Learn about Bitcoin

Bitcoin forks

Bitcoin forks are sometimes needed to bring new benefits to the network, so what makes them so controversial?

Learning a bit about how Bitcoin works on a technical level makes it easier to keep your funds safe for the long term. By running a full node or a miner, you also play a role in protecting the network itself from bad actors and making decisions like whether or not to implement the latest fork.

Forks are not inherently bad or good. They are a necessary process for implementing upgrades that expand Bitcoin’s capabilities, and can either split the blockchain in two (a hard fork) or continue on the same chain (a soft fork). Although forks can improve the network, they can also lead to devastating consequences like coin loss if rushed or badly implemented.

You may have already heard about Taproot or SegWit, the two latest soft forks that stirred up the community before eventually resolving to a consensus. With more forks being discussed, such as the BIP119 soft fork, let’s see why the community can become so divided when new forks are on the table.

Contents

How a fork works

In software development, the term fork is used when software is cloned in order to change the direction of a project. It can be modified to serve a different purpose or compete with the original project. A fork which stays compatible with the old version is called a soft fork, and one that breaks compatibility is a hard fork.

Bitcoin forks happen in order to change the rules of the network. To successfully fork, hundreds of thousands of computers must switch to a new version with the new rules enabled. This takes coordination and there are several Bitcoin Improvement Proposals (BIPs) related to the process, such as BIP9 which outlines a soft fork signaling process where miners can show they support a proposed fork before activating it.

Forks depend on people accepting and using them, otherwise they are considered contentious forks, as not everyone is following the same rules, weakening the network. In general, the fork with the greatest support wins. In the case of hard forks, they force those on the wrong chain to switch or continue mining an abandoned and mostly worthless chain.

Hard forks are to be avoided wherever possible, and approached with extreme caution when necessary. Bitcoin transactions form an unchanging history stretching all the way back to the genesis block, and confirmed transactions can not be changed without messing up every transaction that came after it. Through a hard fork, those transactions could be reordered to steal funds.

Bitcoin has been hard-forked several times in the past, resulting in various spin-off cryptocurrencies, but only once was it forked in order to reverse transactions.

The difference between a soft and hard fork

Forks are defined as hard or soft, depending on whether they continue to work with the existing network. A hard fork changes the rules so much that nodes who don’t upgrade won’t see the new blocks as valid, while blocks produced after a soft fork will still be accepted by the existing network. Successful hard forks result in a chain split and a new currency being created.

Hard forks

When a hard fork happens, users (node operators and miners) need to decide which chain they will support going forward. This can cause much of the original network’s hashrate to fall away, weakening it against attack. If a majority of users choose to support one chain, it is generally considered to be the winning fork, but both chains may continue to coexist indefinitely.

Examples of hard forks include Bitcoin Gold, Bitcoin Cash, and dozens of other attempts at changing how bitcoin works. In every case, these hard forks resulted in a new currency being created by cloning the Bitcoin blockchain and issuing new coinbase rewards to miners that supported the forked chain. The new coins created through this process are not compatible with the original chain.

Soft forks

A soft fork is backwards-compatible and does not create a new currency. Nodes running the new version of the software can still communicate with nodes on older versions. New blocks are seen as valid by both new and old nodes, but older clients must abide the new rules for a transaction to be valid.

Only a majority of the network needs to upgrade to activate a soft fork, not the whole network, but more support reduces risk of users failing to adopt it, which is why the threshold for Taproot activation during Speedy Trial was set to 90% of blocks signalling and other similar mechanisms specify 95%.

Soft forks are the preferred method for implementing upgrades as they allow the network to continue running smoothly even if some nodes do not upgrade. For a decentralized system, it should be taken for granted that some participants will either choose not to upgrade, or simply not learn about the upgrade until much later.

Bitcoin hard forks and why they happened

Hard forks are a tool which were deployed on several occasions in Bitcoin’s early days to fix catastrophic issues, and in order to create new cryptocurrencies to compete with Bitcoin. Here we’ll just cover the interesting cases.

In 2010, Bitcoin hard-forked in order to fix an exploit which created over 90 billion bitcoin. This roll-back fork was a matter of patching the issue and then using a forked version of the blockchain from before the exploit happened, also reversing any transactions that came after it. This would have been a big problem for anyone who sent or received a transaction at the time, or mined any blocks, but ultimately avoided the complete collapse of the network.

In 2013, an accidental hard fork was caused when many miners upgraded to a new, incompatible version, and started mining a forked blockchain. This meant that miners who did not upgrade were continuing on the original chain, while the ones who upgraded were building a new chain excluding the other groups’ blocks. This was fixed by reverting to the older version and abandoning the forked one. Read the full post-mortem in BIP50.

