[Taproot softfork] "Speedy trial" activation

[Carlton Banks]

New proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018590.html

(based on this bitcoin ML post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html)


Essentially:

• 3 months BIP 9 activation (no activation lock-in when it ends), starting April 14th 2021 (so soon), ending July 14th
• 3 month delay till the actual soft-fork after activation (October 1st 2021 would be the date of the soft-fork, regardless of when it is activated)

So miners/pools get a chance to demonstrate their goodwill, but don't have to update their nodes in a big rush (potentially pushed on them by their rivals' signalling for the soft-fork)

In the meantime, the discussion about what to do if the opportunity is missed can continue, including anyone preparing unilateral activation movements fashioned on BIPs 148 and 91.


Sounds ok to me. FWIW, people in the #taproot-activation channel seemed to like it too.


Rules: No trolls, no trolling

[1715666216]

1715666216

[1715666216]

1715666216

[1715666216]

1715666216

[acquafredda]

Sounds reasonable! Get the ball rolling devs! It looks like a good way to eventually activate taproot gracefully and with less friction.
Either get it activated soon or let this activation option die also soon or to put it as simply as they put it:
Succeed, or fail fast

Despite growing frustration, discussion has been overwhelmingly constructive, for which all the contributors should be commended.

Best part! If there is some common ground, let this speedy trial activation succeed.

[pooya87]

The only two criticism I have is that it first reduces the activation threshold to 90% (instead of what we've used in past decade: 95%) by changing nRuleChangeActivationThreshold to 1815 and also it is using block times which is not the most reliable variable to use in blocks due to fluctuations of hashrate, chance and the fact that times could be changed up to 2 hours each. This could open up some room for manipulation. (looking at the PR this last part may have changed)

[achow101]

The only two criticism I have is that it first reduces the activation threshold to 90% (instead of what we've used in past decade: 95%) by changing nRuleChangeActivationThreshold to 1815

Activation thresholds have been lower in the past, ISM (BIP 34) used 75% to activate new rules. Additionally, at previous meetings and discussions in the ##taproot-activation channel (and later discussed on the mailing list), 90% was deemed acceptable.

and also it is using block times which is not the most reliable variable to use in blocks due to fluctuations of hashrate, chance and the fact that times could be changed up to 2 hours each. This could open up some room for manipulation. (looking at the PR this last part may have changed)

AJ's initial proposal is based on BIP 9 which doesn't actually use block times as is. It uses the median time past, not the actual time in the header, although MTP is based on that time.

My version of this proposal (summarized by roconner: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html) is based on BIP 8 so it uses block heights. It also runs 2-3 weeks later than AJ's.

[pooya87]

Activation thresholds have been lower in the past, ISM (BIP 34) used 75% to activate new rules.

I categorize BIP34 fork as more of a bug fix than an upgrade like Taproot. Also the activation was still using 95% rule as far as I can tell. The 75% part was only used to reject blocks with version >= 2 that did not have the height in their coinbase, in other words even with 75% of blocks accepting BIP34, block with version=1 could still be mined.

[achow101]

I categorize BIP34 fork as more of a bug fix than an upgrade like Taproot.

Regardless it is still a soft fork. BIPs 66 (strict DER) and 65 (OP_CLTV) also used the same activation mechanism. You could say that BIP 66 is a bug fix, but BIP 65 is certainly a feature upgrade in the same way taproot is a feature upgrade.

Also the activation was still using 95% rule as far as I can tell. The 75% part was only used to reject blocks with version >= 2 that did not have the height in their coinbase, in other words even with 75% of blocks accepting BIP34, block with version=1 could still be mined.

The part that matters is where the new rules begin to be enforced. Under ISM, the new rules were enforced at 75%. This means that if any blocks failed the new rules after 75% had signaled, then there would be a chain split. The same is true of the proposed 90% threshold: the new rules activate when 90% of blocks signal (after a grace period) and any block that fails the new rules afterwards is invalid. it doesn't matter that blocks conforming to the old rules can be mined, the same applies to BIP 8 and 9 deployments. All that matters with this threshold is whether the new rules are being enforced. For the current taproot activation proposals, that is at 90%. In all ISM forks, that was 75%.

The 95% threshold has no counterpart in BIPs 8 or 9 as they do not have an invalidity requirement. There is no requirement that disallows blocks which are valid under the new rules but do not use them (as a v1 block would be after BIP 34). Even with segwit, miners can still mine blocks that contain only legacy transactions and they don't need to have the witness merkle root in their coinbases if they do so.

[NotATether]

...it first reduces the activation threshold to 90% (instead of what we've used in past decade: 95%) by changing nRuleChangeActivationThreshold to 1815

The threshold was lowered a little bit, but how big of a difference can it make in terms of acceptance? The big mining pools have somewhere in the ball park of 6% to 17% of the global hashpower, and using BTC.com's list, it takes the top 9 pools to reach the 90% threshold, but 95% threshold needs the top 13 pools.

But we don't expect all top pools to support this and there are also a bunch of tiny pools with less than 0.1% of the hashrate, so we can expect them all to weigh in their support or opposition as normal right? The number of pools accepting this doesn't change too much.