Response to Buterin’s Criticism of my Proof-of-Stake Piece
Tuur Demeester
3916

> There’s a long history of nationalization to prove that after governments (IMO the most likely attacker) take over, operational efficiency tends to drop strongly. One study estimates that oil mining companies see their profitability drop by over 50% post nationalization. So that $700 million may be a very low estimate, as it may operate at much lower efficiency post takeover.

I agree that governmental attackers are an important threat to blockchains, though I will personally say that in the Ethereum context they’re generally viewed as the #2 threat. The #1 threat is, unfortunately, Ethereum opponents within the crypto community, such as those who implemented the DAO hack and the DoS attacks last year. The financially resourced attackers I am worried about include mining pools who want to dissuade other blockchains from going PoS, bitcoin maximalist organizations, and other similar threats. And many of them are quite capable of being efficient.

In the long term, sure, government attackers become a larger threat, though I don’t think they will be able to screw up their operational efficiency to that large an extent; all they have to do is buy up or commandeer a few large data centers or mining farms. Furthermore, even if government attackers are horribly inefficient, that seems like it would apply to PoS too — for example, even though theoretically you can revert finality by sacrificing 33% of deposits, an inefficient attacker would likely have a hard time with less than 50%.

> One entire avenue of PoS attack vectors are for example scenarios where attackers borrow the ETH with which they attack the chain, thus profiting from a plummeting price and offsetting most or all of the designed “punishment”.

This is true, but this should not be used as an argument for PoW vs PoS because with any consensus algorithm, an attacker can earn an additional $X (or you can phrase it as “offset $X of their costs”) by shorting ETH during an attack, and so it doesn’t tip the scales one way or the other.

In fact, algorithms that can recover from faults more easily have a lower X, because a 51% attack would not lower the price as much, so this may even be a point in favor of PoS.

> but in terms of the tokens themselves, the attacker could restrain himself and confiscate only 1–5% of each balance for example, so that for each individual saver it would likely still be worthwhile to keep using the system

Blockchains are not just about tokens. I am thinking about the outputs and intermediate states of complex applications including random number generators, on-chain race conditions, ERC20s, proofs of existence, active channels, etc etc. I don’t think it’s possible to make a 4-month reversion of history that is not very seriously disruptive.

As an example, I’ll offer the DAO fork — there were clearly a lot of people complaining and the fork was quite difficult to achieve even though the only “victim” of the HF state transition itself was a $60m thief.

> It could be argued that Bitcoin’s largest mining company Bitmain, with its support of Segwit2X and its BitcoinABC fork blueprint, is executing a long range attack on Bitcoin in an attempt to change its economic model. Yet I’ve never seen you argue that the solution is incredibly clear, and that the community should simply follow the legacy chain. Again, my point is that community consensus is an impractical and undesirable mechanism to rely on for public blockchain robustness. In this thread you seem to agree with that: “I’m not convinced “rough consensus” is a sustainable governance model in genuinely adversarial environments. No country runs on it.

This situation is very different. Unless you read strongly partisan media, it’s very clear that the bitcoin scaling wars are a genuine political disagreement between two factions of the community, and there is little support for the idea that one side is an unambiguous malevolent attacker. Personally, I favor the moderate big blocker side, and other people forcefully favor the small blocker side.

Here, we are talking about a choice between two chains where one chain continues the history that everyone saw all along, and the other chain blatantly reverts 4 months of history. Now if you want to draw analogy to bitcoin scaling wars, it may be the case that the attacker says “ah, but my chain that reverts 4 months of history has better features”. But that then becomes standard market competition between a cryptocurrency and an altcoin, which is outside the scope of the security model — of course a blockchain can be supplanted by something which the market agrees is technically better.

> If you want to argue that Bitcoin somehow runs on social consensus, then at least you should make the distinction that it’s the ‘opt-in’ variant of social consensus, and perhaps also acknowledge that Ethereum/PoS runs on the much more centralization friendly ‘opt-out’ social consensus.

I don’t see why Ethereum’s PoS is opt-out. When a hard fork comes in, you have to opt in to it, otherwise you’re on the non-forking chain.

> Of course in nature the recognition algorithms can be fooled, for example by humans, but with cryptography proof-of-work can be made near entirely waterproof.

I’ll continue to challenge this point. Your node has no way to verify that SHA256² is the hash algorithm for bitcoin, and scrypt is the hash algorithm for litecoin, and not the other way around. It just has the information baked in, from a piece of source code that you downloaded from a trusted source. So if you get a malicious client that tells you scrypt is the hash algorithm for bitcoin, then you sync up to the head of the chain, it will look like you’re synced up to the head of the bitcoin chain, and there will be quite a lot of computational work appearing to back that up, but it’s still not true.

> Your claim that “PoS can achieve a much more favorable ratio” is an argument from authority, unless you can point me to a working public blockchain that operates on pure bonded proof-of-stake, and to pentesting evidence of its security.

WIP :)

> A.k.a. Proof of Vitalik. Someone has to decide which of the 10,000 forks I create is valid. I guess it’s Vitalik.

Not really. It’s a simple protocol rule that says “a blockchain that does not include a prepare or commit that I have known about for more than 2 months is invalid”. This is totally programmatic.

> added that “all these layers of crap add complexity and make the attacks harder to explain but don’t seem to fix the underlying problems.” I think Cohen is right, in that a maze of rules to prevent abuse will likely result in a much more fuzzy definition of what abuse really is, the interpretation of which can than be delegated to bureaucratic powerbrokers — an Ethereum politburo if you will.

Abuse can be defined quite clearly. Abuse is:

  • Two incompatible checkpoints being finalized
  • Many epochs in a row not being finalized (from the point of view of the dominant available chain)
  • Transactions or consensus messages being censored (from the point of view of the dominant available chain)

Cohen may think that minimal slashing conditions are layers of crap and complexity; to me, they are straightforward adaptations of algorithms from 30-year-old Byzantine fault tolerance theory.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.