Proof of Stake...

[Sean Lynch]

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 at odewijk.nl>wrote:

> 2014-02-07 Sean Lynch <seanl at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6119 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20140207/acbbd6fa/attachment-0001.txt>