The history of Bitcoin upgrade activation mechanisms informs an opinion on how to make protocol changes in the future.
One of the most contentious questions in Bitcoin over the last five years has been how to activate soft forks. There have been many different mechanisms used in the history of Bitcoin to activate new features on the network, the iteration of which has generally evolved with the goal of making feature deployment as safe and non-disruptive as was possible. Until 2017, there was general consensus and not much disagreement as activation mechanisms changed, but during the deployment of Segregated Witness (SegWit), this changed.
SegWit became the issue that drove disagreement and contention over how features should be activated on Bitcoin for the first time. After the initial BIP9 deployment, dependent on miner signaling to lock in enforcement rules, a large majority of miners and mining pools refused to signal for activation with their blocks. At the time, many users became furious that miners were delaying the activation of a new feature and holding it hostage with demands for a hard fork to increase the block size (when, I might add, SegWit accomplished a block size increase through a soft fork), and the entire ecosystem was filled with completely inaccurate information about SegWit in an attempt to drive opposition to the feature itself based on outright lies.
BIP148 and the user-activated soft fork (UASF) wound up pushing miners to activate SegWit, and one of the big block pushes was called off, leaving the other to fork and eventually crash into irrelevance. But since then, Bitcoiners have generally avoided having the conversation about how new features should be deployed and activated. The topic has become contentious to the point of almost being a taboo.
I think it’s worth going through a high-level tour of some of the past activation mechanisms proposed and used before getting into how I personally think upgrades should be handled going forward. Note that these mechanisms can be used for both hard forks or soft forks, the only difference is that a chain split is guaranteed with a hard fork, and only possible in a soft fork if things go wrong.
Flag Day Activation
“It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.”
This is the infamous quote by Satoshi Nakamoto after they implemented the original block size limit, speaking to how it could eventually be increased in the future if users deemed it necessary. (It’s worth noting as well that when people called for it early on, Nakamoto was against the idea, and specifically responded with the above quote as to why it shouldn’t be done until needed. The last comment Nakamoto ever made on the issue of block size, found here, also explicitly acknowledged it was ultimately the choice of the users whether or not to do so.)
This is a “flag day activation,” where a block height or timestamp is selected, and upgraded nodes simply start enforcing new rules at that point. There is no public signaling or visible coordination, people simply download the new client and everyone who has upgraded starts enforcing at the chosen time, and those who have not upgraded do not.
This is how pay to script hash (P2SH) was activated. Flag day activations are, technically speaking, a form of user-activated soft fork, given that it is the nodes on the network committing to activation of a new feature and enforcing its rules. The problem with flag days is that they provide no public signal indicating what percentage of miners claim to be enforcing new rules, so that everyone can gauge the potential risk and likelihood that a chain split will occur. Flag days have not been used in some time.
BIP9
BIP9 was developed in order to further decrease the risk of chainsplits in the deployment of soft forks. The idea behind it was having miners include a signal in the blocks they mine, with new node software only triggering the activation of new features if a threshold (95%) of miners in a difficulty period are signaling to activate the feature. This would give a public indication of how many miners were enforcing the new feature before nodes began enforcing the new rule. Obviously, miners could lie and signal falsely, but the idea was that there is no economically-rational reason to do so. CheckLockTimeVerify and CheckSequenceVerify were both deployed using BIP9, and the original Segregated Witness implementation was deployed with it as well.
The big downside of a BIP9 deployment, as evidenced by SegWit, is that a minority of miners can stall the activation of a feature by refusing to signal. Without deploying something a second time using a different activation mechanism, BIP9 gives miners a de facto veto where they can prevent a new feature from activating on the network. This activation mechanism therefore gives miners a disproportionate control over what is added to Bitcoin; miners are service providers to users and HODLers, and therefore should not have such oversized influence in feature activation.
BIP148 And UASF
BIP148 set a huge precedent as well as implemented a novel activation mechanism never seen before; it was not designed simply to activate a feature in its own deployment, but also guarantee the activation occurred for the prior BIP9 deployment of SegWit. This was the reason for the August 1 deadline. Beginning August 1, the last two-week difficulty adjustment period for miner signaling before the SegWit activation window ended, BIP 148 clients enforced by consensus the requirement that all blocks in that last window signaled for SegWit activation.
This mechanism was a novel activation design not previously needed or used, and was situationally done to correct what was viewed as a major shortcoming of BIP9: the ability of miners to stall the activation of features that otherwise had consensus.
BIP91
BIP91 is another unique activation scheme deployed in 2017 in relation to SegWit. Miners at the time were unwilling to cede to the ultimatum of BIP148, but at the same time were worried about the consequences to Bitcoin if BIP148 activated without miners signaling and causing Bitcoin to split into two parallel blockchains. BIP91 was created in order to find a compromise that would keep everyone in sync on the same blockchain.
It established an 80% threshold, where if that many miners signaled in a difficulty period to activate SegWit, it would start orphaning all blocks that were not signaling (similar to BIP148). The goal was to guarantee that if BIP91 activated, it would stay in sync and compatible with BIP148, which would then trigger the original BIP9 deployment of SegWit, keeping everyone on the same chain. The entire purpose was to give miners an excuse to “be the ones to trigger activation.”
BIP8
BIP8 was the proposed mechanism to replace BIP9 due to the situation that occurred during SegWit activation. The design goal was to have a deployment mechanism where miners reaching a threshold of signaling (90%) could activate the proposal at any given point in the activation window, but to create a mechanism where it was possible to guarantee that a fork is activated if enough miners refuse to signal.
That is the “lockinontimeout” variable. If it is set to true, then in the last signaling period consensus rules will enforce that all blocks in that period must signal for activation, just like BIP148, to guarantee that the new feature activates.
Speedy Trial
Speedy Trial was how Taproot wound up being successfully activated. It was a highly contentious choice of activation mechanisms to say the least. At the end of the day, Speedy Trial functions like a BIP9 activation deployment, except that the activation window is much shorter and the signaling threshold is the same as with BIP8 (90%). Part of the rationale for using Speedy Trial was that if something with consensus failed to activate, a BIP8 LOT=True deployment could be released afterwards.
Many people, myself included, viewed Speedy Trial as a step backwards in terms of refining feature activation mechanisms.
What Now?
The SegWit activation fiasco in 2017 demonstrated the ability of a small minority of miners to interfere with network consensus and feature deployment, which had to be corrected through an incredibly convoluted deployment of multiple different activation mechanisms simultaneously that had complicated incentive interactions between all of them. This was an incredibly risky situation that thankfully worked out in the end, but it very well could have gone disastrously.
In my opinion, the entire point of moving past BIP9 was to avoid recreating the potential for such a situation again. Some would argue that Speedy Trial does so because of a much shorter timeframe before an activation window closes, but I would argue it does not. It still presents the risk of an activation failing due to the maliciousness or lack of response from a minority of miners, and importantly, presents the impression on a social level that miners are capable of “vetoing” consensus among other network actors.
That is what I think activation mechanisms boil down to in the long term. As Bitcoin continues growing, more and more uneducated users are going to be entering the ecosystem. In that learning process, they will be observing everything going on, and most importantly, they will be looking at activation mechanisms through the lens of, “What is going on here, who is deciding whether something activates or not?” Developers? Miners? Businesses? This is the question, and these are the answers, that I think most new users will have running through their heads when we go to deploy new features and upgrades on the network.
The answers people will arrive at ultimately will become a self-fulfilling prophecy in this regard, if users wind up seeing miners as the decision makers, then most users will look to miners. If users wind up seeing developers as the decision makers, they will look to developers. How Bitcoiners approach this question now will set precedent for how future users handle things. There are lots of different opinions on how activation should be handled, but in the interest of not putting words in other peoples’ mouths, I’m going to stick with just describing mine.
I do not think Bitcoin Core or miners should be involved in the activation process in the role of either deploying new activation releases, or in a position where they are capable of vetoing or stalling something from activation. Going forward, I think all new features deployed through a UASF using BIP 8 LOT=True. I think it is important that the precedent we set going into the future is one of grassroots organization that does not consistently come from an identifiable group being seen as the arbiters of what features are or are not activated in the Bitcoin protocol.
If, going forward, we set the precedent of people outside of Core being the ones to propose activation, we set the precedent of a higher level of skepticism toward change in general. We avoid creating the social perception for newer users that developers decide what does or does not happen. This would set a very high bar for enacting new changes, and ensure that bar remains high instead of devolving into a dynamic of users deferring to experts to decide what happens. Activations can occur through outside clients, with the next Core release activating new features if they have successfully been activated through patched clients.
This can allow each “activation client” to be used temporarily during a feature deployment, with everyone switching back to Core after a successful activation, preventing the need to maintain long lived clients outside of Core while still removing the process of activation from Core developers.
Some might argue this creates a risk of chain splits during soft forks, but the reality is that chain splits are always possible during a soft fork. With LOT=True, the point at which a fork will occur will be known ahead of time if one were to occur. If the chain is going to split, it will occur during the final signaling period of the activation when the first block not signaling for activation is mined. This defines a consistent and predictable time period in which it will occur if it does, as opposed to any arbitrary point after activation when some miner not enforcing the new rules mines a block violating that rule.
If there truly is consensus for a new feature, then the majority of the economy will be running a client to activate it, and such a chainsplit will be a minor disruption and inconvenience. If there is no consensus for a new feature, then again such a chainsplit should be no more than a minor disruption and inconvenience as a tiny minority forks themselves off the network. They will be left with the decision to continue using a minority fork chain or relent and return to the Bitcoin network.
Bitcoin is ultimately a market-driven system, where consensus is arrived at voluntarily. I believe attempts to prevent that process from becoming messy are both misguided, missing the fundamental nature of the system, and will inevitably lead to more centralized social control and perception of top-down decision making if people constantly try to remove the mess from arriving at consensus. We should embrace that process, and stop trying to control it.
At the end of the day, this is simply my personal opinion on how things should be done, and there are many more diverse opinions out there. People shouldn’t be hesitant to voice their opinions on this matter. It’s time for us to start having this conversation instead of constantly putting it off, and letting the inertia of social dynamics slowly make the decision for us.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
One of the most contentious questions in Bitcoin over the last five years has been how to activate soft forks. There have been many different mechanisms used in the history of Bitcoin to activate new features on the network, the iteration of which has generally evolved with the goal of making feature deployment as safe and non-disruptive as was possible. Until 2017, there was general consensus and not much disagreement as activation mechanisms changed, but during the deployment of Segregated Witness (SegWit), this changed.
SegWit became the issue that drove disagreement and contention over how features should be activated on Bitcoin for the first time. After the initial BIP9 deployment, dependent on miner signaling to lock in enforcement rules, a large majority of miners and mining pools refused to signal for activation with their blocks. At the time, many users became furious that miners were delaying the activation of a new feature and holding it hostage with demands for a hard fork to increase the block size (when, I might add, SegWit accomplished a block size increase through a soft fork), and the entire ecosystem was filled with completely inaccurate information about SegWit in an attempt to drive opposition to the feature itself based on outright lies.
BIP148 and the user-activated soft fork (UASF) wound up pushing miners to activate SegWit, and one of the big block pushes was called off, leaving the other to fork and eventually crash into irrelevance. But since then, Bitcoiners have generally avoided having the conversation about how new features should be deployed and activated. The topic has become contentious to the point of almost being a taboo.
I think it’s worth going through a high-level tour of some of the past activation mechanisms proposed and used before getting into how I personally think upgrades should be handled going forward. Note that these mechanisms can be used for both hard forks or soft forks, the only difference is that a chain split is guaranteed with a hard fork, and only possible in a soft fork if things go wrong.
Flag Day Activation
“It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.”
This is the infamous quote by Satoshi Nakamoto after they implemented the original block size limit, speaking to how it could eventually be increased in the future if users deemed it necessary. (It’s worth noting as well that when people called for it early on, Nakamoto was against the idea, and specifically responded with the above quote as to why it shouldn’t be done until needed. The last comment Nakamoto ever made on the issue of block size, found here, also explicitly acknowledged it was ultimately the choice of the users whether or not to do so.)
This is a “flag day activation,” where a block height or timestamp is selected, and upgraded nodes simply start enforcing new rules at that point. There is no public signaling or visible coordination, people simply download the new client and everyone who has upgraded starts enforcing at the chosen time, and those who have not upgraded do not.
This is how pay to script hash (P2SH) was activated. Flag day activations are, technically speaking, a form of user-activated soft fork, given that it is the nodes on the network committing to activation of a new feature and enforcing its rules. The problem with flag days is that they provide no public signal indicating what percentage of miners claim to be enforcing new rules, so that everyone can gauge the potential risk and likelihood that a chain split will occur. Flag days have not been used in some time.
BIP9
BIP9 was developed in order to further decrease the risk of chainsplits in the deployment of soft forks. The idea behind it was having miners include a signal in the blocks they mine, with new node software only triggering the activation of new features if a threshold (95%) of miners in a difficulty period are signaling to activate the feature. This would give a public indication of how many miners were enforcing the new feature before nodes began enforcing the new rule. Obviously, miners could lie and signal falsely, but the idea was that there is no economically-rational reason to do so. CheckLockTimeVerify and CheckSequenceVerify were both deployed using BIP9, and the original Segregated Witness implementation was deployed with it as well.
The big downside of a BIP9 deployment, as evidenced by SegWit, is that a minority of miners can stall the activation of a feature by refusing to signal. Without deploying something a second time using a different activation mechanism, BIP9 gives miners a de facto veto where they can prevent a new feature from activating on the network. This activation mechanism therefore gives miners a disproportionate control over what is added to Bitcoin; miners are service providers to users and HODLers, and therefore should not have such oversized influence in feature activation.
BIP148 And UASF
BIP148 set a huge precedent as well as implemented a novel activation mechanism never seen before; it was not designed simply to activate a feature in its own deployment, but also guarantee the activation occurred for the prior BIP9 deployment of SegWit. This was the reason for the August 1 deadline. Beginning August 1, the last two-week difficulty adjustment period for miner signaling before the SegWit activation window ended, BIP 148 clients enforced by consensus the requirement that all blocks in that last window signaled for SegWit activation.
This mechanism was a novel activation design not previously needed or used, and was situationally done to correct what was viewed as a major shortcoming of BIP9: the ability of miners to stall the activation of features that otherwise had consensus.
BIP91
BIP91 is another unique activation scheme deployed in 2017 in relation to SegWit. Miners at the time were unwilling to cede to the ultimatum of BIP148, but at the same time were worried about the consequences to Bitcoin if BIP148 activated without miners signaling and causing Bitcoin to split into two parallel blockchains. BIP91 was created in order to find a compromise that would keep everyone in sync on the same blockchain.
It established an 80% threshold, where if that many miners signaled in a difficulty period to activate SegWit, it would start orphaning all blocks that were not signaling (similar to BIP148). The goal was to guarantee that if BIP91 activated, it would stay in sync and compatible with BIP148, which would then trigger the original BIP9 deployment of SegWit, keeping everyone on the same chain. The entire purpose was to give miners an excuse to “be the ones to trigger activation.”
BIP8
BIP8 was the proposed mechanism to replace BIP9 due to the situation that occurred during SegWit activation. The design goal was to have a deployment mechanism where miners reaching a threshold of signaling (90%) could activate the proposal at any given point in the activation window, but to create a mechanism where it was possible to guarantee that a fork is activated if enough miners refuse to signal.
That is the “lockinontimeout” variable. If it is set to true, then in the last signaling period consensus rules will enforce that all blocks in that period must signal for activation, just like BIP148, to guarantee that the new feature activates.
Speedy Trial
Speedy Trial was how Taproot wound up being successfully activated. It was a highly contentious choice of activation mechanisms to say the least. At the end of the day, Speedy Trial functions like a BIP9 activation deployment, except that the activation window is much shorter and the signaling threshold is the same as with BIP8 (90%). Part of the rationale for using Speedy Trial was that if something with consensus failed to activate, a BIP8 LOT=True deployment could be released afterwards.
Many people, myself included, viewed Speedy Trial as a step backwards in terms of refining feature activation mechanisms.
What Now?
The SegWit activation fiasco in 2017 demonstrated the ability of a small minority of miners to interfere with network consensus and feature deployment, which had to be corrected through an incredibly convoluted deployment of multiple different activation mechanisms simultaneously that had complicated incentive interactions between all of them. This was an incredibly risky situation that thankfully worked out in the end, but it very well could have gone disastrously.
In my opinion, the entire point of moving past BIP9 was to avoid recreating the potential for such a situation again. Some would argue that Speedy Trial does so because of a much shorter timeframe before an activation window closes, but I would argue it does not. It still presents the risk of an activation failing due to the maliciousness or lack of response from a minority of miners, and importantly, presents the impression on a social level that miners are capable of “vetoing” consensus among other network actors.
That is what I think activation mechanisms boil down to in the long term. As Bitcoin continues growing, more and more uneducated users are going to be entering the ecosystem. In that learning process, they will be observing everything going on, and most importantly, they will be looking at activation mechanisms through the lens of, “What is going on here, who is deciding whether something activates or not?” Developers? Miners? Businesses? This is the question, and these are the answers, that I think most new users will have running through their heads when we go to deploy new features and upgrades on the network.
The answers people will arrive at ultimately will become a self-fulfilling prophecy in this regard, if users wind up seeing miners as the decision makers, then most users will look to miners. If users wind up seeing developers as the decision makers, they will look to developers. How Bitcoiners approach this question now will set precedent for how future users handle things. There are lots of different opinions on how activation should be handled, but in the interest of not putting words in other peoples’ mouths, I’m going to stick with just describing mine.
I do not think Bitcoin Core or miners should be involved in the activation process in the role of either deploying new activation releases, or in a position where they are capable of vetoing or stalling something from activation. Going forward, I think all new features deployed through a UASF using BIP 8 LOT=True. I think it is important that the precedent we set going into the future is one of grassroots organization that does not consistently come from an identifiable group being seen as the arbiters of what features are or are not activated in the Bitcoin protocol.
If, going forward, we set the precedent of people outside of Core being the ones to propose activation, we set the precedent of a higher level of skepticism toward change in general. We avoid creating the social perception for newer users that developers decide what does or does not happen. This would set a very high bar for enacting new changes, and ensure that bar remains high instead of devolving into a dynamic of users deferring to experts to decide what happens. Activations can occur through outside clients, with the next Core release activating new features if they have successfully been activated through patched clients.
This can allow each “activation client” to be used temporarily during a feature deployment, with everyone switching back to Core after a successful activation, preventing the need to maintain long lived clients outside of Core while still removing the process of activation from Core developers.
Some might argue this creates a risk of chain splits during soft forks, but the reality is that chain splits are always possible during a soft fork. With LOT=True, the point at which a fork will occur will be known ahead of time if one were to occur. If the chain is going to split, it will occur during the final signaling period of the activation when the first block not signaling for activation is mined. This defines a consistent and predictable time period in which it will occur if it does, as opposed to any arbitrary point after activation when some miner not enforcing the new rules mines a block violating that rule.
If there truly is consensus for a new feature, then the majority of the economy will be running a client to activate it, and such a chainsplit will be a minor disruption and inconvenience. If there is no consensus for a new feature, then again such a chainsplit should be no more than a minor disruption and inconvenience as a tiny minority forks themselves off the network. They will be left with the decision to continue using a minority fork chain or relent and return to the Bitcoin network.
Bitcoin is ultimately a market-driven system, where consensus is arrived at voluntarily. I believe attempts to prevent that process from becoming messy are both misguided, missing the fundamental nature of the system, and will inevitably lead to more centralized social control and perception of top-down decision making if people constantly try to remove the mess from arriving at consensus. We should embrace that process, and stop trying to control it.
At the end of the day, this is simply my personal opinion on how things should be done, and there are many more diverse opinions out there. People shouldn’t be hesitant to voice their opinions on this matter. It’s time for us to start having this conversation instead of constantly putting it off, and letting the inertia of social dynamics slowly make the decision for us.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Feedzy
