What is Bitcoin governance?
Bitcoin is not a static protocol. Developers work on Bitcoin to fix critical bugs and deliver upgrades that ensure the protocol stands the test of time. But who decides what changes are made to Bitcoin? Since Bitcoin is decentralized, the process for evolving it is very different from a centralized entity where decisions can be made in a top-down manner. Actually, the term ‘governance’ is not strictly applicable to Bitcoin. The reason being, it implies a situation where leaders act as proxies for the masses — and that’s not how Bitcoin works. Although some blockchain-supported decentralized systems do integrate formal governance processes such as the ability to vote for proposals on-chain or elect leaders, Bitcoin has nothing of the sort.
The process for improving the Bitcoin protocol is quasi-political in the sense that stakeholders must jockey for power and influence. However, it’s not a democracy, a plutocracy, or any other kind of formal political system. Rather, the process for evolving Bitcoin is one of consensus building, where deliberation and persuasion are critical, but where all participants always retain volition. In other words, it’s an opt-in system where everyone has the choice to go their own way, and what Bitcoin is is up to the people who use it. Importantly, the default culture amongst Bitcoiners is that the protocol does not change unless it absolutely has to. This means that, unless the vast majority of participants agree to a change, there will be no change — and those who wish to change are always free to go their own way.
With the understanding that, at the end of the day, Bitcoin is what its users say it is, there is a formalized process for deciding, at the developer level, what changes are needed and how to integrate them. This is the process of developing the Bitcoin Core software client that the community of nodes chooses to run. This software defines the rules of the Bitcoin protocol, so in some ways it is Bitcoin.
What are Bitcoin Improvement Proposals?
Bitcoin’s code upgrade implementation process is formalized through the use of Bitcoin Improvement Proposals (BIPs). These are drafted, peer reviewed, publicly debated, and rigorously tested towards the goal of establishing ‘rough consensus’ amongst the community. Rough consensus is said to be achieved when most people are satisfied that objections to the proposal are wrong.
Once rough consensus has been achieved, the next step is to integrate a BIP into the Bitcoin software client implementation known as Bitcoin Core. This step is completed by one of a small number of ‘core developers’ who have ‘commit access’ to the code repository (meaning they can upload the code to a specific public platform that the community recognizes). Once the BIP has made it into the Bitcoin Core code repository, the final step is for the network of users (nodes) to install the new version of the software client. This final step is critical because it means that end users retain ultimate control over what Bitcoin is.
Only when a defined threshold of nodes installs the upgrade can it be considered activated, and the barrier to activation for BIPs that make material changes to the Bitcoin protocol is set extremely high. For example, BIP 141 (SegWit) required 95% of the network’s miners to signal for the upgrade over a fixed period of 14 days.
Importantly, most consequential BIPs introduce ‘backwards compatible’ changes to the protocol. Backwards compatibility means that any nodes using the new version of the software remain compatible with nodes running the previous version (and vice versa). Backwards compatibility provides nodes, rather than developers, with the final say as to whether a proposal will be implemented. A backwards compatible update is sometimes called a ‘soft fork.’
What’s a hard fork?
When a BIP is not backwards compatible, the only way for it to be introduced is through what’s known as a ‘hard fork.’ Here, only nodes that run the new version are compatible with each other. This means that the entire community of nodes must agree to use the new version. If any segment of the community doesn’t agree to install and run the new software, the result is two separate chains that no longer communicate. Bitcoin Cash, which is the largest and most consequential of the Bitcoin forks, started in August 2017 after participants in the Bitcoin ecosystem were unable to agree on methods for scaling the cryptocurrency.
Who’s in control of Bitcoin?
While the above-described formalized process for creating and integrating BIPs can be considered a form of governance, Bitcoin actually evolves according to the broad consensus of its participants. There are a wide array of voices, including developers, miners, exchanges, wallet providers, custodians, independent node operators, and end users. Participants are locked into a dynamic power struggle where checks and balances prevent any one group from wielding outsized power or influence.
One might look at the fact that there are just 100 developers listed as having contributed to the Bitcoin Core client and conclude that the source of funding behind those developers is a major driving force behind the evolution of Bitcoin. However, one must also consider that there are at least 80,000 Bitcoin nodes — and since most nodes independently decide which Bitcoin Core software client to run, developers can be considered beholden to nodes. Afterall, if developers release software that’s incompatible with the consensus of nodes, that software will not be adopted across the network. Meanwhile, the end users of Bitcoin — who number in the tens of millions — have influence over node operators. For instance, if a wallet provider (who operates a node) begins running a version of Bitcoin that runs counter to the wishes of its users, those users can simply switch to a different wallet provider.
Miners are another group of participants that is often put forward as wielding outsized influence over the evolution of Bitcoin. The argument here is that since miners decide which transactions to include in blocks, a contingent of miners who possess more than 50% of the hashpower can hijack the entire network. Even the threat of hijacking the network, the argument goes, could be enough to influence the evolution of the protocol. The reality, however, is that miners too are beholden to nodes (and ultimately to end users as described above). Reason being, nodes (and by extension end users) can simply ignore blocks produced by miners who aren’t following the consensus protocol. In this scenario, there will inevitably be another group of miners available to direct their hashing power to the consensus protocol. This other group of miners will rise to the occasion thanks to the economic incentive provided by the block reward. The ‘renegade’ miners, then, will find themselves dedicating their resources to a version of Bitcoin that the majority of users no longer considers the ‘real’ Bitcoin. They are free to mine new Bitcoins on their new chain, but those Bitcoins will quickly be considered less valuable by market participants, resulting in a significant economic loss for the renegade miners. In other words, powerful economic incentives force miners to fall in line with the consensus of the entire community of participants. This interplay is a key reason the Proof of Work consensus mechanism is considered so powerful for ensuring Bitcoin isn’t hijacked by a contingent of participants who don’t represent the majority.