In this article, we will explore Bitcoin’s model of governance by first discussing how it works at the protocol level. We will then examine it in light of hard forks, soft forks, as well as a couple of historical examples.
Bitcoin’s method of governance is through consensus which emerges through a network wide agreement of rules enforced by a user’s Bitcoin full node or client. Miners create blocks according to these rules and then submit it to the network of full nodes for them to validate. Full nodes do this by downloading the block and then verifying if it matches the consensus rules of their client. As long as that block is valid and has the most work of other potential chains, the node won’t reject it. If it doesn’t match or doesn’t have the most proof of work, it rejects it. Therefore as block creators, miners are responsible for implementing the rules of the network. On the other hand, full nodes individually validate whether the submitted blocks are in accordance to consensus rules.
In light of this, a full node is only useful for the person running it because it allows them to verify the transactions they receive in accordance to the set of rules they have determined to follow. In this way, they can spend their Bitcoin in the future to other entities that follow the same rules. Therefore it is of upmost importance for full node operators to be conscientious of which client they choose to download and run.
One way changes in Bitcoin can occur is through something called a hard fork. A hard fork is when there is a backwards incompatible change in the rules of consensus. An example of this would be to increase the block size of Bitcoin from 1 mb to 10 mb. If a current Bitcoin full node receives a 10 mb block, it would immediately reject it because it does not fit within the 1 mb block size limit rule.
Once a hard fork is scheduled to activate at a specific block height, it is now up to each individual user and miner to determine which set of rules to enforce. Once the blockheight hits, there is nothing to prevent either of these two chains from continuously being mined or validated, which can create two versions of the blockchain: the unchanged version and the changed version. This creates some chaos and uncertainty and is one of the reasons why hard forks are viewed as dangerous within the Bitcoin community.
One way this can resolve is if one of the chains has significantly less hashrate than the other. That means it will take longer to power through the 2016 block cycle for the mining difficulty to readjust. Meanwhile the chain with the majority hashrate will continue extending their blocks in a more regular fashion and accumulating more proof of work. Therefore people may simply decide to follow the chain with the most proof of work.
Another way this can resolve is if most full nodes in the ecosystem choose the chain with the minority hashrate. Even though the chain with more hashrate has more proof of work, the vast majority of users and businesses may choose not to run that version of the blockchain because they fundamentally disagree with the hard fork. In this way, the chain with the majority hashrate would become irrelevant.
A third way a hard fork can resolve is with two completely independent networks running safely side by side through replay protection. That means both chains survive and transactions broadcast on one chain stay in the same chain. An example of this is when Bitcoin Cash hard forked away from Bitcoin in August 2017. People running Bitcoin software did not have to do anything while those in favor of larger blocks downloaded and ran Bitcoin Cash nodes.
Bitcoin can also make adjustments in the existing protocol through something called a soft fork. This means a new rule can be implemented by miners while the rest of the full nodes in the network don’t have to download the new client software. This is commonly referred to as “backwards compatibility.” One way soft forks can be implemented is via BIP 9 or a Miner Activated Soft Fork. Miners “signal” their support for a protocol by leaving extra information in the coinbase of the blocks they submit. If more than 95% of the successfully submitted blocks show support for the new rules over period of time, the new protocol is activated. If not, the new rule is rejected.
However, the success of the User Activated Soft Fork (UASF) soft fork to activate Segwit in 2017 showed that governance in Bitcoin can look very different. For a complete and thorough history of SegWit’s journey to Bitcoin, I highly recommend this article by @Aaron van Wirdum from Bitcoin Magazine:
The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality
Segregated Witness (SegWit) has activated on Bitcoin. As of today, all SegWit-ready nodes on the Bitcoin network are…
In short, UASF was a soft fork that allowed users to signal that they will reject non-segwit blocks by running a UASF full node. The philosophy behind this proposal was that users were in control of Bitcoin, not miners even though they are the block creators and submitters.
However, there was some debate as to the true efficacy of users signaling their support for UASF. One reason is that the results of node signaling could have been misrepresented. For example, a single individual could have spun up hundreds of nodes in favor of the soft fork by themself. This introduced doubt to miners, who had to decide on which client to utilize for block creation, how much real support UASF had.
This is when Bitcoin’s emergent consensus for SegWit was fought for through social means. People in the community began publicly displaying their support through various social networking channels. Twitter was one of the primary platforms as people began adding [UASF] on to their profiles. This removed any doubt as to who supported the soft fork and provided confidence that UASF had significant support both numerically and by influential members within the community.
Another example of how Bitcoin achieved soft fork consensus through social means was back in 2010. This soft fork censored a specific type of transaction after an attacker had exploited a vulnerability that allowed them to create a block with 92 billion BTC. After some discussion through social media channels, such as bitcointalk.org, the Bitcoin community unanimously agreed to jump back to a previous point in the blockchain before the exploit, thereby killing off the chain history containing the 92 billion BTC block. However, it is important to note that the community was extremely small back then so it was easier to coordinate. The fact that this was an emergency also helped.
Bitcoin’s governance model is implemented through emergent consensus. Individuals must choose which Bitcoin client to run based on the protocol rules it enforces.
However emergent consensus can also be fought for socially, which has been historically demonstrated through UASF and CVE-2010–5139. It is in this way that people attempt to sway the decision of full node operators and miners through discussion and social signaling.
*Special thanks to Udi Wertheimer for his insights.