One of the most controversial issues in Bitcoin over the past five years has been how soft forks are activated. Since the emergence of Bitcoin, various mechanisms have been used to implement new capabilities in this network. These mechanisms have evolved over time with the goal of making the implementation of new capabilities as safe and non-disruptive as possible.
Until 2017, while the activation mechanisms were changing, there was a general consensus about them and there was not much difference; But when SegWit was implemented, this consensus disappeared.
Segway became the site of controversy, and for the first time, debates arose over how to enable new features in Bitcoin. After the initial implementation of the BIP9 improvement plan, which required miners to send signals for implementation, almost all miners and mining pools refused to send signals in blocks.
At that time, many users were worried that miners would delay the activation of the new feature by requesting a hard fork to increase the block size and hold it hostage to their demands. This was while Segway was increasing the block size through a soft fork. In the meantime, the entire Bitcoin ecosystem was full of rumors based entirely on blatant lies to incite opposition to Segway’s promotion.
The BIP148 enhancement scheme and user-activated or user-driven soft fork (UASF) forced miners to activate Segway. In the meantime, one of the pressure streams to increase the block size was abandoned and another stream that had applied for the hard fork was finally abandoned.
However, Bitcoin fans have since generally shied away from talking about how to implement and enable new features. This topic has become so controversial that nothing remains to become a taboo.
In this article, with help a note Written from the Bitcoin Magazine website, we take a tour of the history of the proposals and implementation of Bitcoin activation mechanisms and examine some of the most important ones from the perspective of the author of this article. We invite you to stay with us until the end of this article.
Activate the Flag Day promotion
Activation can be phased; For example:
if (blocknumber > 115000) maxblocksize = largerlimit
this [بهروزرسانی] It can start from later versions; That is, when it came to this block number and [تغییر] applied to the network, other previous versions that do not have it will fail.
Bitcoin Talk, October 4, 2010
This quote by Satoshi Nakamoto dates back to the time after the original block size limit was implemented in Bitcoin. In this comment, he said how the size of the block can be increased in the future at the request of the users. It should be mentioned that at the beginning of Bitcoin’s launch, when users raised such a request, Nakamoto opposed it and in response to them said in the above sentences that it should not be done until it is not necessary. Nakamoto in his last comment about size block He stated that it is ultimately up to the users to decide whether to keep the block size constant or change it.
This update is called “Flag Day Activation” in which a block number or time stamp is selected and the updated nodes at that point implement the new rules.
There is no general signaling or observable coordination involved. People download the new client and anyone who has updated runs the rules and those who haven’t do nothing.
Read more: What is a node?
It is important to know that the meaning of flag day or days used in the topic of computer systems management is to make changes that require a restart of the system or a change in the size of its software or data.
The payment addresses were updated to the script hash or P2SH with this method. From a technical point of view and since during the flag day activations, the nodes on the activation network implement the new functionality and rules; Therefore, these activations are considered a form of UASF.
The problem with enabling flag days is that they don’t provide public signaling to tell what percentage of miners have implemented the new rules. For this reason, it is not possible for all users to measure the potential risks and the possibility of branching in the chain.
The goal of developing the BIP9 improvement plan was to reduce the risk of branching the chain when applying soft forks. The idea of the said plan was that miners include a signal in the blocks they mine and the new node software will start activating the new feature only when a certain percentage (about 95%) of the miners have given the signal to agree to that feature.
This makes it publicly known how many miners will implement the new feature before the new rules are implemented by the nodes. Of course, it is clear that miners can lie and send false signals; But the problem is that it is not rational to do this from the economic point of view. The CheckLockTimeVerify and CheckSequenceVerify functions were both implemented using the BIP9 scheme, and Segway was implemented at the same time.
The big drawback of using the BIP9 scheme, which was revealed when Segway was activated, was that a minority of miners could stop the activation of a feature by refusing to send a signal. Although it is possible to use other activation mechanisms for any scheme, the BIP9 scheme effectively veto It gives miners that they can use it to prevent the activation of a new feature on the network.
Hence, this activation mechanism (BIP9) gives miners disproportionate power to control new features in Bitcoin. This is despite the fact that miners are actually service providers for users and holders and should not have such an unlimited influence on the activation of features.
Upgrade BIP148 and UASF
The BIP148 design implemented a completely new and completely new activation mechanism that did not exist before. BIP148 was not designed to enable new functionality; Rather, it was supposed to make sure Segway, which was implemented in the BIP9 scheme, was activated.
This was also the reason for setting the deadline of August 1, 2017. August 1st was the last two-week difficulty adjustment period for signaling miners before Segway’s activation deadline. As of this date, all BIP148 clients are required to send a segway activation signal for all blocks in that time range.
This mechanism was a new activation scheme that was neither felt nor used before. BIP148 was actually done to fix what was considered a major flaw in BIP9. This defect came from the fact that there might be a consensus on a capability; But miners could stop the activation.
BIP91 is another unique activation scheme implemented in 2017 in connection with Segway. At the time, miners were reluctant to submit to the BIP148 plan; But at the same time, they were worried that the consequences of activating this plan without miners’ signaling would lead to the splitting of the Bitcoin blockchain. BIP91 was designed to provide a solution that avoids forks and keeps everyone on the same blockchain.
In this plan, a threshold of 80% was determined; In this way, if the number of miners sending Segway activation signal reached this level, then all the blocks without signals would be removed from the blockchain (like the BIP148 plan).
The purpose of this restriction was to ensure that if BIP91 were activated, it would maintain compatibility and synchronization with the BIP148 scheme. This would in turn enable segway enforcement via BIP9 and keep everyone on the same chain. Overall, the purpose of all these actions was to give miners an incentive or excuse to send an activation signal.
The BIP8 scheme was proposed to replace BIP9 due to what happened when Segway was activated. The plan was supposed to provide a mechanism for applying updates where once (90%) miners reach the signaling threshold, they can implement and apply the plan at any point in the activation timeframe.
Also, the BIP8 scheme was proposed with the aim of simultaneously being a mechanism to ensure that the fork is activated if a certain number of miners refuse to send a signal. This is the lockinontimeout variable. If the value of this variable is true, the consensus rules in the last signaling period require that all blocks “must” send an enable signal to ensure the activation of the new feature.
Speedy Trail upgrade
Speedy Trial has successfully completed Taproot activation. Taproot is the most important upgrade of the Bitcoin network since the block capacity increase in 2017 (2016), which we know as SegWit. To say the least, it was a very controversial choice among the many activation mechanisms.
Speedy Trial generally works like the activation mechanism of BIP9, with the difference that its activation time range is shorter and the miner signaling threshold is the same as the BIP8 scheme. One of the reasons for choosing Speedy Trial was so that if its consensus failed to activate, a version of BIP8 with the lockinontimeout=True variable could be released instead. In the eyes of many, the Speedy Trial was a step backwards in terms of refining the activation mechanisms.
Bitcoin promotion and the future
The 2017 SegWit activation failure revealed the ability of a small minority of miners to disrupt network consensus and implement functionality. This drawback had to be corrected by the simultaneous use of several different activation mechanisms, which were also very complex.
This was while the aforementioned mechanisms had complex interactions with each other. In the end, this work was successful despite its high risk; Although it could easily end in disaster.
From my point of view (the author of the note published in Bitcoin Magazine), the whole benefit of passing the BIP9 plan was to prevent such a feature from happening again. Some might argue that Speedy Trial’s success is due to its much shorter time frame before the activation range closes; But my argument is that it is not. Speedy Trial still carries the risk that activation will fail due to malicious behavior or unresponsiveness of a minority of miners. At the same time, this design implies that miners have the power to “veto” consensus among network actors.
I think that’s where the activation mechanisms end up in the long run. As Bitcoin continues to grow, more and more uninformed users join the ecosystem. In the process of getting to know Bitcoin, they will witness all these events, and most importantly, they will look at the activation mechanisms from the point of view of “What is going on here?” Who decides what gets activated?” What is the answer? Who are the developers, miners and companies?
If users conclude that miners are the decision-makers, most users’ views will lean towards the miners, and if they see the developers as the decision-makers, it will lean towards the developers. The current approach of Bitcoin fans to this issue will determine how future users approach and interact. Currently, there are different views on how to manage activation.
My point of view is that Bitcoin Core or miners should not play a role in applying new versions of activation or in a position where they have the power to disable or cancel activation. I think in the future all new functionality should be implemented in the network via UASF using the LOT=True variable in the BIP8 scheme.
The legacy we leave for the future must be a people’s organization. This organization should not be the product of a famous group that people see as arbiters who decide which features will be enabled in the Bitcoin protocol and which won’t.
We should not create the impression among new users that the developers decide what is done and what is not done.
This causes many standards to be created and maintained at the same high levels for implementing new changes, rather than being reduced to a situation where users submit to the decisions of experts. Activation can be applied through external clients.
This method allows us to temporarily use each “Activation Client” during the implementation of a new feature, and after successful activation, all return to Bitcoin Core. Thus, there is no need to maintain long-term clients outside Bitcoin Core, and the activation process is also removed from the shoulders of Bitcoin Core developers.
Some may say that this entails the risk of branching the chain during the soft fork. In response, the fact is that there is always a possibility of branching during a soft fork. By using the variable LOT=True, you can know the time of the possible fork before it occurs.
If the chain is to branch, it will happen at the end of the signaling period, i.e. when the first block without an activation signal is mined.
After all, Bitcoin is a market-driven system where consensus is achieved voluntarily. In my opinion, this is a process that trying to fix it out of chaos is a mistake and undermines the fundamental nature of the system.
At the same time, such efforts will inevitably lead to more centralized control and the creation of a decision-making system, taking Bitcoin’s consensus away from its decentralized nature.
However, this is just my personal view on the activation mechanisms in Bitcoin and there are different opinions on this. Finally, no one should hesitate to express their opinion. Now is the time to discuss it, not keep putting it off.