diff options
author | Russell O'Connor <roconnor@blockstream.com> | 2021-03-06 09:44:44 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-06 14:44:59 +0000 |
commit | 158ad4e08e5847dffa25c99322113730bfddda17 (patch) | |
tree | 63eedbc5e386b25c894cf626d8dd04b667ce33ae /c0 | |
parent | f491affe6415877a40422f4ebbb407451be161a6 (diff) | |
download | pi-bitcoindev-158ad4e08e5847dffa25c99322113730bfddda17.tar.gz pi-bitcoindev-158ad4e08e5847dffa25c99322113730bfddda17.zip |
Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Diffstat (limited to 'c0')
-rw-r--r-- | c0/0f8c3254c004d02660ce8411a747e3559e53df | 746 |
1 files changed, 746 insertions, 0 deletions
diff --git a/c0/0f8c3254c004d02660ce8411a747e3559e53df b/c0/0f8c3254c004d02660ce8411a747e3559e53df new file mode 100644 index 000000000..7e9b4c267 --- /dev/null +++ b/c0/0f8c3254c004d02660ce8411a747e3559e53df @@ -0,0 +1,746 @@ +Return-Path: <roconnor@blockstream.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 2D593C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 14:44:59 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 0FBE742FFD + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 14:44:59 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.9 +X-Spam-Level: +X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp2.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) + header.d=blockstream-com.20150623.gappssmtp.com +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id VaKI4I9FpX6C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 14:44:57 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com + [IPv6:2607:f8b0:4864:20::f2c]) + by smtp2.osuosl.org (Postfix) with ESMTPS id D170442FB0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Mar 2021 14:44:56 +0000 (UTC) +Received: by mail-qv1-xf2c.google.com with SMTP id cw15so2458836qvb.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 06 Mar 2021 06:44:56 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=blockstream-com.20150623.gappssmtp.com; s=20150623; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=1qs4J4JF3HscUWLZ6NOZlGYXG4WiDTyYc6AIUZQoC1Y=; + b=XH9XvFOZGeLU7QxecQ2z54tPCCXeZ7Sso+1z4pFfVy+/15OVXTU6SWcAcjJl5N+5Wh + vpUFOvvZ6vxlg7q0KsD9zuBAkZlH7Mn/c/0zwtemuuCjUl9jHNcePdpiGCSpRIAtSnXv + SsLXQ1EldzLVO2rt4GmbpCurLiuXI2pgJdkU0ChA8LKIQqEMlfud5urEtyD/XpmtMI7z + YRcA+SWrhlnk0o+b42E7aeiRq0iC8x0N6pNxzYdDFHsKtjLneLCA79yFUhbOYQZyre8M + byrArxV+WgC+785eDT3vMfI0Yd5jz+E+eW7Y7loqjrB82klLnsxoqBU0WBPNyydWLSIs + 710Q== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to; + bh=1qs4J4JF3HscUWLZ6NOZlGYXG4WiDTyYc6AIUZQoC1Y=; + b=nGSnAmEveXOEkBw/5sEk+s3u4MEepDd29JFBxYX4JvwgZMmT/0STSbCJqHQF8BzwJl + y9cPpbqhkfC6cZ5v+CgOSP00APEIhDDa1C77nUXiz3M7qNDlVhps7zvgcDusHH/jeFdF + hsvDGzIeUToHpLKzGzplFtww6gs5V5h/ztp4kQbQKlaWn5U8yZ3ooy+hGzZQwhQdYR6+ + m71d/oDJWTKxRPQLGCocpsuqQH+XEH0Rs1GKCgYpbLGtHU53QnmLcBWanP28MAjx8YQd + J9PDR6LLbOureGQemyDltUFuMhqGG+oAguGjbKWujqUFNFY9QosJ2I6o7aTT0/lLyjWN + YABQ== +X-Gm-Message-State: AOAM531fNr8MLaLCDh9JxFtPBVZkBkRwm07W3wcFBVTNsGAqktBHoBlk + /LsLeDwgAyL41mm8/2ABHkIK7H53Umztpu3ycKzaYARujqESEYMV +X-Google-Smtp-Source: ABdhPJxL75fZwyp2vBia3AOf1CB31/Hz83mhQE8mj1hfbEMElyypL/DfUoCKu+23xnX+tRk2jQcXL/QfS5G35z54KyY= +X-Received: by 2002:a0c:ea81:: with SMTP id d1mr13412091qvp.57.1615041895527; + Sat, 06 Mar 2021 06:44:55 -0800 (PST) +MIME-Version: 1.0 +References: <20210306034343.fhwrxmq6gbb2os5m@ganymede> + <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com> +In-Reply-To: <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com> +From: "Russell O'Connor" <roconnor@blockstream.com> +Date: Sat, 6 Mar 2021 09:44:44 -0500 +Message-ID: <CAMZUoKmxkHE_d2jTy-a2F9Xr7HxNNb3oyAZ4Wr=4kf8qTP5bdw@mail.gmail.com> +To: Andrew Chow <achow101-lists@achow101.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000007b0f6d05bcdf3e6b" +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 14:44:59 -0000 + +--0000000000007b0f6d05bcdf3e6b +Content-Type: text/plain; charset="UTF-8" + +Hi Andrew, + +This is a slight misunderstanding of the proposal. Rather than an extended +lockin period (a term I've erroneously used in the past) it is really a +minimum activation height. + +Thus using your figures it would instead be: + +* start height = 681408 /* about May 1st */ +* timeout height = 695520 /* about Aug 7th */ +* min activation height = 709632 /* about Nov 13th */ +* lockinontimeout = False +* signaling bit = 2 +* threshold = 1815/2016 blocks (90%) + +This guarantees 7 retargeting periods between start height and timeout +height. + +Being able to make a guarantee about how many retargeting periods we get is +perhaps something worth pursuing given that the signaling period is so +short for this trial. + +On Sat, Mar 6, 2021 at 1:04 AM Andrew Chow via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> I like this idea. +> +> In terms of actual parameters, I propose that we base this Speedy Trial +> off of BIP 8 with the following parameters: +> * start height = 681408 +> * timeout height = 695520 +> * lockinontimeout = False +> * signaling bit = 2 +> * threshold = 1815/2016 blocks (90%) +> +> For the extended lockin period, I propose 14112 blocks, which is 7 +> retarget periods. Thus the earliest activation height will be 697536 and +> the latest activation height will be 709632. +> +> This will give us an approximate start time of May 1st 2021 and an +> approximate timeout time of August 7th 2021, for a total activation +> period of just over 3 months. The extended lockin period is the same +> number of blocks as the activation period so that will also be just over +> 3 months, giving us the latest activation time of November 13th, 2021. +> If miners activated as soon as possible, the earliest activation time +> would be August 21st 2021. +> +> Additionally, this timeline assumes a mid-April release of Bitcoin Core +> 0.21.1 containing these parameters. They could be changed to move up if +> the expected release date were sooner. +> +> +> Andrew Chow +> +> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev 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 +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000007b0f6d05bcdf3e6b +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Hi Andrew,</div><div><br></div><div>This is a slight = +misunderstanding of the proposal.=C2=A0 Rather than an extended lockin peri= +od (a term I've erroneously used in the past) it is really a minimum ac= +tivation height.</div><div><br></div><div>Thus using your figures it would = +instead be:</div><div><br></div><div>* start height =3D 681408 /* about May= + 1st */<br> +* timeout height =3D 695520 /* about Aug 7th */<br></div><div>* min activat= +ion height =3D 709632 /* about Nov 13th */<br></div><div> +* lockinontimeout =3D False<br> +* signaling bit =3D 2<br> +* threshold =3D 1815/2016 blocks (90%)</div><div><br></div><div>This guaran= +tees 7 retargeting periods between start height and timeout height.</div><d= +iv><br></div><div>Being able to make a guarantee about how many retargeting= + periods we get is perhaps something worth pursuing given that the signalin= +g period is so short for this trial.<br></div><br><div class=3D"gmail_quote= +"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 6, 2021 at 1:04 AM Andr= +ew Chow via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfounda= +tion.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><bl= +ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= +t:1px solid rgb(204,204,204);padding-left:1ex">I like this idea.<br> +<br> +In terms of actual parameters, I propose that we base this Speedy Trial<br> +off of BIP 8 with the following parameters:<br> +* start height =3D 681408<br> +* timeout height =3D 695520<br> +* lockinontimeout =3D False<br> +* signaling bit =3D 2<br> +* threshold =3D 1815/2016 blocks (90%)<br> +<br> +For the extended lockin period, I propose 14112 blocks, which is 7<br> +retarget periods. Thus the earliest activation height will be 697536 and<br= +> +the latest activation height will be 709632.<br> +<br> +This will give us an approximate start time of May 1st 2021 and an<br> +approximate timeout time of August 7th 2021, for a total activation<br> +period of just over 3 months. The extended lockin period is the same<br> +number of blocks as the activation period so that will also be just over<br= +> +3 months, giving us the latest activation time of November 13th, 2021.<br> +If miners activated as soon as possible, the earliest activation time<br> +would be August 21st 2021.<br> +<br> +Additionally, this timeline assumes a mid-April release of Bitcoin Core<br> +0.21.1 containing these parameters. They could be changed to move up if<br> +the expected release date were sooner.<br> +<br> +<br> +Andrew Chow<br> +<br> +On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:<br> +> On the ##taproot-activation IRC channel, Russell O'Connor recently= +<br> +> proposed a modification of the "Let's see what happens" = +activation<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<b= +r> +>=C2=A0 =C2=A0 =C2=A0proposed activation logic, nodes will begin countin= +g blocks towards<br> +>=C2=A0 =C2=A0 =C2=A0the 90% threshold required to lock in taproot.[2]<b= +r> +><br> +> 2. Stop soon: if the lockin threshold isn't reached within approxi= +mately<br> +>=C2=A0 =C2=A0 =C2=A0three months, the activation attempt fails.=C2=A0 T= +here is no mandatory<br> +>=C2=A0 =C2=A0 =C2=A0activation and everyone is encouraged to try again = +using different<br> +>=C2=A0 =C2=A0 =C2=A0activation parameters.<br> +><br> +> 2. Delayed activation: in the happy occasion where the lockin threshol= +d<br> +>=C2=A0 =C2=A0 =C2=A0is reached, taproot is guaranteed to eventually act= +ivate---but not<br> +>=C2=A0 =C2=A0 =C2=A0until approximately six months after signal trackin= +g 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 = +process<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<b= +r> +> either quickly succeed or quickly fail---without compromising safety i= +n<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 t= +o<br> +> reduced confidence in the safety of the Bitcoin system.<br> +><br> +> One step developers have taken in the past to ensure widespread adopti= +on<br> +> of new consensus rules is programming in a delay between the time soft= +ware<br> +> with those rules is expected to be released and when the software star= +ts<br> +> tracking which blocks signal for activation.=C2=A0 For example:<br> +><br> +>=C2=A0 =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 =C2=A0 -----------------+------------+------------+------= +----<br> +>=C2=A0 =C2=A0 =C2=A0 BIP68 (v0.12.1)=C2=A0 | 2016-04-15 | 2016-05-11 | = +26 days<br> +>=C2=A0 =C2=A0 =C2=A0 BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 da= +ys<br> +><br> +>=C2=A0 =C2=A0 =C2=A0 Sources: BitcoinCore.org, <a href=3D"https://gist.= +github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc" rel=3D"noreferrer" tar= +get=3D"_blank">https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c8= +17bc</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 mi= +ners,<br> +> there will be six months between the time signal tracking starts and w= +hen<br> +> nodes will begin enforcing taproot's rules.=C2=A0 This gives the u= +serbase even<br> +> more time to upgrade than if we had used the most recently proposed st= +art<br> +> 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 14= +0 days<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 les= +s than<br> +> two months away from having taproot or we would have moved on to the<b= +r> +> next activation attempt over a month ago.<br> +><br> +> Instead, we've debated at length and don't appear to be any cl= +oser to<br> +> what I think is a widely acceptable solution than when the mailing lis= +t<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 whi= +le<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 existi= +ng<br> +> BIP9 code or its proposed BIP8 patchset.[6]<br> +><br> +> - BIP9 uses two time-based[7] parameters, starttime and timeout.=C2=A0= + Using<br> +>=C2=A0 =C2=A0 these values plus a time-based parameter for the minimum = +activation<br> +>=C2=A0 =C2=A0 delay would give three months for miners to activate tapr= +oot, but some<br> +>=C2=A0 =C2=A0 of that time near the start or the end might not be usabl= +e due to<br> +>=C2=A0 =C2=A0 signals only being measured in full retarget periods.=C2= +=A0 However, the<br> +>=C2=A0 =C2=A0 six month time for users to upgrade their node would be n= +ot be<br> +>=C2=A0 =C2=A0 affected by either slow or fast block production.<br> +><br> +>=C2=A0 =C2=A0 =C2=A0 BIP9 is already part of Bitcoin Core and I think t= +he changes being<br> +>=C2=A0 =C2=A0 =C2=A0 proposed would be relatively small, resulting in a= + small patch that<br> +>=C2=A0 =C2=A0 =C2=A0 could be easy to review.<br> +><br> +> - BIP8 uses two height-based parameters, startheight and timeoutheight= +.<br> +>=C2=A0 =C2=A0 Using height values would ensure miners had a certain num= +ber of<br> +>=C2=A0 =C2=A0 retarget periods (6) to lock in taproot and that there= +9;d be a certain<br> +>=C2=A0 =C2=A0 number of blocks (about 24,000) until activation, althoug= +h latest lock<br> +>=C2=A0 =C2=A0 in and expected activation could occur moderately earlier= + or later<br> +>=C2=A0 =C2=A0 than the estimated three and six months.<br> +><br> +>=C2=A0 =C2=A0 =C2=A0 BIP8 would likely be used if Speedy Trial fails, s= +o it could be<br> +>=C2=A0 =C2=A0 =C2=A0 advantageous to base this proposal on BIP8 so that= + we gain<br> +>=C2=A0 =C2=A0 =C2=A0 experience running that code in production.<br> +><br> +> For additional discussion about using times versus heights, see today&= +#39;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 =C2=A0 readiness to enforce rules that their nodes don't act= +ually support.<br> +>=C2=A0 =C2=A0 This was partially responsible for a six-block reorg shor= +tly after the<br> +>=C2=A0 =C2=A0 final BIP66 activation[8] and was found to still be a pro= +blem during<br> +>=C2=A0 =C2=A0 the BIP68 lockin period despite BIP9 being designed to av= +oid it.[9]<br> +><br> +>=C2=A0 =C2=A0 Because Speedy Trial only gives miners a maximum of three= + months to<br> +>=C2=A0 =C2=A0 signal support for taproot, it may encourage such false s= +ignaling.=C2=A0 If<br> +>=C2=A0 =C2=A0 taproot locks in as a result of their signaling but most = +of them fail<br> +>=C2=A0 =C2=A0 to upgrade by the activation date several months later, u= +nprepared<br> +>=C2=A0 =C2=A0 miners could lose large amounts of money and users could = +see long<br> +>=C2=A0 =C2=A0 reorgs (with unupgraded nodes and SPV lite clients potent= +ially losing<br> +>=C2=A0 =C2=A0 money).<br> +><br> +>=C2=A0 =C2=A0 Compared to other activation proposals, I think the only = +difference is<br> +>=C2=A0 =C2=A0 Speedy Trial's short timeline.=C2=A0 False signaling = +is possible with any<br> +>=C2=A0 =C2=A0 other proposal and the same problems can occur if miners = +fail to<br> +>=C2=A0 =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 =C2=A0 Speedy Trial.=C2=A0 This includes no mandatory signaling = +during the<br> +>=C2=A0 =C2=A0 locked_in period(s), although such signaling will be enco= +uraged (as it<br> +>=C2=A0 =C2=A0 was with BIP9[10]).<br> +><br> +> - Party time: to a lesser degree, a benefit mentioned for flag day<br> +>=C2=A0 =C2=A0 activation may also apply here: we could get up to six mo= +nths<br> +>=C2=A0 =C2=A0 advanced notice of taproot activation, allowing users, de= +velopers, and<br> +>=C2=A0 =C2=A0 organizations to prepare software, announcements, and cel= +ebrations for<br> +>=C2=A0 =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 frustrati= +on,<br> +> discussion has been overwhelmingly constructive, for which all the<br> +> contributors should be commended.=C2=A0 Although this should not in an= +y way<br> +> imply endorsement, I'm grateful for the review and comments on a d= +raft<br> +> of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belche= +r,<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= +" target=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 perio= +d<br> +>=C2=A0 =C2=A0 =C2=A0 seemed to have near-universal support during the 2= +021-02-16 IRC<br> +>=C2=A0 =C2=A0 =C2=A0 meeting.=C2=A0 See: <a href=3D"https://en.bitcoin.= +it/wiki/Taproot_activation_proposal_202102" rel=3D"noreferrer" target=3D"_b= +lank">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_activ= +ation_proposals&oldid=3D68062" rel=3D"noreferrer" target=3D"_blank">htt= +ps://en.bitcoin.it/w/index.php?title=3DTaproot_activation_proposals&old= +id=3D68062</a><br> +><br> +> [4] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19953" rel=3D"n= +oreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19953<= +/a><br> +><br> +> [5] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2020-January/017547.html" rel=3D"noreferrer" target=3D"_blank">https://lis= +ts.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html</a><b= +r> +><br> +> [6] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19573" rel=3D"n= +oreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19573<= +/a><br> +><br> +> [7] BIP9's times are based on the median of the past 11 blocks, wh= +ich<br> +>=C2=A0 =C2=A0 =C2=A0 usually trails UTC by about 90 minutes but which c= +an trail behind<br> +>=C2=A0 =C2=A0 =C2=A0 realtime significantly if miners are doing weird t= +hings.<br> +><br> +> [8] <a href=3D"https://en.bitcoin.it/wiki/July_2015_chain_forks" rel= +=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/July_2015_chai= +n_forks</a><br> +><br> +> [9] <a href=3D"https://buildingbitcoin.org/bitcoin-core-dev/log-2016-0= +6-21.html#l-32" rel=3D"noreferrer" target=3D"_blank">https://buildingbitcoi= +n.org/bitcoin-core-dev/log-2016-06-21.html#l-32</a><br> +><br> +> [10] <a href=3D"https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba= +583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339" rel=3D= +"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/ed25= +cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L3= +39</a><br> +><br> +> [11] <a href=3D"http://gnusha.org/taproot-activation/2021-03-05.log" r= +el=3D"noreferrer" target=3D"_blank">http://gnusha.org/taproot-activation/20= +21-03-05.log</a><br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">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= +/mailman/listinfo/bitcoin-dev</a><br> +<br> +<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></div> + +--0000000000007b0f6d05bcdf3e6b-- + |