[atweiden]

Boring histrionics aside, you haven’t refuted GP’s point. Pure proof-of-stake consensus systems all suffer from the misfeature of not even having a basic quantitative fork ranking protocol. Jude C. Nelson critiques this better than anyone [1]:

    PoW requires less proactive trust and coordination between
    community members than PoS -- and thus is better able to recover
    from both liveness and safety failures -- precisely because
    it both (1) provides a computational method for ranking fork
    quality, and (2) allows anyone to participate in producing
    a fork at any time. If the canonical chain is 51%-attacked,
    and the attack eventually subsides, then the canonical chain
    can eventually be re-established in-band by honest miners
    simply continuing to work on the non-attacker chain. In PoS,
    block-producers have no such protocol -- such a protocol
    cannot exist because to the rest of the network, it looks like
    the honest nodes have been slashed for being dishonest. Any
    recovery procedure necessarily includes block-producers having
    to go around and convince people out-of-band that they were
    totally not dishonest, and were slashed due to a "hack" (and,
    since there's lots of money on the line, who knows if they're
    being honest about this?).

Under adversarial conditions like those outlined by Jude C. Nelson, PoS reverts to “phone-a-friend consensus”, or — to use a euphemism coined by Vitalik Buterin — “weak subjectivity”. Centralized Git repos offer a close to identical consensus model.

What’s the point in having a “blockchain” at all if under adversarial conditions, miners are necessarily demoted in favor of trusted human coordinators? Git is very “green-friendly”, too.

[1]: https://news.ycombinator.com/item?id=26810619

[hudon]

> What’s the point in having a “blockchain” at all if under adversarial conditions, miners are necessarily demoted in favor of trusted human coordinators?

If you want to see precisely how "miners are demoted in favor of trusted human coordinators" in Bitcoin, you can read this analysis of the 2013 fork: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-...

In the quote you posted, Nelson is wrong when he states "[Bitcoin] provides a computational method for ranking fork quality". It only provides such a method when both forks agree on the underlying protocol. If two chains aren't being reconciled because the network is in disagreement on which set of rules is valid, the "computational method" is thrown out the window, and the big guns are called in (high profile developers, influencers in the space, etc.). He uses the words "canonical chain" and "attack" as if it's clear which chain is the attacker and which chain is canonical, but we need humans to help us make that determination on which is which. Chains by themselves aren't hostile or not, they're just numbers.

I'm not saying Ethereum is better by the way... they're all the same.

[atweiden]

> In the quote you posted, Nelson is wrong when he states "[Bitcoin] provides a computational method for ranking fork quality". It only provides such a method when both forks agree on the underlying protocol.

Firstly, the “underlying [PoW] protocol” assumes the “majority of CPU power is controlled by nodes that are not cooperating to attack the network” (Satoshi, 2009). IOW “Bitcoin” is defined as the chain with the highest cumulative hashing power. That assumption is baked into all PoW networks.

Secondly, Jude C. Nelson — who you seem to have a professional/academic disagreement with — has a PhD in distributed systems from Princeton. I’m not saying your disagreement with Jude deserves no credibility, but I’m also not prepared to give a pseudonyous commenter on HN the same weight.

(JCN runs circles around Vitalik Buterin — a highly entertaining read [1].)

The 2013 bitcoin-0.7 BDB chainsplit incident you’ve propped up as “proof” PoW lacks a fork ranking protocol — which it doesn’t — was ultimately resolved with hashpower (of course). Humans only got involved there to prevent needless network downtime, read: “Eventually 24 blocks would be lost”. The incident would’ve eventually resolved itself on-chain by PoW miners, with hashing power only.

> I'm not saying [PoS] is better by the way... they're all the same.

Proof-of-Stake consensus lacks all notion of cumulative hashrate, and altogether lacks a quantitative fork ranking protocol. To claim PoS and PoW are “the same” in this respect is simply false equivalence.

