[jude-]

Making the TCB bigger makes PoS less secure overall. If you pick the wrong validator set when you boot your node up, you're fucked -- your node will never discover the chain history which represents actual user activity [1]. PoS is the blockchain equivalent of forcing users to pick out which TLS certificates they trust when they install their OS. PoW is the blockchain equivalent to your OS having a way to discover which TLS certificates the majority of the Internet currently trusts in-band, as well as a way to upgrade them to the newly-trusted set if the majority switches.

The sad part is, PoS doesn't even gain you anything -- it's not cheaper. It's just a feel-good measure that doesn't solve the underlying problem.

> Sztorc's argument is heavily disputed in this thread, and you can see the arguments against it in the critiques provided.

Other people not understanding the argument doesn't make the argument wrong.

[1] The proof is in the appendix of this paper: https://eprint.iacr.org/2016/919.pdf. The gist is that they show that two forks are indistinguishable without a priori knowledge of which validator set is not corrupt.

[CryptoPunk]

>>Making the TCB bigger makes PoS less secure overall.

That is a debatable point. The TCB amounts to a single hash, that the global Ethereum userbase has had at least three months to converge on, with extremely obvious ways of establishing its correctness. If that can't be securely established, it's unlikely a consensus on the correct software distribution channels can be established either, meaning new users would still be completely fucked.

And there are other factors that establish the security of the network besides how much subjectivity plays a role in consensus, like the economic incentives dissuading an attack, and the difficulty of acquiring the economic assets needed to attack the chain.

[jude-]

> That is a debatable point. The TCB amounts to a single hash, that the global Ethereum userbase has had at least three months to converge on, with extremely obvious ways of establishing its correctness. If that can't be securely established, it's unlikely a consensus on the correct software distribution channels can be established either, meaning new users would still be completely fucked.

Sure, let's use Ethereum 2.0 as an example (but note that both myself and the linked paper talk about PoS in general.). Suppose I'm a newcomer to Ethereum 2.0 well after it launches. Suppose that, sometime after the launch but before my arrival on the scene, there's another DAO-like event where there's been a contentious chain split, and lots of bad blood on both sides of the split between developers, users, and exchanges. If I'm only interested in using the chain with the most economic activity, then why should I trust you and your servers to tell me who the initial validators are, especially now that you have a financial reason to tell me your preferred fork? It's like a bank asking me to choose between multiple sets of TLS certificates for all the banks I could conceivably use without giving me a chance to vet them -- why would I ever do this? And how would I even do this reliably?

In PoS, all I have to go on is your word against the others (this is the proof the paper makes) -- there is no way around this. In PoW, I can compare the hashpower between forks and use that to determine on my own which fork has the more valuable coin (and thus the larger economy for it). This, by itself, is a strictly more resilient system design.

What Paul Sztorc is saying is that in the event of contention between competing validator sets, both validators will spend resources equivalent to PoW trying to convince all these newcomers that their validators represent the most economic activity. This includes, but is not limited to, spending energy keeping your validator nodes from getting stolen or hijacked in a bid to change the validator set without consent. So, not only are the energy savings that TFA touts expected to disappear in the long run, but also the energy spend won't even help make the protocol more resilient.