[bitcoin-dev] Straight Flag Day (Height) Taproot Activation

From: Matt Corallo <lf-lists@mattcorallo•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Date: Sun, 28 Feb 2021 11:45:22 -0500	[thread overview]
Message-ID: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com> (raw)

As anyone reading this list is aware, there is significant debate around the activation method for the proposed Taproot 
soft fork. So much so, and with so much conviction, that many individuals are committing themselves to running 
incompatible consensus rules. Obviously, such commitments, were they to come to pass, and were a fork to occur as a 
result, would do more harm than any soft-fork does good. Further, such commitments and debate have likely delayed any 
possible release of a future Taproot activation while issues around locked-in activation are debated, instead of 
avoiding it as was the original intent of the "just ship BIP 8 LOT=false and we'll debate the rest if we need to" approach.

Given this, it seems one way to keep the network in consensus would be to simply activate taproot through a traditional, 
no-frills, flag-day (or -height) activation with a flag day of roughly August, 2022. Going back to my criteria laid out 
in [1],

1) I don't believe we have or will see significant, reasonable, and directed objection. This has largely always been the 
case, but it is also critical that the lack of such objection is demonstrable to outside observers. Ironically, the 
ongoing debate (and clear lack of consensus) around activation methods can be said to have had that effect, at least as 
far as the active Bitcoin Reddit/Twitter userbase is concerned. In addition, the public support for Taproot activation 
made by mining pool operators further shows public review and acceptance. Ideally, large Bitcoin business operators who 
previously took part in Bitcoin Optech's Taproot workshop [2] would publicly state something similar prior to release of 
Taproot activation parameters. Because this expectation is social, no technical solution exists, only public statements 
made in broad venues - something which I'd previously argued comes through soft fork activation parameter deployment, 
but which can also come from elsewhere.

2) The high node-level-adoption bar is one of the most critical goals, and the one most currently in jeopardy in a BIP 8 
approach. Users demanding alternative consensus rules (or, worse, configuration flags to change consensus rules on 
individual nodes with an expectation of use) makes this very complicated in the context of BIP 8. Instead of debating 
activation parameters and entrenching individuals into running their own consensus rules, a flag day activation changes 
the problem to one of simply encouraging upgrades, avoiding a lot of possibility for games. Of course in order to meet 
this goal we still need significant time to pass between activation parameter release and activation. Given the delays 
likely to result from debates around BIP 8 parameters, I don't think this is a huge loss. Capitalizing on current 
interest and demand for Taproot further implies a shortened timeline (eg a year and a half instead of two) may be merited.

3) The potential loss of hashpower is likely the biggest risk of this approach. It is derisked somewhat by the public 
commitment of pool operators to Taproot activation, and can be de-risked further by seeking more immediate commitment 
prior to release. Still, given the desire to push for a forced-signaling approach by many, there is more significant 
risk of loss of hashpower in today's approach. In an ideal world, we could do something more akin to BIP 9/BIP 8(false) 
to reduce risk of this further, but its increasingly likely that this is not possible. A flag-day which takes advantage 
of the nonstandardness of Taproot transactions in current Bitcoin Core releases may suffice.

4) Similar arguments apply as the above around the public commitment from pool operators to enforce the Taproot 
consensus rules.

5) Similar arguments apply as the discussion in (1).

Ultimately, the risk which is present in doing flag day activations (and the reason I've argued against them as a 
"default" in the past) are present as well in BIP 8(true), forced-signaling activations where community debate splits 
the consensus rules across nodes. While such a deployment could delay Taproot somewhat, it sidesteps a sufficient amount 
of debate and resulting delay that I wouldn't be surprised if it did not. Further, Taproot has been worked on for many 
years now with no apparent urgency from the many who are suddenly expressing activation urgency, making it more likely 
such urgency is artificial. Those who seek Taproot activation for Bitcoin market reasons should also rejoice - not only 
can the market celebrate the final release of Taproot, but it gets a second celebratory event in 2022 when the 
activation occurs.

Matt

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
[2] https://bitcoinops.org/en/schorr-taproot-workshop/