Taproot activation proposals

This page summarizes several technical proposals for activating the taproot soft fork defined by BIPs 340, 341, and 342. The goal is to succinctly reference the tradeoffs inherent in each class of proposals so that the development community can choose and implement an activation method that users will find acceptable.

Note that a common theme in many of the proposals is dealing with the case where an insufficient percentage of hashrate signals readiness to enforce taproot. This is a reaction to the difficulty activating segwit. However, there is currently no indication that there will be difficulty activating taproot---miners may offer it the same support that they offered other non-controversial soft forks such as BIP34 height in coinbase, BIP66 strict DER, BIP65 OP_CHECKLOCKTIMEVERIFY, and BIPs 68/112/113 relative locktimes.

Notes on BIP8

At the time this document is being written, BIP8 version bits with lock-in by height was recently updated for the first time in several years. One notable change is that forced activation is now based on block height rather than median time past; a second notable change is that forced activation is a boolean parameter chosen when a soft fork’s activation parameters are set either for the initial deployment or updated in a later deployment.

BIP8 without forced activation is very similar to BIP9 version bits with timeout and delay, with the only significant difference being BIP8’s use of block heights compared to BIP9’s use of median time past. This setting allows the attempt to fail (but it can be retried later).

BIP8 with forced activation concludes with a mandatory signaling period where all blocks produced in compliance with its rules must signal readiness for the soft fork in a way that will trigger activation in an earlier deployment of the same soft fork with non-mandatory activation. In other words, if node version x is released without forced activation and, later, version y is released that successfully forces miners to begin signaling readiness within the same time period, both versions will begin enforcing the new consensus rules at the same time.

This flexibility of the revised BIP8 proposal makes it possible to express some other ideas in terms of what they would look like using BIP8. This provides a common factor to use for categorizing many different proposals.

Proposal overview

Nomenclature: BIP8(lockinontimeout, timeout). The lockinontimeout parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The timeout parameter specifies how many months (m) or years (y) until either the attempt fails or in mandatory activated. Columns with empty stages appear when no action is specified in advance (but any action with broad user support is still possible).

Precise time parameters are still under discussion, with some people advocating moderately longer durations and some advocating moderately shorter durations. The entries below are examples meant to reflect the general idea behind a class of proposals.

Short name	Variation	First stage	Second stage	Third stage
Let’s see what happens	Default	BIP8(false, 3m)
BIP9 equivalent	Default	BIP8(false, 1y)
Modern Soft Fork Activation	No issues	BIP8(false, 1y)	No action, 6m	BIP8(true, 2y)
	Issue discovered	BIP8(false, 1y)	Abandon attempt
Decreasing Threshold Soft Fork Activation	No issues	BIP8(false, 1y)	No action, 6m	BIP8(true, 2.5y), decreasing threshold
	Issue discovered	BIP8(false, 1y)	Abandon attempt
Start now, improve later	No additional action	BIP8(false, 2y)
	Commit to activation	BIP8(false, 2y)	BIP8(true, 2y)
	Commit to accelerated activation	BIP8(false, 2y)	BIP8(true, 1y)
Gently discourage apathy	Default	BIP8(true, 2y)	N/A	N/A
	Accelerate activation	BIP8(true, 2y)	BIP8(true, 1y)	N/A

The same proposals as above graphed over time:

Activation timeline

Proposals

Let’s see what happens, BIP8(false, 3m)

Proposed as a low-risk way to see if miners are willing to activate taproot as quickly as they activated BIP65 CLTV (two months) and BIP68 consensus-enforced sequence numbers (one month).

Pros:

• Non-committal: if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.
• Short duration: if it fails unnecessarily, we’ll only have lost three months plus deployment time.
• Useful data: if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.

Cons:

• Unnecessary failure risk (3 months): if it fails for no good reason, we’ll have wasted three months, plus its deployment time, plus the time to choose and deploy another activation method.
• Single-shot: if it fails, anyone who ran the 3-month release must upgrade in order to enforce any subsequent attempts. Compare to the start now, improve later proposal where early releases can be triggered to activate by later releases.

BIP9 equivalent, BIP8(false, 1y)

Some people think that the lack of miner readiness signaling during the first several months of segwit availability was an aberration specific to the political context of the block size debate, segwit’s interference with covert ASICBoost, or some other factor. These people may wish to try BIP9 again. BIP8(false, 1y) is essentially BIP9 but using block heights rather than median time past to guarantee a specified number of signaling periods.

Pros:

• Non-committal: if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.
• Useful data: if it works, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.

