Bitcoin Softfork Activation Methodology

BitMEX Research

Abstract: Bitcoin’s Taproot softfork upgrade looks almost ready and the Bitcoin community has started to seriously discuss the potential activation methodologies. In this piece, we summarise the main choices when it comes to the activation and discuss the most significant points of contention. We conclude by postulating that there is no perfect activating methodology. Any activation approach could set a bad precedent, which could be exploited at some future date. However, although there is a lot of “bikeshedding” occurring, due to the lack of contention about this particular upgrade, the exact activating path taken at this point may not be particularly critical. A potential partial solution to some of the dilemmas present and possible way forward could be for Bitcoin Core to release a client with a relatively passive activation logic and for other community members to follow on from this by releasing clients that force the same activation in a slightly more assertive manner.

Overview

As we mentioned in May 2019, the Taproot Bitcoin softfork proposal is gaining significant traction in the developer community and now, in the summer of 2020, the focus has shifted to debating how the softfork might activate on the Bitcoin network. 

History of softfork activations in Bitcoin

Before deciding on the best way forwards, it might be a good idea to take a look back at the history of Bitcoin softforks. As far as we can tell, there have been 16 softforks in Bitcoin’s history, based on our December 2017 piece entitled “A complete history of Bitcoin’s consensus forks”. A majority of the upgrades, nine of them to be precise, mostly in the early 2010 to 2012 period, were conducted as flag day softforks. On the other hand, seven of the softforks were activated using a miner signalling threshold, ranging from 55% to 95%.

  Smooth Upgrade Significant Issues Total
Flag day or rolled out with immediate effect 8* 1 9
Miner threshold activations    
55% miner threshold   1 1
80% miner threshold 1*   1
95% miner threshold 4 1 5
Total with miner threshold 5 2 7
Grand total 13 3 16

(Source: BitMEX Research)
(Notes: * As far as we are aware there was one flag day softfork with mandatory miner signalling (BIP148) and one miner threshold softfork with mandatory miner signalling (BIP 91))

While the flag day upgrade method may appear more reliable based on the above data, we would not recommend that this data is used to support the claim that the flag day methodology is superior. Most of the issues in the above softforks were caused by idiosyncrasies unrelated to the activation methodology and the ecosystem has changed significantly in the period. The above data is provided merely for historical context and it may not be all that relevant.

The blocksize war

The other piece of historical context, which again may not be all that relevant, is the blocksize war, which raged from 2015 to 2017. There was a softfork proposal called Segregated Witness, designed to increase the blocksize limit, however, due to the blocksize war conflict the activation of this softfork was somewhat of a dangerous mess, and therefore many in the community are keen to attempt to improve the activation methodology. 

Activation logic for the segregated witness upgrade was included in Bitcoin Core, based on a 95% miner threshold, with a one year timeout. There was no flag day activation at the end. Eventually, towards the end of the softfork window, two different softforks, a flag day softfork (BIP148) and an 80% miner threshold softfork (BIP91) made signalling for the Segregated Witness softfork mandatory and therefore it finally activated. Neither of these two softforks (BIP148 or BIP91) were included in Bitcoin Core.

Due to the above messy confusion, many concluded that the 95% threshold system, without mandatory signalling, was somewhat of a failure. However, in our view, this mess was primarily caused by the tensions in the blocksize war, rather than inherent weaknesses of the activation logic.

The activation debate

Other than the difficult issue of the timing parameters and assuming miner threshold signalling will be used somewhere, as far as we can tell, the debate appears to be focused on three somewhat interrelated areas:

  1. Should the miner threshold signalling period be followed by a flag day activation?
  2. Which parts of the activation logic (if any) should be included in Bitcoin Core?
  3. Should miner signalling eventually become mandatory?

We have tried to summarise the interrelationships between these main debating points in the decision tree illustration below. Based on our illustration we think there are essentially six reasonably likely choices when it comes to modern softfork activation.

Softfork activation methodology decision tree (Assuming some form of miner threshold signalling)

(Source: BitMEX Research)
(Note: The right-hand side of the tree, with mandatory miner signalling, is consistent with BIP 8, while the left-hand side of the tree is consistent with BIP 9)

In the below tables we aim to summarise the main debating points in favour of and against the three challenging questions above, which may need to be answered in order to determine the softfork activation methodology.

Flag day at the end of the signalling period

In favour of a flag day Against a flag day
  • The absence of a flag day in the original segregated witness activation caused problems as miners did not activate it during the early stages and there were concerns the upgrade would not occur
  • Miner signalling without a flag day gives a false impression that miners control the protocol rules, when actually the threshold vote is merely a signalling mechanism for miners to signal they are ready for a softfork the community has already decided on
  • If miners choose not to activate the softfork early, it can safely activate at a later date far into the future. It is end-users who ultimately control the protocol rules, not miners. The threshold voting mechanism is merely a way of safely activating softforks early
  • Using a flag day is too aggressive at this point. Instead one should adopt a more friendly approach and only consider the flag day in exceptional circumstances, if actors begin to appear hostile
  • It is vital to be as patient and as friendly as possible when it comes to the protocol rules. In the event miners are not happy with the upgrade, the status quo consensus rules should prevail and no softfork should occur, this ensures Bitcoin’s rules remain robust
  • Due to a lack of contention, it is likely miners will voluntarily activate the softfork anyway, so why use an aggressive and risky flag day system when it is not necessary?
  • Adding a flag day creates a whole new set of problems. For example, who has the authority to initiate the flag day? How does the community obtain agreement on the date? Anyone can create a flag day softfork at any time and the new rules could be controversial.

