public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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/


             reply	other threads:[~2021-02-28 16:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-28 16:45 Matt Corallo [this message]
2021-02-28 17:20 ` [bitcoin-dev] Straight Flag Day (Height) Taproot Activation Luke Dashjr
2021-02-28 17:29   ` Matt Corallo
2021-02-28 19:43     ` Jeremy
2021-02-28 19:51       ` Matt Corallo
2021-02-28 20:02         ` Jeremy
2021-02-28 20:19           ` Eric Voskuil
2021-02-28 20:25             ` Matt Corallo
2021-02-28 20:38               ` Eric Voskuil
2021-02-28 20:20           ` Matt Corallo
2021-03-03 14:59 ` Anthony Towns
2021-03-03 16:49   ` Matt Corallo
2021-03-06 11:33     ` Anthony Towns
2021-03-08 12:51       ` Jorge Timón
2021-03-08 14:13         ` eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox