The Bitcoin protocol is known for developing slowly, favoring predictability and compatibility over the prevalent Silicon Valley ethos of “move fast and break things.” Indeed, the Bitcoin network has not experienced an outage since March 2013. Yet the Bitcoin protocol is far from perfect, and the software interacting with the network is still a work in progress.
Yet how do we upgrade a network like Bitcoin, where all participants need to come to a full consensus about the rules and mechanisms? Without such a consensus, the network might split, or “fork,” into two or more interoperable chains. This has an impact on Bitcoin’s value, and can even “wipe out” coins you recently received.
Read more: ExpressVPN’s Comprehensive Bitcoin Glossary
Bitcoin Core, the most popular “full node” software, will soon release version 0.21. Data from the project’s Github repository shows between 20 and 100 commits to the code base every week from dozens of contributors. Most of these code changes impact only the functionality of your local software, not the network as a whole, but once in a while, these upgrades need to be rolled out too, and it’s not an easy process.
There is a lot of debate and disagreement over how to upgrade Bitcoin safely. Here’s why there will likely be challenges with the forthcoming upgrade:
Network forks and the consensus model
The Bitcoin network is made up of hundreds of thousands of nodes, each meticulously validating every single transaction in every single block, since the beginning of the Blockchain. Bitcoin miners have a strong incentive to only create blocks that follow these rules; after all, they wouldn’t want to have their blocks “dropped” after spending energy creating them.
In theory, you could change these rules in your own node freely. You could allow for larger blocks, more Bitcoin, or new signature schemes. If you can convince enough people around you to implement the same changes on their software (or simply run your version), you might succeed at splitting the network in half. One side will reject blocks created according to this new rule set, while the other side will accept them. The network has now “forked,” or more precisely, “split,” and is no longer in consensus about the rules. Such a split might be abandoned quickly, but it can also live on perpetually. The result: two separate cryptocurrencies, each with their own value.
Splitting the chain
We consider two factions, each controlling about half of the nodes and half of all Bitcoin miners. They are in disagreement over an arbitrary existing rule, for example the number of Bitcoin that can be newly created. The “limited” camp prefers the number of Bitcoin to be capped at 21 million, representing the status quo. The “inflation” group, however, argues that a small, predictable inflation is important for the functioning of the economy and health of the Bitcoin network, and they go ahead to configure their nodes to allow for up to 6 BTC to be created in each new block, forever.
While both groups consist of about half of the total miners, and in turn hash power, they will create about half of all blocks. Exactly how often, however, is up to pure chance. For those running the “limited” nodes, this is not a big problem. All blocks mined by these miners will be accepted by users, while all blocks mined by the “inflation” miners will be rejected. The network loses security and users and slows significantly, but there are no nasty surprises waiting for “limited” users.
Nodes running the “inflation” software, however, will accept not only the blocks created by their own miners, but they will also accept all blocks created by the “limited” nodes, as even though they contain fewer newly minted Bitcoin, they still formally abide by the rules of creating “up to 6 BTC.”
If due to luck, the “inflation” chain is longer than the “limited” chain, the network is split. But if the “limited” chain at some point becomes longer, then it will be accepted as valid by all “inflation” users as well, unwinding the chain and rendering all previously mined “inflation” blocks invalid. As each chain is inevitably going to be longer than the other at some point, and as this process can be repeated an infinite amount of times, the “infinite” chain can only survive by implementing additional rules that render blocks created under the old rule set as invalid, for example, requiring each block to contain “exactly 6 BTC.”
In popular usage a “network fork” is used to describe the event in which a chain or network splits into at least two groups, but more accurately describes only a proposed change in the consensus rules. In short, a network fork can lead to a chain split, but if well executed, will not.
Tightening and loosening the rules
There are two ways in which we can change the Bitcoin consensus rules:
- Tighten the existing rule set
- Loosen the existing rule set
The example above shows at first a looser rule set, because while the number of newly created Bitcoin will eventually drop to zero, the new rule allowed for “up to 6 BTC” to be created.
As shown above, expanding the rule set safely is not easy, and requires support from a vast majority of the network. To safely expand on the rule sets, it might be necessary to not only expand on the rule set, but to tighten it at the same time (e.g. tighten another rule). In any case, the old chain may continue to exist under the old rules. It is widely considered a beautiful characteristic of a blockchain that even a tiny super-minority maynot be able to be convinced to accept a change in rules.
Soft forks and hard forks
Loosening the rules, therefore, can be termed a “hard fork”, as it will almost inevitably lead to a split in the chain if the change goes ahead and is actively deployed.
When tightening the rules, the dynamic is different. In what we call a “soft fork,” all blocks created by the new nodes will be accepted by the entire network, and blocks created under the old rules will be rejected by the new nodes.
However, to upgrade a network by tightening its rules requires a lot of clever engineering, as the new rules that are added to the consensus protocol have to be more restrictive than the previous rules.
Previous additional features were added through soft forks, such as Segwit in 2017 and Check Lock Time Verify in 2015. The Segwit update made use of a trick using “anyone can spend” addresses. Such addresses exist (but aren’t used for obvious reasons) under the old rule set, and are greatly permissive in that they allow any miner to simply “take” the funds from them. Under the new rules, the funds from these addresses can no longer be spent by miners, but instead need to follow the new Segwit rules. This is safe as long as enough nodes validate these new rules.
To activate a soft fork, one in theory only needs a simple majority. The larger the majority, the smaller the chance of the legacy chain superseding the chain of the new rules. Exactly how large this majority needs to be is hard to say, and it’s more difficult is how to assess how large that majority is in practice.
How to safely activate soft forks
While there is the tendency to favor soft forks over hard forks, the latter inevitably leads to a chain split.
The previously favored methodology involves “miner signaling,” in which each miner “votes” in each block to activate the upgrade. Once a certain percentage (e.g., 75%) of blocks vote for the upgrade, it is “locked in” and activated 14 days later. This, however, gives miners a possibly unnecessary veto over upgrades, as seen in the 2017 scaling debate.
Another option is that of the “user activated soft fork,” or “flag day.” In this methodology users run software that requires the new rules to be followed after a certain time. If enough users take part, this threatens to split the chain. It’s unknown how many users—termed the “economic majority”—are required to avoid a chain split and pressure miners to only produce blocks according to the new rules.
Dangers of soft forks
A lot of dangerous protocol updates could be implemented through a soft fork, such as an upgrade that freezes Bitcoin accounts or requires senders and recipients to reveal their own transactions. If exchanges were mandated to run such modified software, would they represent an “economic majority” to render the network useless? [See also: How to destroy Bitcoin]
Next up: Part 2: The slow and challenging process of upgrading Bitcoin