[DennisP]

> if over 1/3 of the staked coins are malicious

So now you've escalated the attack to be a 33% staker, which I don't think you'd mentioned before. I'll note that 33% of stake is likely to cost more than 50% of mining hardware, and certainly would at the high levels of staking you're concerned about.

> The system doesn't know how many distinct validators exist

Each validator has 32 ETH. If you want to stake more, then you run more validators.

The system does continue running with a split chain, each side apply the leak to the other side. Seems to me if the network reconnects, the side with the most stake would automatically be chosen as the winner, and if somehow the network never reconnects, then a working chain in each might be what you want.

To the extent that social decisions are necessary, this 2014 post on "weak subjectivity" is the first to address your objection to that sort of thing:

https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...

At this point, I'm going to just suggest learning more about how the system actually works. A good starting point is these papers:

Casper FFG: https://arxiv.org/abs/1710.09437

Combining GHOST and Casper: https://arxiv.org/abs/2003.03052

[jude-]

> So now you've escalated the attack to be a 33% staker, which I don't think you'd mentioned before.

I mentioned it in my original comment, reproduced below:

"The unstated gotcha here is that the chain operates through a variation of BFT agreement where staked coins vote for new blocks. All the usual BFT constraints apply -- namely, if fewer than 66% of the staked coins can reach a quorum, the chain stalls. This would mean that the network is only as resilient as the nodes that contribute the least-resilient 33% of the coin votes."

Also, as mentioned before, the cost attacking the network is not the cost as buying 33% of the staking coins. The cost to attack the network is the minimum of either buying 33% of the coins, or compromising 33% of the staked coins' nodes and forcing them to misbehave. Either way, you get a liveness failure.

> The system does continue running with a split chain, each side apply the leak to the other side

It may, but it is definitely not operating in a BFT manner at that point any longer. There is no in-band recovery from an attacker that compromises 33% or more of the staked coins, since they can forever stall the network. Contrast this to PoW, where an attacker that controls 33% or more of the mining power can be dislodged by the honest participants acquiring more mining power (since hashes/sec, not coins, determines who can produce blocks).

> To the extent that social decisions are necessary, this 2014 post on "weak subjectivity" is the first to address your objection to that sort of thing:

In other words, you have to trust somebody to resolve forks for you out-of-band. Note that PoW does not have this deficiency -- when presented with two conflicting chains, the one with the highest cumulative PoW is the "true" chain.

> At this point, I'm going to just suggest learning more about how the system actually works. A good starting point is these papers:

I've read both, and there's nothing special about them that invalidates anything I've written above.

The points I raised in this thread are distributed systems 101 material. Maybe the Ethereum team should pick up a textbook.

[DennisP]

Ah, well if a PoW chain, let's say Bitcoin, relies entirely on hashpower and not at all on social consensus, then I have an attack. First I accumulate >51% hashpower. Then I run my own hard fork which awards 10X block rewards to all blocks produced by me. It also makes all transactions valid if signed by me, so I fill my blocks with transactions taxing 10% from other addresses. I post my forked code on github and tell everybody it's an upgrade.

Eventually people buy and set up enough hardware to get me below 51%. They won't like my chain and their old software won't consider it valid, but so what? Bitcoin doesn't rely on social consensus so opinions are irrelevant. My chain has the most accumulated work. Until other miners catch the old chain up to mine, I control the real Bitcoin.

Or maybe everybody would ignore my rule-breaking chain because Bitcoin relies on social consensus after all.

[jude-]

> Then I run my own hard fork which awards 10X block rewards to all blocks produced by me.

Since your blocks violate my and everyone else's nodes' block validation rules, which among other things stipulate a fixed minting schedule (which you did not adhere to), your blocks are never accepted -- they are treated as invalid and dropped. QED your attack fails.

I honestly thought you knew better before I saw your reply.

> I post my forked code on github and tell everybody it's an upgrade.

Since I'm intending to install "Bitcoin," it is a reasonable assumption that I know what "Bitcoin" is. So, it's possible for me to read your code, and determine that it is, in fact, not Bitcoin, because it does not have the same minting schedule.

Note that knowing that the software I'm running adheres to the rules that make up "Bitcoin" is sufficient for me to bootstrap my node and validate the Bitcoin chain, assuming I am able to connect any/all public Bitcoin nodes (regardless of which fork they see). Even if I join the network while the network is partitioned, my node will eventually determine which of the partitions' forks is the canonical fork all by itself, because the rules of Bitcoin stipulate that the valid chainstate with the highest cumulative PoW is the canonical fork.

However, this is not sufficient for PoS, because in PoS, someone must also tell me out of band which fork is the canonical PoS chain, should the network ever partition into two competing networks. This is because there is no way to examine the chainstate itself and determine which conflicting PoS fork is the canonical fork, even if I can reach all public PoS nodes for all forks. Each partition can plausibly claim that the other fork was rightfully slashed for being offline for a time before my node joined. Because I didn't personally see the offline behavior, I have no way of knowing which partition to trust, if any -- someone who was there to see it must tell me. That's "weak subjectivity" for you.

[DennisP]

Everything you described about Bitcoin is social consensus on the rules of the game. That consensus changes with any hard fork. Whether that consensus includes a block hash is a detail.

[jude-]

No one is arguing that blockchains don't require a priori out-of-band agreement between the human operators on what the rules of the network are in order to work. Please don't be daft, and try and stay on topic. All distributed systems require this.

What is being argued is that each PoS node requires an out-of-band indication as to which fork is the canonical fork before it can boot up. Nodes in PoW systems do not need this -- the protocol lets them figure it out automatically.

Considering that the whole reason for building blockchains is to minimize the trust required between the humans that build and operate them, this puts PoS systems as a whole at a disadvantage -- booting a PoS node requires strictly more trust in other humans than PoW.

Also, just because your preferred blockchain undergoes hard forks all the time because it lacks protocols for in-band upgrades and for multi-stakeholder decision-making, doesn't mean that all blockchains are so lacking.

[DennisP]

Well, you're missing my point, but since you're using phrases like "daft," "stay on topic," and "I thought you knew better," I think the productivity of this discussion has come to an end.