[andrewla]

I have yet to see a convincing argument that proof-of-stake can be made trustless. The only designs that I've seen that seem realistic rely on some notion of checkpointing to prevent large scale chain rewrites.

While it may be possible to make that checkpointing distributed, the only way that I'm aware of is to use proof of work. The easier path is to just checkpoint in the client, so that the trust comes from the github repository that pushes the client, or gets trusted updates from some trusted authority.

That's not to say that trustless consensus is necessary for a currency. I used to be a very strong believer that that was a necessary component, but I've begun to question that belief. The notion of censorship-resistance is an important part of why I liked Bitcoin in the first place, but may turn out not to be sufficiently valuable to people to impact coins that don't have that property.

[wyldfire]

> I have yet to see a convincing argument that proof-of-stake can be made trustless.

It turns out that "trustless" is more subtle and not quite as discrete as we might've thought. While PoW coins like Bitcoin are probably ranked higher on this scale than others, it might not matter.

> That's not to say that trustless consensus is necessary for a currency.

Agreed. IMO these newer coins that are lower on the trustless scale would not have been possible without the high bar that Bitcoin set. But now, they are.

[andrewla]

> It turns out that "trustless" is more subtle and not quite as discrete as we might've thought.

That's exactly it -- even in the centralized variants, the "trusted" authority doesn't have a lot of power. The main power they have is censoring transactions, both in the present (not accepting a new transaction) and in the past (rewriting the chain to omit a transaction and all of its dependents).

The ability to rewrite history is a dangerous one, but is mitigated by the fact that they can't do so undetected by the network. This is a social/economic effect rather than a cryptographic one, which has its own dangers, but means that the trusted authority risks losing (or forking) its status to a competing trusted authority for the same coin if the consensus of the network is that they cannot be trusted.

The forward security guarantees are just that the transactions are signed, and those signatures cannot be forged, even by the trusted authority, so there is no way for another actor (including the trusted authority) without access to your private keys to spend your coins.

[tim333]

"Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol" ?

(https://eprint.iacr.org/2016/889.pdf

https://news.ycombinator.com/item?id=13134363

https://www.reddit.com/r/ethereum/comments/52qfwl/provably_s...)

[andrewla]

I'll have to give it a closer look, but from a cursory look it seems that there's no avoidance of the bootstrap problem (given two chains, which one does a new node choose?), and no guaranteed Sybil-resistance in the "honest majority" required to avoid the grinding attack.

It would take the endorsement of someone that I consider extremely trustworthy to even go to the trouble of trying to deconstruct whether this approach is valid.

It stands, I think, in stark contrast to the simplicity of the proof-of-work based Sybil resistance, and the "central authority will sign the block" based Sybil resistance.

That said, given this discussion about the nature of trust, this scheme may work in effect, even if in the end it devolves into a centralized or social proof to find the correct chain. I'm not sure it adds a lot on top of that except instilling some potentially false sense of security in naively written nodes.

[wildbunny]

It requires a majority of trustworthy nodes to be online - it cannot deal with a force majeure, such as a massive power cut.

[seanwilson]

What can though? If a large fraction of Bitcoin miners went down you'd need less hash rate to double spend.

[kybernetikos]

> The easier path is to just checkpoint in the client, so that the trust comes from the github repository that pushes the client

Are you not trusting the client you're running anyway? It seems like this is not a very big increase in trust.