summaryrefslogtreecommitdiff
path: root/c0
diff options
context:
space:
mode:
authorRussell O'Connor <roconnor@blockstream.com>2021-03-06 09:44:44 -0500
committerbitcoindev <bitcoindev@gnusha.org>2021-03-06 14:44:59 +0000
commit158ad4e08e5847dffa25c99322113730bfddda17 (patch)
tree63eedbc5e386b25c894cf626d8dd04b667ce33ae /c0
parentf491affe6415877a40422f4ebbb407451be161a6 (diff)
downloadpi-bitcoindev-158ad4e08e5847dffa25c99322113730bfddda17.tar.gz
pi-bitcoindev-158ad4e08e5847dffa25c99322113730bfddda17.zip
Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Diffstat (limited to 'c0')
-rw-r--r--c0/0f8c3254c004d02660ce8411a747e3559e53df746
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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
+tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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>
+&gt; On the ##taproot-activation IRC channel, Russell O&#39;Connor recently=
+<br>
+&gt; proposed a modification of the &quot;Let&#39;s see what happens&quot; =
+activation<br>
+&gt; proposal.[1] The idea received significant discussion and seemed<br>
+&gt; acceptable to several people who could not previously agree on a<br>
+&gt; proposal (although this doesn&#39;t necessarily make it their first<br=
+>
+&gt; choice).=C2=A0 The following is my attempt at a description.<br>
+&gt;<br>
+&gt; 1. Start soon: shortly after the release of software containing this<b=
+r>
+&gt;=C2=A0 =C2=A0 =C2=A0proposed activation logic, nodes will begin countin=
+g blocks towards<br>
+&gt;=C2=A0 =C2=A0 =C2=A0the 90% threshold required to lock in taproot.[2]<b=
+r>
+&gt;<br>
+&gt; 2. Stop soon: if the lockin threshold isn&#39;t reached within approxi=
+mately<br>
+&gt;=C2=A0 =C2=A0 =C2=A0three months, the activation attempt fails.=C2=A0 T=
+here is no mandatory<br>
+&gt;=C2=A0 =C2=A0 =C2=A0activation and everyone is encouraged to try again =
+using different<br>
+&gt;=C2=A0 =C2=A0 =C2=A0activation parameters.<br>
+&gt;<br>
+&gt; 2. Delayed activation: in the happy occasion where the lockin threshol=
+d<br>
+&gt;=C2=A0 =C2=A0 =C2=A0is reached, taproot is guaranteed to eventually act=
+ivate---but not<br>
+&gt;=C2=A0 =C2=A0 =C2=A0until approximately six months after signal trackin=
+g started.<br>
+&gt;<br>
+&gt; ## Example timeline<br>
+&gt;<br>
+&gt; (All dates approximate; see the section below about BIP9 vs BIP8.)<br>
+&gt;<br>
+&gt; - T+0: release of one or more full nodes with activation code<br>
+&gt; - T+14: signal tracking begins<br>
+&gt; - T+28: earliest possible lock in<br>
+&gt; - T+104: locked in by this date or need to try a different activation =
+process<br>
+&gt; - T+194: activation (if lockin occurred)<br>
+&gt;<br>
+&gt; ## Analysis<br>
+&gt;<br>
+&gt; The goal of Speedy Trial is to allow a taproot activation attempt to<b=
+r>
+&gt; either quickly succeed or quickly fail---without compromising safety i=
+n<br>
+&gt; either case.=C2=A0 Details below:<br>
+&gt;<br>
+&gt; ### Mitigating the problems of early success<br>
+&gt;<br>
+&gt; New rules added in a soft fork need to be enforced by a large part of<=
+br>
+&gt; the economy or there&#39;s a risk that a long chain of blocks breaking=
+ the<br>
+&gt; rules will be accepted by some users and rejected by others, causing a=
+<br>
+&gt; chain split that can result in large direct losses to transaction<br>
+&gt; receivers and potentially even larger indirect losses to holders due t=
+o<br>
+&gt; reduced confidence in the safety of the Bitcoin system.<br>
+&gt;<br>
+&gt; One step developers have taken in the past to ensure widespread adopti=
+on<br>
+&gt; of new consensus rules is programming in a delay between the time soft=
+ware<br>
+&gt; with those rules is expected to be released and when the software star=
+ts<br>
+&gt; tracking which blocks signal for activation.=C2=A0 For example:<br>
+&gt;<br>
+&gt;=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>
+&gt;=C2=A0 =C2=A0 =C2=A0 -----------------+------------+------------+------=
+----<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 BIP68 (v0.12.1)=C2=A0 | 2016-04-15 | 2016-05-11 | =
+26 days<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 da=
+ys<br>
+&gt;<br>
+&gt;=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>
+&gt;<br>
+&gt; Speedy Trial replaces most of that upfront delay with a backend delay.=
+<br>
+&gt; No matter how fast taproot&#39;s activation threshold is reached by mi=
+ners,<br>
+&gt; there will be six months between the time signal tracking starts and w=
+hen<br>
+&gt; nodes will begin enforcing taproot&#39;s rules.=C2=A0 This gives the u=
+serbase even<br>
+&gt; more time to upgrade than if we had used the most recently proposed st=
+art<br>
+&gt; date for a BIP8 activation (~July 23rd).[2]<br>
+&gt;<br>
+&gt; ### Succeed, or fail fast<br>
+&gt;<br>
+&gt; The earlier version of this proposal was documented over 200 days ago[=
+3]<br>
+&gt; and taproot&#39;s underlying code was merged into Bitcoin Core over 14=
+0 days<br>
+&gt; ago.[4]=C2=A0 If we had started Speedy Trial at the time taproot<br>
+&gt; was merged (which is a bit unrealistic), we would&#39;ve either be les=
+s than<br>
+&gt; two months away from having taproot or we would have moved on to the<b=
+r>
+&gt; next activation attempt over a month ago.<br>
+&gt;<br>
+&gt; Instead, we&#39;ve debated at length and don&#39;t appear to be any cl=
+oser to<br>
+&gt; what I think is a widely acceptable solution than when the mailing lis=
+t<br>
+&gt; began discussing post-segwit activation schemes over a year ago.[5]=C2=
+=A0 I<br>
+&gt; think Speedy Trial is a way to generate fast progress that will either=
+<br>
+&gt; end the debate (for now, if activation is successful) or give us some<=
+br>
+&gt; actual data upon which to base future taproot activation proposals.<br=
+>
+&gt;<br>
+&gt; Of course, for those who enjoy the debate, discussion can continue whi=
+le<br>
+&gt; waiting for the results of Speedy Trial.<br>
+&gt;<br>
+&gt; ### Base activation protocol<br>
+&gt;<br>
+&gt; The idea can be implemented on top of either Bitcoin Core&#39;s existi=
+ng<br>
+&gt; BIP9 code or its proposed BIP8 patchset.[6]<br>
+&gt;<br>
+&gt; - BIP9 uses two time-based[7] parameters, starttime and timeout.=C2=A0=
+ Using<br>
+&gt;=C2=A0 =C2=A0 these values plus a time-based parameter for the minimum =
+activation<br>
+&gt;=C2=A0 =C2=A0 delay would give three months for miners to activate tapr=
+oot, but some<br>
+&gt;=C2=A0 =C2=A0 of that time near the start or the end might not be usabl=
+e due to<br>
+&gt;=C2=A0 =C2=A0 signals only being measured in full retarget periods.=C2=
+=A0 However, the<br>
+&gt;=C2=A0 =C2=A0 six month time for users to upgrade their node would be n=
+ot be<br>
+&gt;=C2=A0 =C2=A0 affected by either slow or fast block production.<br>
+&gt;<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 BIP9 is already part of Bitcoin Core and I think t=
+he changes being<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 proposed would be relatively small, resulting in a=
+ small patch that<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 could be easy to review.<br>
+&gt;<br>
+&gt; - BIP8 uses two height-based parameters, startheight and timeoutheight=
+.<br>
+&gt;=C2=A0 =C2=A0 Using height values would ensure miners had a certain num=
+ber of<br>
+&gt;=C2=A0 =C2=A0 retarget periods (6) to lock in taproot and that there&#3=
+9;d be a certain<br>
+&gt;=C2=A0 =C2=A0 number of blocks (about 24,000) until activation, althoug=
+h latest lock<br>
+&gt;=C2=A0 =C2=A0 in and expected activation could occur moderately earlier=
+ or later<br>
+&gt;=C2=A0 =C2=A0 than the estimated three and six months.<br>
+&gt;<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 BIP8 would likely be used if Speedy Trial fails, s=
+o it could be<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 advantageous to base this proposal on BIP8 so that=
+ we gain<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 experience running that code in production.<br>
+&gt;<br>
+&gt; For additional discussion about using times versus heights, see today&=
+#39;s<br>
+&gt; log for ##taproot-activation.[11]<br>
+&gt;<br>
+&gt; ### Additional concerns<br>
+&gt;<br>
+&gt; - Encourages false signaling: false signaling is when miners signal<br=
+>
+&gt;=C2=A0 =C2=A0 readiness to enforce rules that their nodes don&#39;t act=
+ually support.<br>
+&gt;=C2=A0 =C2=A0 This was partially responsible for a six-block reorg shor=
+tly after the<br>
+&gt;=C2=A0 =C2=A0 final BIP66 activation[8] and was found to still be a pro=
+blem during<br>
+&gt;=C2=A0 =C2=A0 the BIP68 lockin period despite BIP9 being designed to av=
+oid it.[9]<br>
+&gt;<br>
+&gt;=C2=A0 =C2=A0 Because Speedy Trial only gives miners a maximum of three=
+ months to<br>
+&gt;=C2=A0 =C2=A0 signal support for taproot, it may encourage such false s=
+ignaling.=C2=A0 If<br>
+&gt;=C2=A0 =C2=A0 taproot locks in as a result of their signaling but most =
+of them fail<br>
+&gt;=C2=A0 =C2=A0 to upgrade by the activation date several months later, u=
+nprepared<br>
+&gt;=C2=A0 =C2=A0 miners could lose large amounts of money and users could =
+see long<br>
+&gt;=C2=A0 =C2=A0 reorgs (with unupgraded nodes and SPV lite clients potent=
+ially losing<br>
+&gt;=C2=A0 =C2=A0 money).<br>
+&gt;<br>
+&gt;=C2=A0 =C2=A0 Compared to other activation proposals, I think the only =
+difference is<br>
+&gt;=C2=A0 =C2=A0 Speedy Trial&#39;s short timeline.=C2=A0 False signaling =
+is possible with any<br>
+&gt;=C2=A0 =C2=A0 other proposal and the same problems can occur if miners =
+fail to<br>
+&gt;=C2=A0 =C2=A0 upgrade for any mandatory activation.<br>
+&gt;<br>
+&gt; ### Additional advantages<br>
+&gt;<br>
+&gt; - No mandatory signaling: at no time are miners required to signal by<=
+br>
+&gt;=C2=A0 =C2=A0 Speedy Trial.=C2=A0 This includes no mandatory signaling =
+during the<br>
+&gt;=C2=A0 =C2=A0 locked_in period(s), although such signaling will be enco=
+uraged (as it<br>
+&gt;=C2=A0 =C2=A0 was with BIP9[10]).<br>
+&gt;<br>
+&gt; - Party time: to a lesser degree, a benefit mentioned for flag day<br>
+&gt;=C2=A0 =C2=A0 activation may also apply here: we could get up to six mo=
+nths<br>
+&gt;=C2=A0 =C2=A0 advanced notice of taproot activation, allowing users, de=
+velopers, and<br>
+&gt;=C2=A0 =C2=A0 organizations to prepare software, announcements, and cel=
+ebrations for<br>
+&gt;=C2=A0 =C2=A0 that event.<br>
+&gt;<br>
+&gt; ## Implementation details and next steps<br>
+&gt;<br>
+&gt; Initial discussion about implementation may be found in today&#39;s<br=
+>
+&gt; ##taproot-activation log.[11] If it appears Speedy Trial may have<br>
+&gt; traction, Russell O&#39;Connor has offered to work on a patch against =
+BIP8<br>
+&gt; implementing it.<br>
+&gt;<br>
+&gt; ## Acknowledgments<br>
+&gt;<br>
+&gt; The original idea for a short-duration attempt was discussed in the<br=
+>
+&gt; ##taproot-activation IRC channel last July and the revised idea saw<br=
+>
+&gt; additional evaluation there this week.=C2=A0 Despite growing frustrati=
+on,<br>
+&gt; discussion has been overwhelmingly constructive, for which all the<br>
+&gt; contributors should be commended.=C2=A0 Although this should not in an=
+y way<br>
+&gt; imply endorsement, I&#39;m grateful for the review and comments on a d=
+raft<br>
+&gt; of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belche=
+r,<br>
+&gt; Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell<br>
+&gt; O&#39;Connor, and IRC users maybehuman and proofofkeags<br>
+&gt;<br>
+&gt; ## Footnotes<br>
+&gt;<br>
+&gt; [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>
+&gt;<br>
+&gt; [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget perio=
+d<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 seemed to have near-universal support during the 2=
+021-02-16 IRC<br>
+&gt;=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>
+&gt;<br>
+&gt; [3] <a href=3D"https://en.bitcoin.it/w/index.php?title=3DTaproot_activ=
+ation_proposals&amp;oldid=3D68062" rel=3D"noreferrer" target=3D"_blank">htt=
+ps://en.bitcoin.it/w/index.php?title=3DTaproot_activation_proposals&amp;old=
+id=3D68062</a><br>
+&gt;<br>
+&gt; [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>
+&gt;<br>
+&gt; [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>
+&gt;<br>
+&gt; [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>
+&gt;<br>
+&gt; [7] BIP9&#39;s times are based on the median of the past 11 blocks, wh=
+ich<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 usually trails UTC by about 90 minutes but which c=
+an trail behind<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 realtime significantly if miners are doing weird t=
+hings.<br>
+&gt;<br>
+&gt; [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>
+&gt;<br>
+&gt; [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>
+&gt;<br>
+&gt; [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>
+&gt;<br>
+&gt; [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>
+&gt; _______________________________________________<br>
+&gt; bitcoin-dev mailing list<br>
+&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
+ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
+&gt; <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--
+