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.
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|
(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:
- Should the miner threshold signalling period be followed by a flag day activation?
- Which parts of the activation logic (if any) should be included in Bitcoin Core?
- 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)
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|
Activation logic to be included in Bitcoin Core
|In favour of including activation logic in Bitcoin Core||Against including activation logic in Bitcoin Core|
Mandatory miner signalling at the flag day activation point
In favour of forced miner signalling
Against forced miner signalling
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.