Sorry, meant to include the list before. Switching to inline reply since I want to reply to separate points separately.

On Fri, Feb 7, 2014 at 12:40 PM, Lodewijk andré de la porte <l@odewijk.nl> wrote:

2014-02-07 Sean Lynch <seanl@literati.org>:

Substitute "CPU power" for "wealth," and your claim about trust equally applies to the current proof-of-work function. I don't accept your premise that giving more power to wealthy people is somehow worse than giving more power to people with lots of CPU power (i.e. wealthy people).

Ah, yes. But now you're confusing some things.

I can calculate that a certain transaction is no longer worth falsifying. Let's say that there's 10,000 USD (10kusd) required to fake a single block.

Now my transaction is buried 5 blocks. Setting apart a block just for the sake of luck-prevention I can say that if my transaction is <40kUSD it is now entirely safe. It is not worth it to revert it.

Unless someone wants to mess with me (specifically me) it will not be done. If I suspect someone wants to mess with me I only have to estimate how much he can spend messing with me.

Block reward kind of throws a wrench into the story. It drastically reduces the actual cost of mining a block. Still I can say with math that it isn't worth it after a while.

With proof of stake I cannot do such math. I'm subjected not to the will of the rich to mess with me. Not the will of the rich to waste money on me. And the cost of faking a chain does not grow with it's length, unless it's a proof-of-work-and-stake. In which case I'm really wondering why you're taking two risks.

Either way, this is not equivalent to introducing trust into the system where it did not exist before. My claim about proof-of-stake not being trust any more than proof-of-work is stands.

I was proposing using coin days destroyed as part of the "difficulty" computation, which would mean they actually DO have value, since you cannot use the same coin days more than once, and they would reduce the number of CPU cycles you need to burn in order to produce a block. The idea is to reduce the cost of mining in terms of pure CPU cycles by giving value to something that currently has no value: coin days. So you actually CAN do such math still.

This is not a pure proof-of-stake system, though. I am as skeptical of pure proof of stake as you are.

I'm more strongly in favor of using citizen's ID's as provided by governments for the purpose of voting on blocks than in proof of stake.

Not knowing you, this doesn't tell me much, since the same could be said of the most statist friend I actually tolerate, the one who thinks Bitcoin should die in a fire. I'm guessing that this means "not in favor of it at all."

There are a couple of problems people are trying to solve with proof-of-stake. The first is that the value of mining will eventually go down, meaning people will be willing to devote less computing power to it, reducing the cost of an attack. The second is that, even if it didn't go down, we don't necessarily want a huge fraction of the world's computing power devoted to mining. The goal is to take some limited resource that doesn't depend on a trusted third party and that is difficult to corner and use that to distribute voting authority. In addition, we'd like the people doing the voting to have an economic incentive to vote correctly. Bitcoin does that by paying them to vote and revoking the payment if their block doesn't end up in the main chain. Proof-of-stake does it by hoping that the voters care about the integrity of the system, similar to only allowing landowners to vote, only (hopefully) without the ability to prevent others from becoming stakeholders, which I think is your main worry about it.

Incidentally, the coin days are from ALL of the transactions in the block, not just your own. I'm not sure if I was clear about that before. You could maybe override a transaction that had fewer coin days, but you'd have to burn a similar amount (though less) of CPU time in addition.

Speaking of which, is there any reason peers couldn't watch for forks and incorporate any still-valid transactions into new blocks and permanently blacklist any outputs that get double-spent? You could create a special "blacklist" transaction that just incorporates the two separate spends into the main chain, so that everyone could validate that the account holder attempted to double spend.