Taproot activation proposals - Revision history

Luke-jr at 06:07, 14 September 2024

2024-09-14T06:07:47Z

← Older revision		Revision as of 06:07, 14 September 2024
Line 1:		Line 1:
	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.		This page summarizes several technical proposals for activating the taproot soft fork defined by BIPs 340-343. 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 <code>OP_CHECKLOCKTIMEVERIFY</code>, and BIPs 68/112/113 relative locktimes.		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 <code>OP_CHECKLOCKTIMEVERIFY</code>, and BIPs 68/112/113 relative locktimes.

Luke-jr at 21:30, 16 March 2021

2021-03-16T21:30:48Z

← Older revision		Revision as of 21:30, 16 March 2021
Line 14:		Line 14:
	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.		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 ==		== Prior to 2021 ==

			=== Proposal overview ===

	Nomenclature: <code>BIP8(lockinontimeout, timeout)</code>. The <code>lockinontimeout</code> parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The <code>timeout</code> 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).		Nomenclature: <code>BIP8(lockinontimeout, timeout)</code>. The <code>lockinontimeout</code> parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The <code>timeout</code> 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).
Line 115:		Line 117:
	[[File:Activation-timeline.png\|frame\|none\|alt=\|Activation timeline]]		[[File:Activation-timeline.png\|frame\|none\|alt=\|Activation timeline]]

	== Proposals ==		=== Proposals ===

	=== Let’s see what happens, BIP8(false, 3m) ===		==== 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).		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).
Line 133:		Line 135:

	<br><br>		<br><br>
	=== BIP9 equivalent, BIP8(false, 1y) ===		==== 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.		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.
Line 147:		Line 149:

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

	Proposed in a [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html 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.		Proposed in a [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html 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.
Line 163:		Line 165:

	<br><br>		<br><br>
	=== Decreasing Threshold Soft-Fork Activation, BIP8(false, 6m)+NoAction(1y)+BIP8(true, 2.5y) ===		==== 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.		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.
Line 180:		Line 182:

	<br><br>		<br><br>
	=== Start now, improve later, BIP8(false, 2y) ===		==== 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 <code>lockinontimeout=true</code>, requiring activation at the end of the two years. Or <code>true</code> could be set and the timeout deadline could be shortened, allowing activation within 6 or 12 more months.		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 <code>lockinontimeout=true</code>, requiring activation at the end of the two years. Or <code>true</code> could be set and the timeout deadline could be shortened, allowing activation within 6 or 12 more months.
Line 196:		Line 198:

	<br><br>		<br><br>
	=== Gently discourage apathy, BIP8(true, 2y) ===		==== 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.		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.

Luke-jr: Update language

2021-03-16T21:28:47Z

Update language

← Older revision		Revision as of 21:28, 16 March 2021
Line 5:		Line 5:
	== Notes on BIP8 ==		== Notes on BIP8 ==

	At the time this document is being written, [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8] ~~''version bits with lock-~~in ~~by height'' was recently [https://github.com/bitcoin/bips//pull/550 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.		At the time this document is being written, [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8] has been drafted based on lessons learned in 2017.
			One notable change following BIPs 9+148 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 [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki 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 without forced activation is very similar to [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki 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).

Harding: Add note about forced activation proposals being a reaction to segwit activation rather than an expectation that miners will necessarily be a problem for taproot activation

2020-10-17T10:52:15Z

Add note about forced activation proposals being a reaction to segwit activation rather than an expectation that miners will necessarily be a problem for taproot activation

← Older revision		Revision as of 10:52, 17 October 2020
Line 1:		Line 1:
	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.		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 <code>OP_CHECKLOCKTIMEVERIFY</code>, and BIPs 68/112/113 relative locktimes.

	== Notes on BIP8 ==		== Notes on BIP8 ==

Harding: Add "Chaos risk" to "Gently discourage apathy" for "Accelerate activation" variation

2020-07-21T13:38:38Z

Add "Chaos risk" to "Gently discourage apathy" for "Accelerate activation" variation

← Older revision		Revision as of 13:38, 21 July 2020
Line 207:		Line 207:
	* '''Committal:''' if a problem is discovered with taproot before activation, users and developers may need to intervene to prevent the problem from being exploited.		* '''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).		* '''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 <code>lockinontimeout=true</code> 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.

Harding: s/Type/Variation/ for clarity

2020-07-21T13:26:18Z

s/Type/Variation/ for clarity

← Older revision		Revision as of 13:26, 21 July 2020
Line 21:		Line 21:
	{\|		{\|
	!\| Short name		!\| Short name
	!\| ~~Type~~		!\| Variation
	!\| First stage		!\| First stage
	!\| Second stage		!\| Second stage

Harding: Initial content adapted from discussion gist at https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d

2020-07-21T13:21:17Z

Initial content adapted from discussion gist at https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d

New page

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.

== Notes on BIP8 ==

At the time this document is being written, [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8] ''version bits with lock-in by height'' was recently [https://github.com/bitcoin/bips//pull/550 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 [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki 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: <code>BIP8(lockinontimeout, timeout)</code>. The <code>lockinontimeout</code> parameter is a bool specifying whether the attempt will conclude with a flag day activation (true) or a failure to activate (false). The <code>timeout</code> 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
!| Type
!| 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
| <s>BIP8(false, 2y)</s>
| BIP8(true, 2y)
|

|-
|

| Commit to accelerated activation
| <s>BIP8(false, 2y)</s>
| BIP8(true, 1y)
|

|-
| Gently discourage apathy
| Default
| BIP8(true, 2y)
| N/A
| N/A
|-
|

| Accelerate activation
| <s>BIP8(true, 2y)</s>
| BIP8(true, 1y)
| N/A
|}

The same proposals as above graphed over time:

[[File:Activation-timeline.png|frame|none|alt=|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 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html 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 <code>lockinontimeout=true</code>, requiring activation at the end of the two years. Or <code>true</code> 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 <code>lockintimeout=true</code>, 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 <code>lockinontimeout=true</code> 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 <code>lockinontimeout=false</code> 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).