Cons:

• Unnecessary failure risk (1 year): if it fails for no good reason, we’ll have wasted an entire year, plus its deployment time, plus the time to choose and deploy another activation method.

Modern Soft Fork Activation, BIP8(false, 1y)+quiet(6m)+BIP8(true, 2y)

Proposed in a mailing list post, the goals of this idea are to ensure users truly want a soft fork and that it’s activated in a way that minimizes the risk of disruption.

Pros:

• Non-committal (initial deployment): if a problem is discovered with taproot during the first two stages, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.
• Useful data: if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.
• Far-off flag day: if mandatory activation is needed, there’s a long time (2 years) for users to upgrade to mandatory enforcement nodes. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.

Cons:

• Committal (subsequent deployment): if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.
• Unnecessary delay: without miner cooperation, it will take almost three years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).

Decreasing Threshold Soft-Fork Activation, BIP8(false, 6m)+NoAction(1y)+BIP8(true, 2.5y)

A [slight variation][bip-dectresh] on the Modern Soft Fork Activation method, the final period in this proposal steadily decreases the percentage of hashrate that needs to signal readiness for the soft fork before it activates. For example, normally 95% of blocks in a difficulty period need to signal for a BIP8 soft fork in order to activate it; however, near the end of the final signaling period, it might only require 60% of hash rate to signal readiness. This lower threshold is reasonable because it’s expected that most users will be ready to enforce the proposal at that time. Even if miners still aren’t signaling in sufficient numbers, the proposal can mandatory activate at the end of its final stage.

Pros:

• Non-committal (initial deployment): if a problem is discovered with taproot during the first two stages, the attempt can safely fail without further intervention.
• Useful data: if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.
• Far-off flag day: if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.

Cons:

• Committal (subsequent deployment): if a problem is discovered with taproot during the final stage, users and developers may need to intervene to prevent the problem from being exploited.
• Unnecessary delay: without miner cooperation, it will take almost four years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).
• No reference implementation: no implementation of this proposal yet exists, although it is not believed that creating one would be particularly difficult.

Start now, improve later, BIP8(false, 2y)

Proposed as an option that maximizes flexibility, this allows miners to signal readiness to enforce taproot quickly but also makes it easy for users to force taproot activation later. For example, after several months of miners not activating taproot for no good reason, an updated node could be published that used the same BIP8 parameters except lockinontimeout=true, requiring activation at the end of the two years. Or true could be set and the timeout deadline could be shortened, allowing activation within 6 or 12 more months.

Pros:

• Non-committal: if a problem is discovered with taproot before miner activation, or there’s a lack of user support for the proposal, the attempt can safely fail without further intervention.
• Useful data: if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.
• Enough time for second deployment: the two year duration probably gives users and developers enough time to deploy an alternative that sets lockintimeout=true, allowing all nodes compatible with either deployment to activate simultaneously.

Cons:

• Unnecessary failure risk (2 years): if it fails for no good reason, we’ll have wasted two years, plus its deployment time, plus the time to choose and deploy another activation method.
• Chaos risk: if some users later decide to lockinontimeout=true with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial lockinontimeout=false version is released.

Gently discourage apathy, BIP8(true, 2y)

Proposed as a way to ensure miners eventually need to signal, so they don’t defer doing so out of apathy, this method requires activation after a long delay.

Pros:

• Useful data: if it activates quickly, it will add evidence to the theory that segwit activation was an aberration and users, developers, and miners can continue working together to upgrade the consensus protocol with minimal fuss.
• Far-off flag day: if mandatory activation is needed, there’s a long time (months or years) for users to upgrade to nodes that accept reduced threshold signaling or mandatory activation. This minimizes the chance that only a small number of users will enact mandatory enforcement and then be tricked into accepting bitcoins that most other users won’t consider valid.
• Enough time for second deployment: the two year duration may gives users and developers enough time to deploy additional soft fork rules that fix any problems in the initial proposal.

Cons:

• Committal: if a problem is discovered with taproot before activation, users and developers may need to intervene to prevent the problem from being exploited.
• Unnecessary delay: without miner cooperation, it will take two years to get the taproot features, which may delay other useful Bitcoin work or cause developers to spend time implementing unnecessary intermediate solutions (e.g. 2pECDSA rather than MuSig).
• Chaos risk: if some users later decide to lockinontimeout=true with a date before the original two-year end, they all need to choose the same date or users choosing a date with insufficient support could be tricked into accepting non-spendable bitcoins. It may be possible to mitigate this by building support for an acceleration target date even before the initial version is released.