Previously we discussed why upgrading Bitcoin is so difficult. Bitcoin is a network that’s reliant on full consensus of all participants, so it is notoriously difficult and often highly controversial to propose new changes and features.
On the contrary, this can be perceived as a strength of the network, as it is likewise difficult to push through changes against the will of a conservative community.
[Can’t get enough on Bitcoin? Sign up for the ExpressVPN blog newsletter.]
Even non-controversial changes can be difficult and dangerous to roll out. Any upgrade to the consensus rules could cause the chain to split, leading to uncertainty and disruption to the network, even making it hard to safely transact. This happened in November 2020 to the Ethereum network, where an “unannounced hard fork” split the chain and caused providers of critical infrastructure to go offline.
Step 1: The idea
In Bitcoin, there is no formal mechanism for how to propose and implement new features, but there are some conventions. It usually begins in informal discussions among Bitcoin developers. Anybody can be a Bitcoin developer, and you do not need to work on Bitcoin’s “official” software client, Bitcoin Core, to be considered a Bitcoin developer.
In a broader sense, you might not even need to work directly on Bitcoin to be considered a Bitcoin developer. Plenty of systems rely on Bitcoin or build on top of it, and its developers would still be considered “Bitcoin Devs.” Even contributors to systems very similar to Bitcoin could claim this title for them.
There are plenty of channels where developers meet, exchange ideas, and propose changes. The most visible is Twitter, although Reddit also still plays a role among the open platforms where anybody can post and read. Then there are semi-open platforms where anybody can read, but you will need an invitation to post or have your comment reviewed by an existing member. The two most popular of these forums are the Bitcoin Dev mailing list and the IRC channels. Finally, there are countless smaller invitation-only chat groups on Telegram, Slack, Discord, or Mattermost, often dedicated around specific platforms, ideas, or techniques.
Ideas are often developed by groups of people through discussions. Some discussions are more formal, such as the mailing list, while others are very open, like on Twitter. A good idea will draw a lot of criticism, but also interest. It can make sense to present this idea in both formal and informal channels, and to gather those interested in a medium of your own.
Step 2: The proposal
The “Bitcoin Improvement Proposal” is as close as a proper standard Bitcoin has to formulate changes. A “BIP” will outline the need for the proposal, how exactly it will work, and depending on the proposal, how it can be deployed.
Not all proposals will require a BIP to become deployed as code. BIPs are specifically for mechanisms that affect the consensus-relevant part of the Bitcoin protocol, i.e., those that could lead to a chain split. BIPs, however, often also concern other parts of the Bitcoin network that require coordination, or that affect how other software interacts with Bitcoin. Good examples of such BIPs are BIP39, which is on how to create mnemonic seeds; and BIP21, on how to create Bitcoin URIs.
Since 2018, there has even been a BIP about how to make BIPs. It makes for an interesting read and also classifies existing BIPs by the “layers” of the Bitcoin network they affect.
Step 3: The discussion
If your idea generates interest on the mailing list and chat groups and your BIP has been accepted and assigned a number, people will take it a lot more seriously. You might already get some coverage in Bitcoin media for it or be invited to a conference to present your proposal. If your BIP has not yet been accepted, media coverage or a presentation might also help give it that extra boost.
Most likely, your document will remain in draft status for a while as suggestions for improvements come in or potential errors may be found.
Step 4: The coding
Almost all ideas for how to upgrade Bitcoin will require some code work. This tends to be done on the Bitcoin Core codebase by multiple individuals, possibly but not necessarily led by the person initially proposing the change.
It is entirely possible, however, that the idea is first implemented as code on peripheral software, or even another blockchain, from where it is ported back to Bitcoin.
No matter how the code finds its way into Bitcoin, you can expect it to be heavily vetted and reviewed by multiple people before it is “merged” into the code and becomes part of a future release.
Step 5: Deployment
As discussed in the previous article, upgrading Bitcoin is hard, and the risk of a chain split is not something that the community takes lightly. So it comes to no surprise that the deployment methodology is a highly contentious point in the discussion process. Some BIPs, such as BIP148 and BIP149, exclusively deal with the activation methodology of other BIPs, while a BIP like BIP99 deals with the terminology.
Even before a new proposal is activated, it is already included in a previous release of the software. As users update their software slowly, it is better if the network already has an understanding of rules before they are activated and if as many nodes as possible are able to validate the new rules.
As discussed previously, the so-called soft forks are favored over hard forks, but there are a few popular ways to deploy a soft fork safely.
Flag day
A flag day is usually a block height—a specific block in the future at which the rules will come into effect. This creates certainty for when a proposed rule change will become active and when a new feature will become available, but it gives no feedback mechanism on how risky this upgrade may be. In the worst case, few users have adopted software that validates the new rules, and a chain split becomes possible.
Mining activation
Using a small field in the block header, each miner is given the option to vote for the new proposed rules. Once a certain percentage of miners indicate their support for these rules, the proposal gets locked in and is activated shortly afterwards. Unlike the flag-day activation, it gives more certainty as to how likely a chain split may be, though of course the miners could be signaling support for the new rules without having upgraded their software, maliciously or out of laziness.
The main disadvantage of mining activation is that it gives miners the ability to veto proposed upgrades. Whether miners should be given this veto was a controversial topic in 2017, when Bitcoin activated a soft fork for the last time as part of the Segwit feature.
UASF (BIP148)
The User Activated Soft Fork was a peculiar proposal to eliminate the mining activation mechanism of the Segwit upgrade. Running this code meant to invalidate all blocks that did not signal for the upgrade. If run by very few people, this would have little effect, but if run by many people would inevitably lead to a chain split. UASF might have contributed to the activation of Segwit but the code never came into action.
What makes a good upgrade idea?
Most ideas on how to upgrade Bitcoin never turn into solid proposals, and many proposals never turn into code, and not all code is eventually run by the network. Whether your idea will find its way up the chain into the latest blocks depends on how much it will improve Bitcoin, what risks it carries, and how safely it can be tested and deployed.
Read more: How to set up a home server and use it as a Bitcoin node
