Over the past year, there has been considerable confusion around the term consensus as it relates to both the consensus mechanism that Satoshi wrote of in the Bitcoin whitepaper, and the consensus rules that underpin the Bitcoin network. This confusion has led to a widespread misunderstanding of the limitations of consensus networks – and of the nature and risks of hard forks.
Satoshi’s consensus mechanism
Satoshi described the use of proof-of-work computation by network nodes to reach consensus – or “general agreement” – about which valid blockchain contains the most cumulative work and is therefore the authoritative blockchain:
“When a node finds a proof-of-work, it broadcasts the block to all nodes… Nodes accept the block only if all transactions in it are valid and not already spent… Nodes express their acceptance of the block by working on creating the next block in the chain… Nodes always consider the longest chain to be the correct one and will keep working on extending it.”
Christian Decker and Roger Wattenhofer describe the result of any contention about the best blockchain:
“Eventually one branch will be longer than the other branches, and the partitions that did not adopt this branch as theirs will switch over to this branch. At this point the blockchain fork is resolved and the ledger replicas are consistent up to the blockchain head. The blocks discarded by the blockchain resolution are referred to as orphan blocks.”
So, in the context of blocks that conform to the protocol’s rules, the network reaches consensus on what constitutes the best blockchain, essentially by a matter of processing power. Miners have rational economic incentive to orphan blocks that are unlikely to be included on the best blockchain. If a miner were to build on such blocks, the odds that their future mining rewards would be accepted by the network would be diminished. In this way, network nodes are able to come to full agreement regarding which chain is authoritative.
How do nodes approach blocks which don’t conform to the protocol’s rules? What if a miner includes a block which double spends outputs, or increases the block size? Satoshi’s answer to that question was quite clear: They respond by “rejecting invalid blocks by refusing to work on them.”
In other words, Satoshi’s consensus mechanism unequivocally rejects invalid blocks. Failing to conform to the protocol’s rules invalidates any block. Any blockchain that includes such an invalid block is not participating in the Bitcoin network and accordingly, is not in competition for the best blockchain.
The difficulty and hash rate of an invalid blockchain is irrelevant to the Bitcoin network, regardless of what miners might tell you. Despite popular perception, miners do not have any power over the protocol’s consensus rules – the rules enforced by every node on the network. The only power that miners specifically have is to order transactions into blocks, in conformity with these rules.
The basis for a network’s consensus rules
Listening to the recent hard fork debates, it’s easy to overlook the fact that the term consensus derives from the root consent. In other words, when you opt in to the Bitcoin network, you consent to the protocol’s rules. Users participate via nodes, which enforce these consensus rules. Thus, individual user consent is the basis for the consensus rules imposed on the network.
This has significant philosophical implications for hard forks. A hard fork is not merely a software change; it entails that every user migrates to a new network. A hard fork is fundamentally a new system, with new rules, and is completely incompatible with the original network. Thus, by definition, a hard fork violates the user consent that serves as the basis for a consensus network like Bitcoin.
In the context of the Bitcoin network, there is no such thing as “achieving consensus for a hard fork.” There never will be. There is no mechanism by which every user of Bitcoin’s software can consent to a network migration. Inherently, users don’t consent to a hard fork – consent exists only post-hoc, after the fork has occurred (when some users decide to opt in to the new network). Anyone that refuses to migrate networks did not consent to the rule changes.
In other words, any “majority vote” (for example, by hash power distribution or coin stake) prior to a hard fork is merely an inaccurate poll, and cannot act as a replacement for the affirmative consent users provide by opting in to a network. Hard forks violate the basic philosophical principles underlying distributed consensus networks and are thus an existential threat to the integrity of their blockchains.
Network consensus vs. “Social consensus”
Proponents of hard forks in Bitcoin and Ethereum have sought to replace the definition of consensus with that of “social consensus” – the idea that if most users agree with a certain plan, that it should be enacted even if it breaks the consensus rules. The underlying logic is that if most people agree to a hard fork, the existing consensus can be subverted, and the majority rulers can economically coerce the minority into migrating networks against their will.
Generally, this understates the risks associated with contentious hard forks by falsely assuming that only one blockchain will survive. Of note, opting in to the forked protocol does not revoke your consent to the original protocol’s rules, and individual users may seek to maximize the value of their tokens held on both chains.
After last month’s hard fork, Ethereum users now understand that it is very dangerous to assume that a minority fork will simply die. If users remain on the original network – suggesting existing demand for its newly minted tokens – the original chain will be worthy to rationally mine. In this way, multiple blockchains emerge from a contentious hard fork. As the ETH/ETC debacle demonstrated, speculators can further challenge a hard fork by establishing market demand for the original chain’s token, ensuring a network split by incentivizing miners to secure the original network.
Perhaps more importantly, this method of governance is in direct contradiction with the basic security premises of Bitcoin (or any similar distributed consensus network). Even if we accept the practical argument that the fear of economic loss associated with mining/transacting on the minority chain is enough to force the minority to migrate to the hard-forked network, the idea should be opposed on philosophical grounds. When you opt in to the network, you and all participants enforce the consensus rules. This entails rejecting invalid blocks – not abandoning the consensus rules anytime 51% (or 75%) of miners tell you to. Such attempts to break consensus are an attack on the very idea of participating in a consensus network. If a majority of miners can coerce the network into abandoning the rules every user has agreed to, only by virtue of its hash power, then Nick Szabo is correct to call this “technologically equivalent to a 51% attack.”
What can we learn from the DAO fork?
The DAO fork is an ideal case study for the dynamics of a contentious hard fork. For background, the DAO was a crowd-funded application built on the Ethereum protocol.
In June, unknown actors exploited a vulnerability in the DAO’s code that allowed them to siphon funds from their owners. This resulted in the loss of millions of ETH for the DAO’s investors. Part of the Ethereum community decided to implement a hard fork to reverse the theft and return the ETH to its original owners.
Despite efforts to poll the community, the vast majority of Ethereum users (by coin stake) and miners (by hash rate) did not vote at all. Still, the hard fork proceeded anyway. Predictably, some users remained on the original chain, and the hard fork resulted in two surviving blockchains on separate, incompatible networks: Ethereum Classic and Ethereum.
Why was the DAO fork contentious?
The crux of the issue centers on where the exploited code occurred: the application layer (in contrast to the protocol layer). When a flaw exists at the protocol level, all network participants are negatively impacted; thus, all users are incentivized to fix the problem. While it is impossible to obtain consensus for a hard fork to address such a flaw, a rational analysis of user incentives suggests that it would receive widespread support.
The closest example that illustrates this dynamic in Bitcoin is the 2010 value overflow bug and subsequent soft fork. Of note: the solution was a soft fork, so breaking consensus rules was never a concern. Bitcoin has never hard-forked.
The value overflow bug, by introducing token supply beyond the intended consensus limits, undermined the basic value premise of Bitcoin’s finite supply limit. The protocol flaw negatively affected all Bitcoin users by effectively diluting their share of all mined bitcoins by ~45,000x. A soft fork was released within hours of the offending block, which rejected output value overflow transactions and any transaction which paid more than 21 million bitcoins. At block height 74691, the soft forked chain overtook the offending chain and orphaned it. This is an excellent example of the community successfully soft-forking to address a protocol flaw. Unfortunately, the jury is still out regarding whether the community can successfully do so in the case of consensus-breaking changes.
The DAO fork differed significantly in that it was a hard fork which sought to address a flaw on the application layer – not the protocol layer. Since the protocol wasn’t at issue, there was no reason to assume that the fork would receive widespread support.
The Ethereum Foundation continues to describe Ethereum as a platform for “unstoppable applications” that “run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.” Stephan Tual, one of the DAO’s creators, made the claim, “Code is law.”
Ethereum’s community was built on the principles of “unstoppable applications” and “ no third party interference.” It simply wasn’t rational to assume that the entire userbase was incentivized to fork their protocol to effectively bail out a third party application. Since the DAO was merely an application, only a minority of Ethereum users participated in its crowd sale. When the DAO theft occurred, only a minority of Ethereum users were affected, and thus directly incentivized to support a hard fork. Predictably, only a small minority of ETH holders and miners signaled support.
Although the initial post-fork miner distribution approached 99:1 at one point in favor of the forked network, enough users were incentivized to secure the immutability and consensus of the original chain. As such, value was retained on both blockchains – it became apparent that both chains were worthy for rational miners to build on, splitting the network into two.
Implications for Bitcoin
What does this mean for Bitcoin? The answer is two-fold.
Firstly, is it possible to initiate a hard fork that is not contentious? The fundamental problem is that the removal of consensus rules generally involves both security and philosophical trade-offs. Take the block size debate as an example. One side is composed of decentralists – those who point to the centralization of nodes and hash power and the necessity of fee markets as compelling reasons not to increase throughput without scaling mechanisms. On the other side are those that argue that retaining low fees and nurturing adoption is paramount to any concerns about p2p decentralization and security. When the fundamental priorities (and philosophies) of each side are incompatible with the other, how can we expect any resulting hard fork not to be contentious?
Vitalik Buterin made an important point when he mused, “I propose we use the term ‘tradeoff denialism’ for when someone tries to reply to ‘I think A is better than B’ with ‘well why not do both?’” Can you imagine a world where 100% of bitcoiners are willing to sacrifice their security for a chance at increased adoption? Where there are trade-offs to be made, there will necessarily be contention.
For years, many Bitcoin users have complained about the lack of a “killer app” that promotes Bitcoin adoption to the mainstream. On the contrary, Bitcoin’s “killer app” was released at inception: math-based, censorship-resistant money on a decentralized inflation-controlled ledger. This is Bitcoin’s primary use case; this is what drives demand and serves as a basis for its value. The risk of a network split initiated by a contentious hard fork is a significant threat to that use case, and to the very idea of a cohesive, global ledger. Pieter Wuille elaborates:
“No matter how you determine the switchover date, there is no way of knowing when (and whether at all) everyone changes their full nodes (and perhaps other software), and even very high hash power votes cannot prevent an actual fork from appearing afterwards. At best, people lose the guarantee that their confirmations are meaningful (because at some point it becomes clear that the other side will get adopted, and they need to switch). At worst, a fork persists, and two partitions appear, in each of which you can spend every pre-existing coin. This defeats the primary purpose Bitcoin was designed for: double spend protection.”
Secondly, a hard fork is a clear attack on the basic security premises and underlying philosophy of Bitcoin. There is no software mechanism to measure user consent to remove consensus rules. There is a widespread misunderstanding in the Bitcoin community which states that hard forks can be enforced as a matter of hash power. This wrongly conflates the nature of hard forks with that of soft forks. Eric Voskuil explains:
“In the case of a hard fork, a new transaction may be valid despite not conforming to the original rules. In the case of a soft fork, new transactions are valid under the original rules. In other words, holders of a money have not agreed to a hard fork but inherently accept a soft fork… A soft fork can be enforced by simple majority of processing power. In other words a soft fork isn’t actually a change in consensus among people, it’s a change that flows from the people controlling a majority of processing power… The original paper does not articulate a distinction between these rules, loosely referring to both scenarios as consensus. However it is an error to refer to soft fork rules as ‘consensus rules’.”
So, it is very true that a majority of hash power can enforce new rules with a soft fork. However, it is clearly inaccurate to say that hash power has any relationship to the software’s consensus rules. Miners have absolutely no say over user consent (i.e. consensus rules) – except to the extent that they operate their own nodes. When prominent developers, industry executives and centralized mining pools promote the idea of a miner vote to determine consensus changes, this is a direct attack on Bitcoin – it is a direct attack on your money. Pieter Wuille points out:
“Bitcoin is not a democracy. The full node security model is designed to minimize trust in other parties in the system. This works by validating as much as possible according to the consensus rules. In particular, there is no ‘majority vote’ that can override things (contrary to what some people think, it is not ‘longest chain wins, and a majority of miners decide’; even a majority of miners cannot steal your coins or produce more than the allowed subsidy, unless they convince others to change their software).”
Hard forks should be opposed as a matter of both risk and philosophy
From both practical and philosophical perspectives, it seems clear that attempts to hard fork the Bitcoin protocol should be unequivocally opposed. The community should be staunchly opposed to the idea that some group of users (for example, mining pools), can vote away the consensus rules that secure our money. It is important to recognize that breaking consensus threatens to erode all trust in the supposed ability of Bitcoin to enforce basic rules. If you believe that consensus rules can be removed via democratic vote, do you really believe in the viability of the 21 million BTC supply limit? Why? Any future vote can simply remove that limit, and the majority can dilute the wealth of early adopters. The consensus rules are your only defense against such theft. Attempting to remove them is opening Pandora’s box.
Readers should ask themselves: Do you believe that miners ought to be able to change the rules that we, the users, consented to? If the answer is yes, then you have imbued miners with the power of central banks. Non-mining node operators do not have identical interests to those of miners; non-mining nodes serve as a check on the power of miners. Refusing to trust miners and individually enforcing the protocol’s rules is an individual’s only protection against collusion by miners (or others) against him/her. In the absence of decentralized node validation, there is no effective difference between miners and central banks; there are no rules by which they must abide. If you grant miners authority over consensus rules, you have sacrificed the fundamental security provided by the full node security model – your money is no longer safe. It is tempting to use miner distribution as a voting mechanism, but it simply has no relation to user consent and thus, should have no bearing on the consensus rules.
As discussed earlier in regards to the 2010 value overflow incident, there is only one narrow condition that may ethically, and in practice, afford us the ability to hard fork: a bona fide protocol flaw that negatively affects all Bitcoin users. Indeed, such a hard fork would violate the consent of users. However, if we know that the protocol flaw affects every user – this is the nature of protocol flaws – then we know prima facie that fixing the flaw is aligned with user incentives and expectations. Any rational user is likely to support a hard fork under these narrow conditions.
To be clear, retaining immutable consensus and therefore favoring soft fork solutions to protocol limitations does not mean that progress nor development must stagnate. On the contrary, in regards to the block size debate, soft forks will allow for incredible improvements to both bandwidth and non-bandwidth scaling without the risks associated with hard forks. Instead of merely allowing more transaction throughput by increasing maxblocksize, we can drastically optimize transaction size to increase capacity through mechanisms like Schnorr signatures. Once malleability fixes are in place, the doors are opened for smart contracts that contribute via non-bandwidth scaling: Lightning Network will allow trustless contracts with no custodial risk, which will directly mitigate mainchain throughput. MAST can further optimize the size of complex smart contracts. Mining pre-validation (weak blocks) can drastically reduce critical bandwidth, resulting in fast propagation / latency mitigation and “weak” confirmations for transactions, addressing concerns over mining centralization in the context of increased throughput. Improvements like committed bloom maps, batch validation and archive nodes can further reduce resource requirements for nodes, mitigating centralization pressures as throughput increases.
Brilliant scaling solutions are before us – solutions which will directly enhance capacity while mitigating the externalities created by increased throughput. Why would we break consensus simply to increase capacity? The idea is absurd!
Implications for Ethereum Classic
The Ethereum Classic community has emerged as a reaction to the brazen approach that ETH developers have taken towards hard forks. Ethereum users that value the integrity of their consensus rules and the immutability of their blockchain have rallied behind Ethereum Classic.
Unfortunately, the consequences of the ETH core developers’ brazen approach are not limited to the DAO fork. ETH’s core developers effectively sabotaged the Ethereum protocol by programming the “difficulty bomb.” Vitalik Buterin describes the effects:
“At block 3.5m (1 year from now), we would have an equilibrium block time of 25s for 100k blocks (~1 month); then we would see 35s for 100k more blocks (now ~1.4 months); then ~55s for ~2.2 months, then ~95s for ~3.8 months, and so forth until we get ~655s for ~26 months (ie. slightly worse than bitcoin), and only after that does the protocol break because of the cap of ~99/2048 downward adjustment, and that final doom does not take place until 2021 (though it certainly gets very annoying by the second half of 2017).”
In effect, time between mined blocks will become longer and longer until eventually, “final doom” occurs, when no more blocks can be mined. It should be noted that to purposefully sabotage the Ethereum protocol in order to force a break of consensus shows incredible disdain for the Ethereum userbase by ETH’s core developers. Nevertheless, this is the hand that Ethereum Classic was dealt.
Fortunately, the Ethereum Classic community has the means and moral authority to break consensus to overcome this sabotage. The difficulty bomb is an existential protocol flaw. All users are incentivized to fix it – they must be, otherwise their protocol is doomed to inertia, and effectively will no longer be an active blockchain.
As such, the only way forward is a hard fork – one whose only change to the protocol is to return delayed block times to historically typical levels. The only chance we have to prevent a contentious hard fork is to restrict consensus changes to the protocol flaw that warrants the fork.
Many bitcoiners have come to support the Ethereum Classic community, some of whom have expressed a desire to fork ETC’s protocol to restrict the future supply and perpetual inflation of ETC. This is the wrong course of action, and enters the dangerous territory of contentious hard forks. ETC’s inflation rate is specifically a security incentive that ensures honest mining – removing it entails significant security trade-offs, which will not be looked upon equally by every user of the protocol. To prevent a network split, emphasis must be put on aligning consensus changes with global user incentives and expectations. Any changes outside the narrow context of addressing protocol flaws are likely to result in contention.
Whatever your philosophical opinions might be in regards to hard forks, it’s important to remember that Bitcoin is not merely money; it is also the software development project that seeks to secure that money. In engineering, particularly with considerable value at risk, it’s vital that we plan for worst-case scenarios. We cannot simply assume that users will blindly follow miners and change their software – particularly because they shouldn’t. And while miners are rational in where they point their hash power, this does not entail that miners are correct in their assumptions about the resolution of a hard fork. The risks entailed by hard forks simply do not warrant their use as a mechanism for software updates underpinning a consensus ledger.
Bitcoin and other token-based consensus networks are economies. Unfortunately, causality in macroeconomics is, and will likely continue to be a mystery. As David Hume said, “There can be no demonstrative arguments to prove that those instances, of which we have had no experience, resemble those, of which we have had experience.” We can never know beforehand how a hard fork capable of splitting the network will resolve.
We must take a risk-oriented approach and avoid the worst-case scenarios that hard forks entail. In particular, the emergence of multiple Bitcoin networks open to cross-network double-spending would be a devastating failure of Bitcoin’s double-spend protection. Further, it would forever cast doubt on the ability of the Bitcoin network to enforce basic rules, such as its limited supply.