Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Jeremy <jlrubin@mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 10225 bytes --]

Thank you for resurfacing and collating this concept.

At this time I don't see major issues with this course of action and think
it represents not only a reasonable compromise between all different
perspectives, but also gives us an opportunity to learn more about less
'slow' yet safe consensus upgrades. In particular, I am very happy to see
the earliest activation concept included.

Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Fri, Mar 5, 2021 at 7:44 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On the ##taproot-activation IRC channel, Russell O'Connor recently
> proposed a modification of the "Let's see what happens" activation
> proposal.[1] The idea received significant discussion and seemed
> acceptable to several people who could not previously agree on a
> proposal (although this doesn't necessarily make it their first
> choice).  The following is my attempt at a description.
>
> 1. Start soon: shortly after the release of software containing this
>    proposed activation logic, nodes will begin counting blocks towards
>    the 90% threshold required to lock in taproot.[2]
>
> 2. Stop soon: if the lockin threshold isn't reached within approximately
>    three months, the activation attempt fails.  There is no mandatory
>    activation and everyone is encouraged to try again using different
>    activation parameters.
>
> 2. Delayed activation: in the happy occasion where the lockin threshold
>    is reached, taproot is guaranteed to eventually activate---but not
>    until approximately six months after signal tracking started.
>
> ## Example timeline
>
> (All dates approximate; see the section below about BIP9 vs BIP8.)
>
> - T+0: release of one or more full nodes with activation code
> - T+14: signal tracking begins
> - T+28: earliest possible lock in
> - T+104: locked in by this date or need to try a different activation
> process
> - T+194: activation (if lockin occurred)
>
> ## Analysis
>
> The goal of Speedy Trial is to allow a taproot activation attempt to
> either quickly succeed or quickly fail---without compromising safety in
> either case.  Details below:
>
> ### Mitigating the problems of early success
>
> New rules added in a soft fork need to be enforced by a large part of
> the economy or there's a risk that a long chain of blocks breaking the
> rules will be accepted by some users and rejected by others, causing a
> chain split that can result in large direct losses to transaction
> receivers and potentially even larger indirect losses to holders due to
> reduced confidence in the safety of the Bitcoin system.
>
> One step developers have taken in the past to ensure widespread adoption
> of new consensus rules is programming in a delay between the time software
> with those rules is expected to be released and when the software starts
> tracking which blocks signal for activation.  For example:
>
>     Soft fork        | Release    | Start      | Delta
>     -----------------+------------+------------+----------
>     BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days
>     BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
>
>     Sources: BitcoinCore.org,
> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
>
> Speedy Trial replaces most of that upfront delay with a backend delay.
> No matter how fast taproot's activation threshold is reached by miners,
> there will be six months between the time signal tracking starts and when
> nodes will begin enforcing taproot's rules.  This gives the userbase even
> more time to upgrade than if we had used the most recently proposed start
> date for a BIP8 activation (~July 23rd).[2]
>
> ### Succeed, or fail fast
>
> The earlier version of this proposal was documented over 200 days ago[3]
> and taproot's underlying code was merged into Bitcoin Core over 140 days
> ago.[4]  If we had started Speedy Trial at the time taproot
> was merged (which is a bit unrealistic), we would've either be less than
> two months away from having taproot or we would have moved on to the
> next activation attempt over a month ago.
>
> Instead, we've debated at length and don't appear to be any closer to
> what I think is a widely acceptable solution than when the mailing list
> began discussing post-segwit activation schemes over a year ago.[5]  I
> think Speedy Trial is a way to generate fast progress that will either
> end the debate (for now, if activation is successful) or give us some
> actual data upon which to base future taproot activation proposals.
>
> Of course, for those who enjoy the debate, discussion can continue while
> waiting for the results of Speedy Trial.
>
> ### Base activation protocol
>
> The idea can be implemented on top of either Bitcoin Core's existing
> BIP9 code or its proposed BIP8 patchset.[6]
>
> - BIP9 uses two time-based[7] parameters, starttime and timeout.  Using
>   these values plus a time-based parameter for the minimum activation
>   delay would give three months for miners to activate taproot, but some
>   of that time near the start or the end might not be usable due to
>   signals only being measured in full retarget periods.  However, the
>   six month time for users to upgrade their node would be not be
>   affected by either slow or fast block production.
>
>     BIP9 is already part of Bitcoin Core and I think the changes being
>     proposed would be relatively small, resulting in a small patch that
>     could be easy to review.
>
> - BIP8 uses two height-based parameters, startheight and timeoutheight.
>   Using height values would ensure miners had a certain number of
>   retarget periods (6) to lock in taproot and that there'd be a certain
>   number of blocks (about 24,000) until activation, although latest lock
>   in and expected activation could occur moderately earlier or later
>   than the estimated three and six months.
>
>     BIP8 would likely be used if Speedy Trial fails, so it could be
>     advantageous to base this proposal on BIP8 so that we gain
>     experience running that code in production.
>
> For additional discussion about using times versus heights, see today's
> log for ##taproot-activation.[11]
>
> ### Additional concerns
>
> - Encourages false signaling: false signaling is when miners signal
>   readiness to enforce rules that their nodes don't actually support.
>   This was partially responsible for a six-block reorg shortly after the
>   final BIP66 activation[8] and was found to still be a problem during
>   the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
>
>   Because Speedy Trial only gives miners a maximum of three months to
>   signal support for taproot, it may encourage such false signaling.  If
>   taproot locks in as a result of their signaling but most of them fail
>   to upgrade by the activation date several months later, unprepared
>   miners could lose large amounts of money and users could see long
>   reorgs (with unupgraded nodes and SPV lite clients potentially losing
>   money).
>
>   Compared to other activation proposals, I think the only difference is
>   Speedy Trial's short timeline.  False signaling is possible with any
>   other proposal and the same problems can occur if miners fail to
>   upgrade for any mandatory activation.
>
> ### Additional advantages
>
> - No mandatory signaling: at no time are miners required to signal by
>   Speedy Trial.  This includes no mandatory signaling during the
>   locked_in period(s), although such signaling will be encouraged (as it
>   was with BIP9[10]).
>
> - Party time: to a lesser degree, a benefit mentioned for flag day
>   activation may also apply here: we could get up to six months
>   advanced notice of taproot activation, allowing users, developers, and
>   organizations to prepare software, announcements, and celebrations for
>   that event.
>
> ## Implementation details and next steps
>
> Initial discussion about implementation may be found in today's
> ##taproot-activation log.[11] If it appears Speedy Trial may have
> traction, Russell O'Connor has offered to work on a patch against BIP8
> implementing it.
>
> ## Acknowledgments
>
> The original idea for a short-duration attempt was discussed in the
> ##taproot-activation IRC channel last July and the revised idea saw
> additional evaluation there this week.  Despite growing frustration,
> discussion has been overwhelmingly constructive, for which all the
> contributors should be commended.  Although this should not in any way
> imply endorsement, I'm grateful for the review and comments on a draft
> of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> O'Connor, and IRC users maybehuman and proofofkeags
>
> ## Footnotes
>
> [1]
> https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
>
> [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
>     seemed to have near-universal support during the 2021-02-16 IRC
>     meeting.  See:
> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
>
> [3]
> https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
>
> [4] https://github.com/bitcoin/bitcoin/pull/19953
>
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
>
> [6] https://github.com/bitcoin/bitcoin/pull/19573
>
> [7] BIP9's times are based on the median of the past 11 blocks, which
>     usually trails UTC by about 90 minutes but which can trail behind
>     realtime significantly if miners are doing weird things.
>
> [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
>
> [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
>
> [10]
> https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
>
> [11] http://gnusha.org/taproot-activation/2021-03-05.log
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 13821 bytes --]