Bitcoin

Bitcoin Fork History: The Evolution of Protocol Changes

Since its introduction, the Bitcoin blockchain has received several proposals for change. In most cases, these proposals involve updates to its protocol rules through a mechanism known as a fork, which requires the network to either adopt new rules or retain the existing rules. At times, implementing these forks has often sparked debate within the community, and in some cases, even led to splits in the network.

This article explores key moments in Bitcoin's fork history, and how the focus has now shifted from trying to change Bitcoin's core protocol to building on top of it through Layer 2 solutions.

What is a Bitcoin Fork?

A Bitcoin fork is an intentional change or upgrade to its protocol rules. There are two main types of forks: hard forks and soft forks. The difference between them is backward compatibility or, simply, alignment with the existing rules.

A hard fork refers to a change to Bitcoin's protocol that requires all network participants to upgrade to the new rule set and reject the old ones. In most cases, this causes the blockchain to be separated into two distinct chains: the one that follows the new rules and the one that follows the old ones. More often than not, a hard fork leads to a new blockchain, as we will see later.
A soft fork, on the other hand, is backward compatible. This means it allows older nodes to continue participating in the network even if they do not upgrade to the new changes. It achieves this by tightening the existing rules rather than replacing them, ensuring that all blocks created under the new rules still appear valid to nodes running on the old rules. And as days go by, the older version slowly becomes obsolete as more participants upgrade to the newer version

As we know, there is no central authority that can dictate which changes are to take place on Bitcoin and which are not. Therefore, whenever there has been a proposal for changes through a fork to the Bitcoin blockchain, heated debates and occasional splits have erupted.

History of Bitcoin Forks

In the early days of Bitcoin, changes were activated through 'flag days', a method where developers (in particular, Satoshi Nakamoto) set and imposed a specific date when nodes would enforce new rules. Generally, these changes were adopted without much opposition.

Well, those were the Satoshi days, when users and miners were few and often the same people, and the main developer was one. But when Satoshi left in 2011, things really changed in a big way. To bring a change to Bitcoin, a consensus or simply an agreement must be reached amongst its community, and before it is reached, even 'wars' are fought…

The First Bitcoin War: The Battle For P2SH

Pay-to-Script-Hash (P2SH) was introduced by Gavin Andresen, who had then become the lead developer after Satoshi left. It was part of BIP 16 and proposed a change to Bitcoin transactions through the use of short addresses that hide the detailed rules for how coins can later be spent.

The change was to be in the form of a soft fork, and therefore it required majority backing in the community to signal their readiness to support it. At first, this seemed to satisfy everyone, but the world would not stay peaceful for long before another developer, Luke Dashjr, challenged its technical aspects and its philosophical implications for Bitcoin governance. In response, he even wrote his own version of P2SH called CheckHashVerify (CHV).

This sparked a war between developers in the Bitcoin Forum. The main concern was whether the lead developer should unilaterally select a proposal and ask miners to signal support, or if the process should be a democratic 'vote' between multiple competing proposals. After three months of heated arguments and competition, CHV had too little support, which forced Dashjr to reluctantly concede P2SH's dominance. With that, Andresen announced that the soft fork would be deployed and activated by April 1, 2012, which it did.

The Birth of Miner Activated Soft Fork

After the heated debates on P2SH, Gavin Andresen came back with another proposal, BIP34. This time, however, instead of having a pre-set date for activation (flag day), he took into account the opinion of miners, where activation required a 75% miner approval threshold to enforce the rule and 95% to make it mandatory. Luckily, the threshold was reached without major controversy, and the soft fork was successfully activated.

Although it was not a standardized method for activating protocol changes in Bitcoin, BIP 34's activation design set the stage for leveraging miners' hash power as a coordination mechanism. This design came to be termed a 'miner activated soft fork', or MASF. Born of this idea was BIP9, designed in 2015 as a standard framework for activating soft forks.

Its operation is very simple: after a soft fork is submitted, a signaling period is set. During this period, miners show support by setting a bit in their blocks. If 95% of blocks signal approval within a 2016-block period, the soft fork is locked in and activated after a short period. If the 95% threshold isn't met, the soft fork fails.

As proof of its success, BIP 9 succeeded in the activation of the CheckSequenceVerify (CSV) soft fork, which was locked in without a contentious public debate, and everything seemed calm. But oh, how wrong we would be to think so…

The Fork Wars of 2017

When everything seemed settled with a MASF, in 2017 a soft fork got close to expiring in its hands after miners refused to signal readiness for it. This soft fork was none other than the Segregated Witness (SegWit).