Both these hard forks happened for different reasons. While the resolution was quick, they would both have resulted in failed transactions and potentially coin loss for users on the wrong side of the fork. In these cases, hard forks reduced the damage that could have been caused by bugs and exploits. In that capacity, they are a very effective tool, but they can cause a lot of collateral damage to users in the process.

When is a fork needed?

Forks are a necessary way to upgrade Bitcoin. Without them, there would be no lightning network, for example, which was dependent on the segregated witness (SegWit) soft fork. As long as forks are backwards-compatible (i.e. soft forks), users have the option to continue without upgrading, without causing a chain split. This ensures network upgrades are democratized and no-one is forced to adopt a new ruleset which they do not agree with.

Activating a fork comes at the risk of destabilizing the network. Hard forks can be a last resort for truly catastrophic issues but they undermine the trust of the network. Soft forks are less significant as they don’t disrupt the state of the network, but can still introduce problems. Being able to opt-out should prevent undesirable upgrades from being adopted by the majority, but there can be many political and human aspects involved that make it important to be cautious with any proposed fork.

What is a UASF (user-activated soft fork)?

Activating a fork is complicated by Bitcoin’s decentralized nature. A user-activated soft fork (UASF) is a process where a fork is pushed through by users running full nodes, rather than the mining nodes who are often mistakenly seen as the network’s governance council. It requires consensus of thousands of full nodes switching to the forked version until they take over the network majority, and with enough support a UASF can decide the network’s future without mining nodes’ agreement.

User-activated soft forks democratize the upgrade process. While signaling for SegWit was expected to come from miners as described in BIP148, it ultimately failed to activate based on miners’ consensus alone. Instead, the community rallied around the idea that by upgrading their nodes they could push through SegWit themselves. While the UASF ended up not to be needed, the SegWit upgrade was ultimately adopted by a majority through BIP91.

Taproot, last year’s follow-up to SegWit, used a similar voting mechanism known as Speedy Trial, but in that case the miner signalling process was a success and no UASF was required. While the first few rounds of voting failed, it only took a couple of months for the Taproot soft fork to be accepted, possibly influenced by the knowledge that a UASF would be able to overturn miners’ decisions.

It should be noted, however, that some miners who signaled their support later failed to implement Taproot, causing issues with incompatible addresses. Community pressure remains highly important to ensure resistance against bad actors and a UASF is an important tool for keeping the network democratic.

Speedy Trial and finding consensus

With last year’s Taproot upgrade, a process known as a Speedy Trial was put in place before the fork, to allow miners to signal their agreement to upgrade. The signal is given by changing the version bit of newly-mined blocks from 0 to 1.

Once a majority of over 90% of miners had signaled their support within the set two-week timeline, it indicated that the new version, the soft fork, would be adopted by all of them once it rolled out and its new rules would begin being enforced.

The Speedy Trial process is a way to avoid long delays between an upgrade being developed and its adoption by network participants. It is simply an organized attempt at activation that allows miners a short period during which the proposed implementation can be accepted or rejected, and in case of rejection a new set of parameters can be proposed and the signalling period can restart.

The BIP119 soft fork (OP_CTV)

The Speedy Trial process was implemented to ensure that a decision is made in a timely manner for implementing proposals with widespread support. BIP119 introduces a new way to add spending conditions to bitcoin transactions, by introducing an OP code known as OP_CTV (Check Template Verify). This is expected to happen by Speedy Trial, following from Taproot’s success.

A lack of certainty over how the new features of BIP119 may be used has led to resistance to implementing it, while proponents are being accused of trying to rush the process and over-emphasizing support within the industry. Read more about it in the below newsletter.

The release of a new client including the OP_CTV mechanism, and initiation of the Speedy Trial process, marks the start of a soft fork. Anyone running the new client will be supporting BIP119 as a network upgrade, and if a large enough number of miners adopt this client, OP_CTV would be officially recognized as part of bitcoin. Users could still decide not to upgrade, but the health of the network may suffer if an upgrade is not widely supported.

BIP119 is not fundamentally controversial, but the approach taken to deploy it has been seen as uncharacteristically impatient for bitcoin. Each new upgrade that the network undergoes has been unique in its own way, so it is only natural that BIP119 faces some resistance. Ultimately, it comes down to miners and node operators trying to preserve their own self-interests, which means making compromises until both camps are in agreement. Decentralized dispute resolution is not meant to be easy, but it will eventually reach a judgment that fits majority consensus.