Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-28 📝 Original message:As anyone reading this ...
📅 Original date posted:2021-02-28
📝 Original message: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/
📝 Original message: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/