To understand where SegWit came from as a soft fork, allow me to take you back to the famous 'Bitcoin Block Size Wars'. This was a period where Bitcoin was looking to address its scalability problems caused by the 1MB block size limit. Out of this, emerged two camps:

One which proposed increasing the block size to large portions which caused a split in the network and we saw several Bitcoin hard forks like Bitcoin XT, Bitcoin Classic and Bitcoin Cash (BCH). And another which proposed a solution without altering the 1MB limit by separating transaction data from the signature data, where SegWit now came from.

In the end, SegWit won the hearts of many Bitcoin core developers and users, and therefore it was to be activated through BIP 9. For SegWit, however, BIP 9 did not play out smoothly, which takes us back to where we started by saying 'it came close to expiring'.

The main reason for this was that while BIP 9 was intended to signal technical readiness, some miners treated it as a political vote on the upgrade. They withheld their signals to gain leverage in the ongoing scaling debate or to benefit from existing inefficiencies in the network.

In response, developer Shaolin Fry proposed BIP148, a User Activated Soft Fork (UASF) that would enforce SegWit activation on a set 'flag day' without waiting for miners' approval. Faced with a possible loss of income, the obstructing miners conceded, and in August 2017, SegWit was activated. But for most Bitcoin developers, BIP 9 had exposed its flaws, and alternatives were needed.

The Calm Bitcoin War: Taproot Upgrade

After the drama behind the 2017 SegWit upgrade, it was largely debated whether Bitcoin could ever come to consensus on another soft fork. But four years later came another soft fork, known as the Taproot Upgrade.

Taproot as an upgrade by itself was a no-brainer to the Bitcoin protocol. Actually, by and large, the majority of core developers agreed with the changes it proposed in BIP340, BIP341, and BIP342. The controversy came in when the discussions started on how to activate it. Several proposals were put forward that circulated in the Bitcoin technical channels.

However, all these proposals revolved around using either BIP 8 or BIP 9. BIP 8 was a new activation method that took up the idea of BIP9 and added a new parameter called 'LOT' (Lock in on timeout), which can take the value of 'true' or 'false'. If this variable is set to 'false', BIP8 works in a similar way to BIP9, but if it is set to 'true', it automatically triggers a UASF if miners fail to signal.

To break the stalemate between the two camps arguing over how to set LOT (true vs. false), a new activation approach called Speedy Trial was introduced. It described a three-month activation window instead of the usual one year, with a 90% miner signaling threshold and a set activation height with no UASF. The goal was to let the soft fork either activate or fail quickly. In the end, Speedy Trial successfully activated Taproot at block 709,632 on November 14, 2021.

Building on a Stable Foundation

Realizing the huge difficulty and risk involved in changing Bitcoin's base layer (Layer 1), developers have now shifted to building new systems on top of it, which are what we call Layer 2 solutions or simply L2. Since the last Bitcoin soft fork to be activated, L2 projects building on Bitcoin have increased in different forms such as sidechains, rollups, and state channels.

These systems only use the base layer for its security and finalization while solving many Bitcoin scalability problems through fast transactions, issuance of new assets, smart contracts, and much more. They work very well because they are permissionless, and developers can experiment freely without the need for global consensus for every new feature. Also, their failures do not threaten the security of the main Bitcoin network; therefore, perhaps we can comfortably relax and say the fork wars are over for now.

Conclusion

Bitcoin has come a long way from the days of wars, debates, and divisions. But as it stands, we can perhaps say the dust is settling, and calmness is returning, all thanks to the new approach of bringing changes through layer 2 solutions. Therefore, as we scale, we can always look back and ascertain that this hard-won resilience is what gives Bitcoin its strength and is essential for its role as a global monetary asset.

Connect with Bitfinity Network

*Important Disclaimer: The information provided on this website is for general informational purposes only and should not be considered financial or investment advice. While we strive for accuracy, Bitfinity makes no representations or warranties regarding the completeness, accuracy, or reliability of the content and is not responsible for any errors or omissions, or for any outcomes resulting from the use of this information. The content may include opinions and forward-looking statements that involve risks and uncertainties, and any reliance on this information is at your own risk.

External links are provided for convenience, and we recommend verifying information before taking any action. Bitfinity is not liable for any direct or indirect losses or damages arising from the use of this information.

Bitcoin Fork History: The Evolution of Protocol Changes

What is a Bitcoin Fork?

History of Bitcoin Forks