diff options
author | Jeremy <jlrubin@mit.edu> | 2021-03-05 20:44:33 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-06 04:44:49 +0000 |
commit | 09f10da725f49ad93b9976eeb28cec3357807f0f (patch) | |
tree | d68cbcd12f5a02169a1a3621a768a9e395a63a60 | |
parent | 226618d84420ed5f489e2617d13f3bf6cd36eb47 (diff) | |
download | pi-bitcoindev-09f10da725f49ad93b9976eeb28cec3357807f0f.tar.gz pi-bitcoindev-09f10da725f49ad93b9976eeb28cec3357807f0f.zip |
Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
-rw-r--r-- | a6/6ae3884885beb0ffc10e65e18f53b599370240 | 618 |
1 files changed, 618 insertions, 0 deletions
diff --git a/a6/6ae3884885beb0ffc10e65e18f53b599370240 b/a6/6ae3884885beb0ffc10e65e18f53b599370240 new file mode 100644 index 000000000..7d884abb3 --- /dev/null +++ b/a6/6ae3884885beb0ffc10e65e18f53b599370240 @@ -0,0 +1,618 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id C6CD3C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 04:44:49 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id ACC9060657 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 04:44:49 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.499 +X-Spam-Level: +X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 + tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, + SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 0fkRMeQLgZ6f + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 04:44:47 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 6087A60605 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 04:44:47 +0000 (UTC) +Received: from mail-il1-f181.google.com (mail-il1-f181.google.com + [209.85.166.181]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1264ijIv011080 + (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) + for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 5 Mar 2021 23:44:45 -0500 +Received: by mail-il1-f181.google.com with SMTP id i18so3917693ilq.13 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 05 Mar 2021 20:44:45 -0800 (PST) +X-Gm-Message-State: AOAM533jEVSskv0giHZ5q9/Ir+yuV5k/QQeLMIu1fRPz2uJoTSz52lsc + BWuIcKicZpQf/1PeFrPaItjAwVEbCtpbnPSD59U= +X-Google-Smtp-Source: ABdhPJzh44LHUa9018CgXZMtP85GAmuoiBqIE29le8VST4ZOJ9LDIedW3BaooL0E/6kaUYqmWQ0Eh0P+k+xLAB2EL9I= +X-Received: by 2002:a05:6e02:1ca4:: with SMTP id + x4mr11393261ill.58.1615005884987; + Fri, 05 Mar 2021 20:44:44 -0800 (PST) +MIME-Version: 1.0 +References: <20210306034343.fhwrxmq6gbb2os5m@ganymede> +In-Reply-To: <20210306034343.fhwrxmq6gbb2os5m@ganymede> +From: Jeremy <jlrubin@mit.edu> +Date: Fri, 5 Mar 2021 20:44:33 -0800 +X-Gmail-Original-Message-ID: <CAD5xwhjOFUPpXZ97CWSSpngEiAt7tmTikS+==-0AKbHPzEXieg@mail.gmail.com> +Message-ID: <CAD5xwhjOFUPpXZ97CWSSpngEiAt7tmTikS+==-0AKbHPzEXieg@mail.gmail.com> +To: "David A. Harding" <dave@dtrt.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000015bff705bcd6dcee" +Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial" +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sat, 06 Mar 2021 04:44:49 -0000 + +--00000000000015bff705bcd6dcee +Content-Type: text/plain; charset="UTF-8" + +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 +> + +--00000000000015bff705bcd6dcee +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:#000000">Thank you for resurfacing= + and collating this concept.</div><div class=3D"gmail_default" style=3D"fon= +t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></di= +v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se= +rif;font-size:small;color:#000000">At this time I don't see major issue= +s with this course of action and think it represents not only a reasonable = +compromise between all different perspectives, but also gives us an opportu= +nity to learn more about less 'slow' yet safe consensus upgrades. I= +n particular, I am very happy to see the earliest activation concept includ= +ed.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet= +ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail= +_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= +olor:#000000">Best,</div><div class=3D"gmail_default" style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl= +ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-= +size:small;color:#000000">Jeremy<br clear=3D"all"></div><div><div dir=3D"lt= +r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D= +"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@= +JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank= +"></a></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir= +=3D"ltr" class=3D"gmail_attr">On Fri, Mar 5, 2021 at 7:44 PM David A. Hardi= +ng via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.= +org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockqu= +ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= + solid rgb(204,204,204);padding-left:1ex">On the ##taproot-activation IRC c= +hannel, Russell O'Connor recently<br> +proposed a modification of the "Let's see what happens" activ= +ation<br> +proposal.[1] The idea received significant discussion and seemed<br> +acceptable to several people who could not previously agree on a<br> +proposal (although this doesn't necessarily make it their first<br> +choice).=C2=A0 The following is my attempt at a description.<br> +<br> +1. Start soon: shortly after the release of software containing this<br> +=C2=A0 =C2=A0proposed activation logic, nodes will begin counting blocks to= +wards<br> +=C2=A0 =C2=A0the 90% threshold required to lock in taproot.[2]<br> +<br> +2. Stop soon: if the lockin threshold isn't reached within approximatel= +y<br> +=C2=A0 =C2=A0three months, the activation attempt fails.=C2=A0 There is no = +mandatory<br> +=C2=A0 =C2=A0activation and everyone is encouraged to try again using diffe= +rent<br> +=C2=A0 =C2=A0activation parameters.<br> +<br> +2. Delayed activation: in the happy occasion where the lockin threshold<br> +=C2=A0 =C2=A0is reached, taproot is guaranteed to eventually activate---but= + not<br> +=C2=A0 =C2=A0until approximately six months after signal tracking started.<= +br> +<br> +## Example timeline<br> +<br> +(All dates approximate; see the section below about BIP9 vs BIP8.)<br> +<br> +- T+0: release of one or more full nodes with activation code<br> +- T+14: signal tracking begins<br> +- T+28: earliest possible lock in<br> +- T+104: locked in by this date or need to try a different activation proce= +ss<br> +- T+194: activation (if lockin occurred)<br> +<br> +## Analysis<br> +<br> +The goal of Speedy Trial is to allow a taproot activation attempt to<br> +either quickly succeed or quickly fail---without compromising safety in<br> +either case.=C2=A0 Details below:<br> +<br> +### Mitigating the problems of early success<br> +<br> +New rules added in a soft fork need to be enforced by a large part of<br> +the economy or there's a risk that a long chain of blocks breaking the<= +br> +rules will be accepted by some users and rejected by others, causing a<br> +chain split that can result in large direct losses to transaction<br> +receivers and potentially even larger indirect losses to holders due to<br> +reduced confidence in the safety of the Bitcoin system.<br> +<br> +One step developers have taken in the past to ensure widespread adoption<br= +> +of new consensus rules is programming in a delay between the time software<= +br> +with those rules is expected to be released and when the software starts<br= +> +tracking which blocks signal for activation.=C2=A0 For example:<br> +<br> +=C2=A0 =C2=A0 Soft fork=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Release=C2=A0 =C2=A0 |= + Start=C2=A0 =C2=A0 =C2=A0 | Delta <br> +=C2=A0 =C2=A0 -----------------+------------+------------+----------<br> +=C2=A0 =C2=A0 BIP68 (v0.12.1)=C2=A0 | 2016-04-15 | 2016-05-11 | 26 days <br= +> +=C2=A0 =C2=A0 BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days<br> +<br> +=C2=A0 =C2=A0 Sources: BitcoinCore.org, <a href=3D"https://gist.github.com/= +ajtowns/1c5e3b8bdead01124c04c45f01c817bc" rel=3D"noreferrer" target=3D"_bla= +nk">https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc</a><br= +> +<br> +Speedy Trial replaces most of that upfront delay with a backend delay.<br> +No matter how fast taproot's activation threshold is reached by miners,= +<br> +there will be six months between the time signal tracking starts and when<b= +r> +nodes will begin enforcing taproot's rules.=C2=A0 This gives the userba= +se even<br> +more time to upgrade than if we had used the most recently proposed start<b= +r> +date for a BIP8 activation (~July 23rd).[2] <br> +<br> +### Succeed, or fail fast<br> +<br> +The earlier version of this proposal was documented over 200 days ago[3]<br= +> +and taproot's underlying code was merged into Bitcoin Core over 140 day= +s<br> +ago.[4]=C2=A0 If we had started Speedy Trial at the time taproot<br> +was merged (which is a bit unrealistic), we would've either be less tha= +n<br> +two months away from having taproot or we would have moved on to the<br> +next activation attempt over a month ago.<br> +<br> +Instead, we've debated at length and don't appear to be any closer = +to<br> +what I think is a widely acceptable solution than when the mailing list<br> +began discussing post-segwit activation schemes over a year ago.[5]=C2=A0 I= +<br> +think Speedy Trial is a way to generate fast progress that will either<br> +end the debate (for now, if activation is successful) or give us some<br> +actual data upon which to base future taproot activation proposals.<br> +<br> +Of course, for those who enjoy the debate, discussion can continue while<br= +> +waiting for the results of Speedy Trial.<br> +<br> +### Base activation protocol<br> +<br> +The idea can be implemented on top of either Bitcoin Core's existing<br= +> +BIP9 code or its proposed BIP8 patchset.[6]<br> +<br> +- BIP9 uses two time-based[7] parameters, starttime and timeout.=C2=A0 Usin= +g<br> +=C2=A0 these values plus a time-based parameter for the minimum activation<= +br> +=C2=A0 delay would give three months for miners to activate taproot, but so= +me<br> +=C2=A0 of that time near the start or the end might not be usable due to<br= +> +=C2=A0 signals only being measured in full retarget periods.=C2=A0 However,= + the<br> +=C2=A0 six month time for users to upgrade their node would be not be<br> +=C2=A0 affected by either slow or fast block production.<br> +<br> +=C2=A0 =C2=A0 BIP9 is already part of Bitcoin Core and I think the changes = +being<br> +=C2=A0 =C2=A0 proposed would be relatively small, resulting in a small patc= +h that<br> +=C2=A0 =C2=A0 could be easy to review.<br> +<br> +- BIP8 uses two height-based parameters, startheight and timeoutheight.<br> +=C2=A0 Using height values would ensure miners had a certain number of<br> +=C2=A0 retarget periods (6) to lock in taproot and that there'd be a ce= +rtain<br> +=C2=A0 number of blocks (about 24,000) until activation, although latest lo= +ck<br> +=C2=A0 in and expected activation could occur moderately earlier or later<b= +r> +=C2=A0 than the estimated three and six months.<br> +<br> +=C2=A0 =C2=A0 BIP8 would likely be used if Speedy Trial fails, so it could = +be<br> +=C2=A0 =C2=A0 advantageous to base this proposal on BIP8 so that we gain<br= +> +=C2=A0 =C2=A0 experience running that code in production.<br> +<br> +For additional discussion about using times versus heights, see today's= +<br> +log for ##taproot-activation.[11]<br> +<br> +### Additional concerns<br> +<br> +- Encourages false signaling: false signaling is when miners signal<br> +=C2=A0 readiness to enforce rules that their nodes don't actually suppo= +rt.<br> +=C2=A0 This was partially responsible for a six-block reorg shortly after t= +he<br> +=C2=A0 final BIP66 activation[8] and was found to still be a problem during= +<br> +=C2=A0 the BIP68 lockin period despite BIP9 being designed to avoid it.[9]<= +br> +<br> +=C2=A0 Because Speedy Trial only gives miners a maximum of three months to<= +br> +=C2=A0 signal support for taproot, it may encourage such false signaling.= +=C2=A0 If<br> +=C2=A0 taproot locks in as a result of their signaling but most of them fai= +l<br> +=C2=A0 to upgrade by the activation date several months later, unprepared<b= +r> +=C2=A0 miners could lose large amounts of money and users could see long<br= +> +=C2=A0 reorgs (with unupgraded nodes and SPV lite clients potentially losin= +g<br> +=C2=A0 money).<br> +<br> +=C2=A0 Compared to other activation proposals, I think the only difference = +is<br> +=C2=A0 Speedy Trial's short timeline.=C2=A0 False signaling is possible= + with any<br> +=C2=A0 other proposal and the same problems can occur if miners fail to<br> +=C2=A0 upgrade for any mandatory activation.<br> +<br> +### Additional advantages<br> +<br> +- No mandatory signaling: at no time are miners required to signal by<br> +=C2=A0 Speedy Trial.=C2=A0 This includes no mandatory signaling during the<= +br> +=C2=A0 locked_in period(s), although such signaling will be encouraged (as = +it<br> +=C2=A0 was with BIP9[10]).<br> +<br> +- Party time: to a lesser degree, a benefit mentioned for flag day<br> +=C2=A0 activation may also apply here: we could get up to six months<br> +=C2=A0 advanced notice of taproot activation, allowing users, developers, a= +nd<br> +=C2=A0 organizations to prepare software, announcements, and celebrations f= +or<br> +=C2=A0 that event.<br> +<br> +## Implementation details and next steps<br> +<br> +Initial discussion about implementation may be found in today's<br> +##taproot-activation log.[11] If it appears Speedy Trial may have<br> +traction, Russell O'Connor has offered to work on a patch against BIP8<= +br> +implementing it.<br> +<br> +## Acknowledgments<br> +<br> +The original idea for a short-duration attempt was discussed in the<br> +##taproot-activation IRC channel last July and the revised idea saw<br> +additional evaluation there this week.=C2=A0 Despite growing frustration,<b= +r> +discussion has been overwhelmingly constructive, for which all the<br> +contributors should be commended.=C2=A0 Although this should not in any way= +<br> +imply endorsement, I'm grateful for the review and comments on a draft<= +br> +of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,<br= +> +Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell<br> +O'Connor, and IRC users maybehuman and proofofkeags<br> +<br> +## Footnotes<br> +<br> +[1] <a href=3D"https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.= +E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29" rel=3D"noreferrer" tar= +get=3D"_blank">https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.= +E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29</a><br> +<br> +[2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period<br> +=C2=A0 =C2=A0 seemed to have near-universal support during the 2021-02-16 I= +RC<br> +=C2=A0 =C2=A0 meeting.=C2=A0 See: <a href=3D"https://en.bitcoin.it/wiki/Tap= +root_activation_proposal_202102" rel=3D"noreferrer" target=3D"_blank">https= +://en.bitcoin.it/wiki/Taproot_activation_proposal_202102</a><br> +<br> +[3] <a href=3D"https://en.bitcoin.it/w/index.php?title=3DTaproot_activation= +_proposals&oldid=3D68062" rel=3D"noreferrer" target=3D"_blank">https://= +en.bitcoin.it/w/index.php?title=3DTaproot_activation_proposals&oldid=3D= +68062</a><br> +<br> +[4] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19953" rel=3D"norefe= +rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19953</a><b= +r> +<br> +[5] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020= +-January/017547.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li= +nuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html</a><br> +<br> +[6] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19573" rel=3D"norefe= +rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19573</a><b= +r> +<br> +[7] BIP9's times are based on the median of the past 11 blocks, which<b= +r> +=C2=A0 =C2=A0 usually trails UTC by about 90 minutes but which can trail be= +hind<br> +=C2=A0 =C2=A0 realtime significantly if miners are doing weird things.<br> +<br> +[8] <a href=3D"https://en.bitcoin.it/wiki/July_2015_chain_forks" rel=3D"nor= +eferrer" target=3D"_blank">https://en.bitcoin.it/wiki/July_2015_chain_forks= +</a><br> +<br> +[9] <a href=3D"https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.= +html#l-32" rel=3D"noreferrer" target=3D"_blank">https://buildingbitcoin.org= +/bitcoin-core-dev/log-2016-06-21.html#l-32</a><br> +<br> +[10] <a href=3D"https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c7= +35f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339" rel=3D"nore= +ferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/ed25cb58f= +605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339</a= +><br> +<br> +[11] <a href=3D"http://gnusha.org/taproot-activation/2021-03-05.log" rel=3D= +"noreferrer" target=3D"_blank">http://gnusha.org/taproot-activation/2021-03= +-05.log</a><br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000015bff705bcd6dcee-- + |