[jude-]

> There is no legitimate sense in which PoS _is_ an instance of "rich have more power and get richer" but PoW is not.

In PoW, miners must sell their tokens to buy capital-intensive mining equipment and power to stay competitive. In PoS, stakers have no incentive to sell enough tokens to anyone who could turn around and stake them as a competitor, since that would cut into the seller's future staking rewards.

> The 1/3 bound is for safety-under-asynchrony (a form of safety for which PoW's security margin is zero). If you assume synchrony, then PoS protocols' safety approaches 50% much like PoW does.

First, consensus protocols can be trivially safe regardless of the network's behavior -- you simply require a majority vote for any proposed agreement. Second, any consensus protocol can only remain live as long as there are no more than f faults out of 3f+1 replicas. This is again irrespective of the network model -- Leslie Lamport's proofs do not make any assumptions about the network.

[vbuterin]

> Second, any consensus protocol can only remain live as long as there are no more than f faults out of 3f+1 replicas. This is again irrespective of the network model

We actually know of consensus protocols that require synchrony including between participants and clients that go up to 99% fault tolerance for both liveness and safety; in fact Lamport himself described one in his original paper (remember that it's "written messages" and not "oral messages" in his vocab that's the relevant category; these days public key cryptography is cheap and uncontroversial so there's no need to care about the "oral" case). There's also a table on page 291 in the 1988 DLS paper (see https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf, the "authenticated byzantine" row and the "synchronous" column) that gives an overview of the fault tolerance levels in various different cases.

The original definition of consensus did not have a notion of passive clients needing to learn the result, so the "active participants synchronous, passive clients asynchronous" model common in blockchain land was not really analyzed well back then. It turns out that with a synchronous network, the passive client requirement is what brings safety and liveness down from 99% to 50%. And it also happens that the 50% fault tolerance protocols are less fragile in the case that the synchrony assumption breaks temporarily.

[jude-]

> We actually know of consensus protocols that require synchrony including between participants and clients that go up to 99% fault tolerance for both liveness and safety; in fact Lamport himself described one in his original paper (remember that it's "written messages" and not "oral messages" in his vocab that's the relevant category; these days public key cryptography is cheap and uncontroversial so there's no need to care about the "oral" case)

The "written messages" protocol does not tell the whole story. If you go back and re-read Lamport '82 [1], the assumptions that make the SM(m) algorithm ("written messages") work at all also make it a practically useless result. In particular, assumption A4(b) (top of page 391) requires that anyone can authenticate any general's messages at all times. How the generals are supposed to learn each other's public keys _without_ an instance of SM(m) is not addressed, but presumably they would need to fall back to OM(m) ("oral messages") to do so. So if you take a BFT system as a whole, where you can't assume the existence of a magical fool-proof way for generals to learn each other's keys a priori, my original claim stands.

> The original definition of consensus did not have a notion of passive clients needing to learn the result, so the "active participants synchronous, passive clients asynchronous" model common in blockchain land was not really analyzed well back then.

Prior literature doesn't consider "passive clients" because they're not protocol participants in the first place. Clients do not participate in deciding agreement; otherwise they wouldn't be called clients.

Last I checked this is very much still the case in blockchain-land. Your wallet (client) does not do anything to help miners/stakers determine the best chain tip or the next block, for example.

So, I'm not sure what you're trying to say here?

> It turns out that with a synchronous network, the passive client requirement is what brings safety and liveness down from 99% to 50%. And it also happens that the 50% fault tolerance protocols are less fragile in the case that the synchrony assumption breaks temporarily.

Unless you're assuming the existence of the magic fool-proof public-key distribution mechanism required for SM(m) to work, you're not going to get liveness unless you're either (a) assuming nodes do not exhibit arbitrary failure modes, or (b) requiring at least 2/3+e nodes are honest.

[1] https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf

EDIT: wrong date for Lamport