Satoshi’s Most Misleading Paragraph
The most misleading paragraph in the entire Satoshi white paper, without a doubt, is the third paragraph of section 4:
The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.
There are a few serious problems with it. First there are the obvious ones— nobody uses CPUs to mine anymore, very few nodes still mine, only mining nodes vote, and mining pools have tended to concentrate voting to a few pool operators. But there’s another serious problem that has often gone overlooked: the only thing on which mining nodes are actually voting is which of multiple valid chains to extend, not what rules to use in deciding whether a particular chain is valid.
Now this might not seem so clear upon a first reading — after all, Nakamoto does speak of “majority decision making” in an apparently general sense. Regardless of what Nakamoto might have meant here, upon deeper examination of the concept (and looking at Nakamoto’s implementation), we come to appreciate that were the nodes to actually vote on whether a chain is valid we would immediately lose the algorithmic nature of the consensus process — and with it, the strong guarantees of eventual consistency. Were nodes to actually do this, the chain would eventually diverge and the network would fragment. Without a common set of rules determining whether a particular chain is valid, there’s nothing to stop nodes from diverging into separate networks — even with minority hashpower…or perhaps even without any hashpower at all!
As the Ethereum ETH/ETC hard fork demonstrated, a chain with minority hashrate can continue to chug along. Some have argued that Bitcoin is different since the difficulty adjustment takes much longer. But the difficulty adjustment issue is a well-known problem, independent of the hard fork issue. Any sudden drop in network hashrate would result in this problem, regardless of the cause. And if this were to occur, it is quite probable that many stakeholders would opt to tweak the difficulty readjustment algorithm to get around this problem. Yes, this would also effectively fork these stakeholders off from those who opt against this intervention…but arguably, the incentives to cooperate to fix the network would be sufficiently strong to override such controversy. Every stakeholder would have an interest in fixing it. Nonetheless, it’s a kind of scenario I would prefer to avoid.
What actually happened in the ETH/ETC fork isn’t that a majority hashpower decided on a new set of rules. The only thing that majority hashpower did was attempt to legitimize the process of forcing exchanges and other economically important nodes to change their software to effectively support a new protocol with different rules. The same symbol at the exchange became applied to effectively a new network with different consensus rules. Had these economically important nodes refused to change their software, there’s nothing within the original protocol that would have been able to force them to do so. Therefore, we lost the algorithmic nature of proof-of-work consensus in favor of a political process.
Soft forks deployed with signaling mechanisms such as BIP9 are fundamentally different than hard forks: we don’t lose the algorithmic nature of proof-of-work consensus — the addition of new consensus rules to the validation process can occur incrementally and only after guaranteeing overwhelming incentives for hashpower to enforce them; and we avoid the risk of a chain split since even nonupgraded validating nodes can continue to validate the rules they are familiar with and will consider the new blocks valid as well. For obvious reasons, nonupgraded nodes cannot validate new rules they are unfamiliar with. This argument has been raised as a reason against doing soft forks — but there’s no way around this with a hard fork either, so such arguments are moot unless one is arguing against making any consensus rule changes ever. BIP9 ensures that all nodes are aware of any impending soft fork activation so they can warn their users and give them a chance to either upgrade, stay with the same software, or opt out of the network completely.
In the case of a hard fork, it is necessary to convince economically important nodes, such as exchanges, to update their software before it is clear that a chain will reach a permanent supermajority. Even if a chain reaches a supermajority, the hashrate can always swing back to other chains that become more profitable to mine. Hashrate will tend to follow the markets. This adds a tremendous amount of uncertainty to the deployment and is very highly disruptive to commerce and markets. And there’s no guarantee that we reach eventual consistency at all. Two or more chains can continue to exist indefinitely, leading to inflation, destruction of fungibility, cross-chain attacks, and a number of other undesirable effects, not to mention potential hostility in the community; and with it, balkanization.
During the recent Ethereum security hard forks, I ran a few Ethereum nodes. I can speak from personal experience — even as someone with extensive experience and knowledge in these types of networks, it became quite an ordeal to keep in sync with the networks. I can only imagine how difficult it would be for far less technically inclined users to be dealing with these issues regularly. For these reasons, I believe frequent hard forks would tend to strongly discourage people from running validating nodes.
Miners have always had two abilities:
- To select which transactions to put in their blocks, including the coinbase transaction that pays them their reward.
- To select which of multiple valid chains to extend, assuming the rest of the network also accepts any of these chains as valid.
Nakamoto’s most-difficult-chain rule allows the rest of the network to converge upon the same ledger regardless of the choices made by miners.
Attempting to give miners the ability to vote on hard forks has always run counter to Nakamoto consensus* as it would mean miners could arbitrarily change the rules even if other nodes in the network would not accept their chains as valid. Indeed, the only way such a change in rules would even be possible is by getting validating nodes to change their software, whether willingly or via coercion. If the change is highly contentious, some of the nodes would have to be coerced if we’re to retain a single network. And this gets us right back into the realm of political money that Satoshi was trying to avoid.
— — — — — — — —
*Soft fork mechanisms such as BIP9 were probably unknown to Nakamoto. Also, much progress has been made in isolating the consensus rule implementation and modularizing node software to allow for multiple implementations that will still converge to the same ledger.