PoS systems undeniably lack an on-chain mechanism for resolving fork disputes. Hence they have little need for a blockchain — after all, if a top-down human hierarchy presiding over a blockchain is going to unilaterally decide which chainfork to favor anyway, they might as well just skip the blockchain and use Git. As with Git repos, in PoS, forking disputes have to be handled by centralized authorities who outright dictate which Git history is valid. No other dispute resolution protocols are possible here.

Conversely, PoW systems make this determination by ranking cumulative hashing power amongst forked blockchains. PoW networks coldly and quantitatively come to consensus about what constitutes the longest valid chain. PoS systems use less energy than PoW systems, but they can’t even come to consensus without top-down hierarchical human intervention under adversarial conditions, hence they have little reason to use a blockchain at all.

[1]: https://news.ycombinator.com/item?id=25984356

[hudon]

> [The chainsplit] was ultimately resolved with hashpower

Did you read the article? Humans were needed to avoid catastrophe. Here let me post the relevant bit:

quote:

What would have happened if the developers had done nothing? Throughout the text I’ve emphasized that the downgrade option was the correct one and that speed of developer response was of the essence. Let’s examine this claim further by thinking about what would have happened if the developers had simply let things take their course. Vitalik Buterin thinks everything would have been just fine: “if the developers had done nothing, then Bitcoin would have carried on nonetheless, only causing inconvenience to those bitcoind and BitcoinQt users who were on 0.7 and would have had to upgrade.”

Obviously, I disagree. We can’t know for sure what would have happened, but we can make informed guesses. First of all, the fork would have gone on for far longer — essentially until every last miner running version 0.7 or lower either shut down or upgraded their software. Given that many miners leave their setups unattended and others have custom setups that aren’t easy to upgrade quickly, the fork would have lasted days. This would have several effects. Most obviously, the psychological impact of an ongoing fork would have been serious. In contrast, as events actually turned out, the event happened overnight in the US and had been resolved the next morning, and media coverage praised the developers for their effective action. The price of Bitcoin dropped by 25% during the incident but recovered immediately to almost its previous value.

Another adverse impact is that exchanges or payment services that took too long to upgrade their clients (or disable transactions) might find themselves victims of large double-spend attacks. As it happened, OKPay suffered a $10,000 double spend. This was done by a user trying to prove a point and who revealed the details publicly; they got lucky in that their payment to OKPay was confirmed by the 0.8 branch but not 0.7. A longer-running fork would likely have exacerbated the problem and allowed malicious attackers to figure out a systematic way to create double-spend transactions. [1] Worse, it is possible, even if not likely, that the 0.7 branch might have continued indefinitely. Obviously, if this did happen, it would be devastating for Bitcoin, resulting in a fork of the currency itself. One reason the fork might keep going is because of a “Goldfinger attacker” interested in de-stabilizing Bitcoin: they might not have the resources to execute a 51% attack, but the fork might give them just the opportunity they need: they could simply invest resources into keeping the 0.7 fork alive instead of launching an attack from scratch.

There’s another reason why the fork might have never ended. Miners who postponed their decision to switch from 0.7 to 0.8 by, say, a week would face the distasteful prospect of forgoing a week’s worth of mining revenue. They might instead gamble and continue to operate on the 0.7 branch as a big fish in a small pond. If the 0.7 branch had, say, 10% of the mining power of the 0.8 branch, the miner’s revenue would be multiplied tenfold by mining on the 0.7 branch. Of course, the currency they’d earn would be “Bitcoin v0.7”, which would fork into a different currency from “Bitcoin v0.8”, and would be worth much less, the latter being considered the legitimate Bitcoin. We analyze this type of situation in Chapter 7, “Community, Politics, and Regulation” of our Bitcoin textbook-in-progress or the corresponding sections of the video lecture.

While the exact course of events that would have resulted from inaction is debatable, it is clear that the downgrade solution is by far the less risky one, and the speed and clearheadedness of the developers’ response is commendable.

[atweiden]

Basically none of that is consensus breaking. And I acknowledged the potential of a deep reorg leading to needless network downtime. In the author of the article’s opinion, this deep reorg would’ve resulted in utter chaos, which seems hyperbolic to me. Regardless, how does that disprove the existence of a fork ranking protocol in Bitcoin?