Bitcoin is a distributed payment system. By nature, no person or entity runs it. However, its protocol is sometimes modified to introduce new functionalities. These changes are generally made through a mechanism known as a “soft fork.”
To implement these soft forks in an optimal manner while maintaining the integrity of the current consensus, specific activation methods are used. These mechanisms, although sometimes unknown, play a crucial role in understanding the dynamics associated with changes in the Bitcoin protocol. In this article, we explore the various methods of activating soft forks used on Bitcoin.
What is the difference between a soft fork and a hard fork?
The Bitcoin protocol is something intangible in nature. It simply represents a group of unspoken rules, which allow different nodes to synchronize and form a network. All these nodes implement the protocol rules through software, the most used being Bitcoin Core.
When a change occurs on these protocol rules, this event is called a “fork”. Each node is then free to choose whether it wants to implement this fork, or if it refuses it. This is how consensus is sought for each modification of Bitcoin, without the need to call on a central authority.
There are two main types of forks: hard forks and soft forks. The difference between the two is the backwards compatibility of the update.
The hard fork changes the protocol by removing rules or making existing ones less restrictive, making it not backwards compatible with older nodes. It then causes the blockchain to be separated into two distinct chains: the one with the up-to-date nodes and the one with the old nodes.
The soft fork, on the other hand, changes the protocol by adding rules or making existing ones more restrictive. In this way, the new protocol remains backwards compatible with the old one and no chain separations are supposed to occur. On Bitcoin, except in exceptional cases, we prefer to use soft forks to modify the rules of the protocol.
The difficulty lies in the fact that, even with the use of a soft fork, there can sometimes be a separation of the blockchain into two branches. This scenario occurs when minors who did not update represent more than 50% of the network's computing power. In this case, the branching into two distinct chains persists as long as the chain that did not integrate the soft fork has more accumulated work than the chain that adopted it.
In order to preserve the unity of Bitcoin, we want to avoid such branches at all costs. To do this, miners will be asked to decide beforehand on their acceptance of a soft fork. While a large majority indicate their agreement to support it, the risks of a fork during the activation of the soft fork are considerably reduced. This process of consultation and prior consensus is called an “activation method.”
What is the difference between a UASF and a MASF?
We then differentiate between two categories of soft forks. When its implementation comes directly from users, this is called a “UASF” (User-Activated Soft Fork). This method occurs when network nodes choose to apply a soft fork by modifying their software, without waiting for the approval of miners. Generally used in emergency situations, especially when the majority of minors oppose the adoption of a soft fork, UASF is in reality a deterrent instrument allowing users to counter a potential abuse of power by minors. However, UASF is not without risks: it can lead to a blockchain branch, thus placing users who adopt it on a chain that is potentially of no economic value and less secure.
In a more consensual process, we prefer to use soft fork activation by minors. We then speak of a “MASF” (Miner-Activated Soft Fork). In this case, minors are allowed to give their approval for the modification of the protocol. When a large majority of them indicate their agreement to the deployment of the soft fork, the update is then validated and activated a little later. This method makes it possible to avoid the branching of the blockchain and to maintain the unity of the network.
As you can see, since there is no central planning on Bitcoin, each update can quickly become chaotic. The developers have thus proposed various activation methods in order to execute a soft fork while reducing the risk of breaking the Bitcoin consensus.
Informal activation methods
At the time of Satoshi Nakamoto, there was no formal procedure for activating soft forks. Satoshi himself made the changes, which were generally adopted without much opposition by a still small community. Sometimes, it didn't even announce them in advance, like when it unilaterally imposed a 1MB block size limit in 2010.
Among the first methods used, we also find the “Flag Day”. It consisted in setting and imposing a specific date to activate the soft fork. Although simple, this method is very rigid and does not allow for possible disagreements within the community to be considered.
After Satoshi left in early 2011, more formalized activation procedures began to emerge. The activation of BIP16, which introduces P2SH (Pay-to-Script-Hash), was at the center of one of the first major debates within the community. It was during this tense period that the first activation methods taking into account the opinion of minors were used.
After these debates on P2SH, Gavin Andresen proposed BIP34, which introduced an initial framework for activation methods. This approach made it possible to take into account the opinion of minors and to execute the soft fork once a certain approval threshold was reached.
Subsequently, other soft forks used similar methods, with activation windows extending over several weeks. However, there was still no standardized method for activating a protocol change. Activations were carried out more or less in line with the recommendations of the BIP34, but the latter did not take into account the signaling of several soft forks simultaneously.
Activate a soft fork with BIP9
The BIP9, designed in 2015 by Pieter Wuille, Peter Todd, Peter Todd, Greg Maxwell, and Rusty Russell, establishes a standard framework for activating soft forks, improving the initial concept of the BIP34. Its operation is very simple. When a soft fork is decided, the community submits it to the underage report. To do this, a start date and a maximum duration for the signaling are determined. During this time, miners can use a specific bit in the block version field to indicate their support for the soft fork.
As soon as 95% of the blocks report their approval over a fixed period of 2016 blocks, the soft fork is then locked. This period coincides with each adjustment in the proof-of-work difficulty. After this lockdown, a short period of time is given to miners to align themselves with the update, before the soft fork is actually executed. If the 95% approval threshold is not reached within the specified time, the soft fork is abandoned.
Compared to the BIP34, the BIP9 offers the possibility to report several soft forks simultaneously. However, it also has its drawbacks, including the fact that it is based entirely on a MASF, thus giving minors considerable power. Indeed, if the threshold of 95% signaling is not reached during the voting window, the proposed change is simply abandoned.
In particular, BIP9 was used to activate SegWit in 2017. As you probably know, things did not go according to plan. For months, a majority of minors refused to report their agreement with SegWit, despite the consensus of users.
Thus, BIP9 introduces a certain ambiguity into the governance of Bitcoin, leading miners to think that they control the activation of soft forks. In reality, their role is limited to signaling their readiness to adopt the new code, in order to avoid a branch of the blockchain. Despite the complexity of the subject, it is the users who exercise definitive control over the protocol, via their full nodes.
For this reason, developer Shaolin Fry proposed the BIP148 in March 2017, which allowed users to do a UASF. The aim was to impose SegWit on minors, without their consent. This initiative, which was widely supported by the community, put sufficient pressure on the miners, who, for fear of losing their income, finally approved SegWit through a more traditional signaling process.
The SegWit activation process thus turned into a fiasco and could have been a disaster for Bitcoin. For this reason, in 2017, Shaolin Fry and Luck Dashjr proposed BIP8, a new activation method that takes up the idea of BIP9 while adding an automatic UASF mechanism at the end of the voting period.
It specifies a new parameter called “LOT” (Lock in on time out), which can take the value of “true” or “false”. If this variable is set to “false”, BIP8 works in a similar way to BIP9. An approval window for minors is specified and, once the threshold is reached, the soft fork is locked. On the other hand, if the LOT parameter is set to “true”, BIP8 provides that if the required threshold is not reached at the end of the voting period, a UASF will be automatically triggered by the users. This mechanism aims to put pressure on miners to force the activation of the soft fork in the event of a blockage in the approval process.
BIP8 with LOT activated is therefore a much more aggressive method against minors. It leaves them with only two choices:
Be cooperative, and thus facilitate the activation process;
Be non-cooperative, in which case users do a UASF to enforce the soft fork.
BIP8 has also rectified some faults in BIP9. Instead of using time stamps to specify the voting period, he sets it to block heights. In this way, BIP8 eliminates the possibility of miners causing the hash rate on the network to drop sharply to skew the process. In addition, it adds the ability to freely determine the minimum voting threshold and introduces a parameter specifying a minimum block height, below which the soft fork cannot be activated. This setting gives minors time to prepare for the code change, while allowing them to signal their agreement in advance.
Activate a soft fork in Speedy Trial
The “Speedy Trial” process, proposed by David A. Harding in early 2021 based on an idea by Russell O'Connor, is a new activation method designed initially for the Taproot soft fork. It is based on the use of BIP8 with the LOT parameter set to “false”, but with a significant reduction in the activation window to only three months. In this way, the approval of minors can be verified very quickly. If the required threshold is reached during one of the periods, the soft fork is activated several months later, leaving enough time for miners to update their software. Although this method has not yet been formalized in a specific BIP, it was already used to activate Taproot in November 2021.
Despite its effectiveness for Taproot, which had a large consensus in the community, the Speedy Trial method is not necessarily the most suitable for all Bitcoin updates. Some developers express reservations about its future use, fearing that it would encourage a succession of soft forks too quickly and, therefore, that it could compromise the stability of the Bitcoin protocol.
The methods for activating soft forks on Bitcoin are evolving with new updates. It's a trial and error pattern that's quite similar every time: we define a standard activation method; we use it for the next big soft fork; it doesn't go as expected; so we define another standard by considering our past mistakes.
To date, there are mainly three activation methods:
BIP9, which allows minors to be asked for their approval before activating a soft fork;
BIP8, which is essentially like BIP9, but adds the possibility of automatic UASF if minors are not cooperative;
And the Speedy Trial, which is like BIP8, but with a very short voting period.
