path: root/c0/0f8c3254c004d02660ce8411a747e3559e53df

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--