Activation logic to be included in Bitcoin Core

In favour of including activation logic in Bitcoin Core Against including activation logic in Bitcoin Core
  • If the activation methodology is not implemented in Bitcoin Core, then there is the problem of achieving coordination over the activation parameters
  • At the same time, if other community members release the client with activation logic, this sets a dangerous precedent. Many users could release all kinds of clients for softforks, when there is insufficient consensus, increasing the risk of dangerous chainsplits in the future
  • Bitcoin Core including the activation methodology is the least worst option
  • Bitcoin Core would release a client which includes activation logic, however, it will not bundled in with other bug fixes. At the same time Bitcoin Core does not have an auto-update feature. Therefore upgrading is entirely optional and Bitcoin Core is not forcing a protocol change, only users who choose to run the new software are changing the protocol rule
  • One of the largest problems with the blocksize war was that many people now overestimate the extent to which the Bitcoin Core project has power over Bitcoin’s consensus rules. This is now a significant issue and therefore the community should ensure Bitcoin Core does not have the ability to change the consensus rules on their own
  • Consensus rule changes must come from a larger group than software developers and it must also be driven by a grassroots user movement
  • It is too controversial and aggressive for the Bitcoin Core project to implement a flag day upgrade, this is an inappropriate power grab. Users and/or miners must demonstrate support for a softfork proposal before Core can include a flag day

Mandatory miner signalling at the flag day activation point

In favour of forced miner signalling

Against forced miner signalling

  • Mandatory miner signalling provides certainty in that the community knows whether the activation worked or not. Without mandatory flagging, the flag day activation could have passed and users would not know if the softfork activated
  • For example, after the flag day passed, users would have to wait several months (or longer) to see if a block breaching the new softfork rules is produced, built upon and accepted by the wider economy and this could happen at any point in time 
  • A hostile attacking miner could produce a block which violates the softfork rule at any time they want, for instance a time designed to cause maximum chaos
  • Therefore although mandatory signalling aggressively forces miners to upgrade and increases the risk of a chainsplit, this is better than the alternative, which allows an attacker to create a similar chainsplit risk, except at a time that suits the hostile actor
  • Modern softforks only restrict non standard bitcoin rules. This makes activation very safe, since only a malicious miner who upgrades to an anti-softfork client could cause a chainsplit. Even if miners do not upgrade for the softfork, they would still always produce valid blocks. Mandatory signalling breaks this very safe upgrade methodology and introduces extra risks. Miners who do not upgrade and take no action would produce invalid blocks
  • Mandatory miner signalling is therefore too aggressive. Miners should be free to not upgrade and continue operating as before the fork
  • Mandatory miner signalling will only encourage false flagging, where miners claim to have upgraded to support the protocol change but are merely manipulating the flag. We already know false flagging is common, for instance in the past large miners have produced blocks with multiple contradicting flags. Therefore mandatory signalling does not provide any certainty

Conclusion

One could argue that there is a significant amount of “bikeshedding” occurring about the activation logic. Due to the lack of contention about this particular upgrade, the exact activating path taken at this point may not be particularly critical at this point. However, as one can see from the discussions above, there is no perfect activation methodology, each method has issues or exposes potential weaknesses or contradictions with respect to the robustness of Bitcoin’s protocol rules. Any approach taken to solve the problem could set a precedent and therefore be exploited at a future date with other protocol changes.

Perhaps there is some compromise which could be reached with regards to the current apparent activation methodology dilemma:

  • Bitcoin Core could include activation logic based on BIP 9, choosing a 95% miner threshold activation logic without a flag day at the end of the activation period and without mandatory miner signalling. Therefore Bitcoin Core would not be acting in an overtly aggressive manner, as miner cooperation would be needed to activate the softfork. There is also precedent for this, as Bitcoin Core has released clients with this activation logic many times in the past
  • Other community-driven versions of the software (not Bitcoin Core), could then be released. These other clients could contain flag day activation logic, with mandatory miner signalling for the Bitcoin Core softfork, timed to coincide with the end of Bitcoin Core’s chosen activation window. This community-driven softfork would therefore activate Bitcoin Core’s softfork

To some extent this solves the timing for community coordination problem, as community members could just choose the end of Bitcoin Core’s activation window as the mandatory signalling period. It also does not set a dangerous precedent about any clients being made to activate any softfork, since it is being used to activate a softfork where logic already exists in Bitcoin Core. This activation methodology is reasonably similar to how segregated witness eventually activated, except this time it could be planned from the start, at least to some extent. This certainly doesn’t solve all the issues, nor are we claiming this is a good outcome, however to us it feels like a potential likely pathway forwards.

Further Reading/Materials