path: root/a6/6ae3884885beb0ffc10e65e18f53b599370240

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C6CD3C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 04:44:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id ACC9060657
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 04:44:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0fkRMeQLgZ6f
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 04:44:47 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 6087A60605
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 04:44:47 +0000 (UTC)
Received: from mail-il1-f181.google.com (mail-il1-f181.google.com
 [209.85.166.181]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1264ijIv011080
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 5 Mar 2021 23:44:45 -0500
Received: by mail-il1-f181.google.com with SMTP id i18so3917693ilq.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 05 Mar 2021 20:44:45 -0800 (PST)
X-Gm-Message-State: AOAM533jEVSskv0giHZ5q9/Ir+yuV5k/QQeLMIu1fRPz2uJoTSz52lsc
 BWuIcKicZpQf/1PeFrPaItjAwVEbCtpbnPSD59U=
X-Google-Smtp-Source: ABdhPJzh44LHUa9018CgXZMtP85GAmuoiBqIE29le8VST4ZOJ9LDIedW3BaooL0E/6kaUYqmWQ0Eh0P+k+xLAB2EL9I=
X-Received: by 2002:a05:6e02:1ca4:: with SMTP id
 x4mr11393261ill.58.1615005884987; 
 Fri, 05 Mar 2021 20:44:44 -0800 (PST)
MIME-Version: 1.0
References: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
In-Reply-To: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 5 Mar 2021 20:44:33 -0800
X-Gmail-Original-Message-ID: <CAD5xwhjOFUPpXZ97CWSSpngEiAt7tmTikS+==-0AKbHPzEXieg@mail.gmail.com>
Message-ID: <CAD5xwhjOFUPpXZ97CWSSpngEiAt7tmTikS+==-0AKbHPzEXieg@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000015bff705bcd6dcee"
Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2021 04:44:49 -0000

--00000000000015bff705bcd6dcee
Content-Type: text/plain; charset="UTF-8"

Thank you for resurfacing and collating this concept.

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

Best,

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


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

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

--00000000000015bff705bcd6dcee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Thank you for resurfacing=
 and collating this concept.</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000">At this time I don&#39;t see major issue=
s with this course of action and think it represents not only a reasonable =
compromise between all different perspectives, but also gives us an opportu=
nity to learn more about less &#39;slow&#39; yet safe consensus upgrades. I=
n particular, I am very happy to see the earliest activation concept includ=
ed.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">Best,</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">Jeremy<br clear=3D"all"></div><div><div dir=3D"lt=
r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D=
"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@=
JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank=
"></a></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Mar 5, 2021 at 7:44 PM David A. Hardi=
ng via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">On the ##taproot-activation IRC c=
hannel, Russell O&#39;Connor recently<br>
proposed a modification of the &quot;Let&#39;s see what happens&quot; activ=
ation<br>
proposal.[1] The idea received significant discussion and seemed<br>
acceptable to several people who could not previously agree on a<br>
proposal (although this doesn&#39;t necessarily make it their first<br>
choice).=C2=A0 The following is my attempt at a description.<br>
<br>
1. Start soon: shortly after the release of software containing this<br>
=C2=A0 =C2=A0proposed activation logic, nodes will begin counting blocks to=
wards<br>
=C2=A0 =C2=A0the 90% threshold required to lock in taproot.[2]<br>
<br>
2. Stop soon: if the lockin threshold isn&#39;t reached within approximatel=
y<br>
=C2=A0 =C2=A0three months, the activation attempt fails.=C2=A0 There is no =
mandatory<br>
=C2=A0 =C2=A0activation and everyone is encouraged to try again using diffe=
rent<br>
=C2=A0 =C2=A0activation parameters.<br>
<br>
2. Delayed activation: in the happy occasion where the lockin threshold<br>
=C2=A0 =C2=A0is reached, taproot is guaranteed to eventually activate---but=
 not<br>
=C2=A0 =C2=A0until approximately six months after signal tracking started.<=
br>
<br>
## Example timeline<br>
<br>
(All dates approximate; see the section below about BIP9 vs BIP8.)<br>
<br>
- T+0: release of one or more full nodes with activation code<br>
- T+14: signal tracking begins<br>
- T+28: earliest possible lock in<br>
- T+104: locked in by this date or need to try a different activation proce=
ss<br>
- T+194: activation (if lockin occurred)<br>
<br>
## Analysis<br>
<br>
The goal of Speedy Trial is to allow a taproot activation attempt to<br>
either quickly succeed or quickly fail---without compromising safety in<br>
either case.=C2=A0 Details below:<br>
<br>
### Mitigating the problems of early success<br>
<br>
New rules added in a soft fork need to be enforced by a large part of<br>
the economy or there&#39;s a risk that a long chain of blocks breaking the<=
br>
rules will be accepted by some users and rejected by others, causing a<br>
chain split that can result in large direct losses to transaction<br>
receivers and potentially even larger indirect losses to holders due to<br>
reduced confidence in the safety of the Bitcoin system.<br>
<br>
One step developers have taken in the past to ensure widespread adoption<br=
>
of new consensus rules is programming in a delay between the time software<=
br>
with those rules is expected to be released and when the software starts<br=
>
tracking which blocks signal for activation.=C2=A0 For example:<br>
<br>
=C2=A0 =C2=A0 Soft fork=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Release=C2=A0 =C2=A0 |=
 Start=C2=A0 =C2=A0 =C2=A0 | Delta <br>
=C2=A0 =C2=A0 -----------------+------------+------------+----------<br>
=C2=A0 =C2=A0 BIP68 (v0.12.1)=C2=A0 | 2016-04-15 | 2016-05-11 | 26 days <br=
>
=C2=A0 =C2=A0 BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days<br>
<br>
=C2=A0 =C2=A0 Sources: BitcoinCore.org, <a href=3D"https://gist.github.com/=
ajtowns/1c5e3b8bdead01124c04c45f01c817bc" rel=3D"noreferrer" target=3D"_bla=
nk">https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc</a><br=
>
<br>
Speedy Trial replaces most of that upfront delay with a backend delay.<br>
No matter how fast taproot&#39;s activation threshold is reached by miners,=
<br>
there will be six months between the time signal tracking starts and when<b=
r>
nodes will begin enforcing taproot&#39;s rules.=C2=A0 This gives the userba=
se even<br>
more time to upgrade than if we had used the most recently proposed start<b=
r>
date for a BIP8 activation (~July 23rd).[2] <br>
<br>
### Succeed, or fail fast<br>
<br>
The earlier version of this proposal was documented over 200 days ago[3]<br=
>
and taproot&#39;s underlying code was merged into Bitcoin Core over 140 day=
s<br>
ago.[4]=C2=A0 If we had started Speedy Trial at the time taproot<br>
was merged (which is a bit unrealistic), we would&#39;ve either be less tha=
n<br>
two months away from having taproot or we would have moved on to the<br>
next activation attempt over a month ago.<br>
<br>
Instead, we&#39;ve debated at length and don&#39;t appear to be any closer =
to<br>
what I think is a widely acceptable solution than when the mailing list<br>
began discussing post-segwit activation schemes over a year ago.[5]=C2=A0 I=
<br>
think Speedy Trial is a way to generate fast progress that will either<br>
end the debate (for now, if activation is successful) or give us some<br>
actual data upon which to base future taproot activation proposals.<br>
<br>
Of course, for those who enjoy the debate, discussion can continue while<br=
>
waiting for the results of Speedy Trial.<br>
<br>
### Base activation protocol<br>
<br>
The idea can be implemented on top of either Bitcoin Core&#39;s existing<br=
>
BIP9 code or its proposed BIP8 patchset.[6]<br>
<br>
- BIP9 uses two time-based[7] parameters, starttime and timeout.=C2=A0 Usin=
g<br>
=C2=A0 these values plus a time-based parameter for the minimum activation<=
br>
=C2=A0 delay would give three months for miners to activate taproot, but so=
me<br>
=C2=A0 of that time near the start or the end might not be usable due to<br=
>
=C2=A0 signals only being measured in full retarget periods.=C2=A0 However,=
 the<br>
=C2=A0 six month time for users to upgrade their node would be not be<br>
=C2=A0 affected by either slow or fast block production.<br>
<br>
=C2=A0 =C2=A0 BIP9 is already part of Bitcoin Core and I think the changes =
being<br>
=C2=A0 =C2=A0 proposed would be relatively small, resulting in a small patc=
h that<br>
=C2=A0 =C2=A0 could be easy to review.<br>
<br>
- BIP8 uses two height-based parameters, startheight and timeoutheight.<br>
=C2=A0 Using height values would ensure miners had a certain number of<br>
=C2=A0 retarget periods (6) to lock in taproot and that there&#39;d be a ce=
rtain<br>
=C2=A0 number of blocks (about 24,000) until activation, although latest lo=
ck<br>
=C2=A0 in and expected activation could occur moderately earlier or later<b=
r>
=C2=A0 than the estimated three and six months.<br>
<br>
=C2=A0 =C2=A0 BIP8 would likely be used if Speedy Trial fails, so it could =
be<br>
=C2=A0 =C2=A0 advantageous to base this proposal on BIP8 so that we gain<br=
>
=C2=A0 =C2=A0 experience running that code in production.<br>
<br>
For additional discussion about using times versus heights, see today&#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 readiness to enforce rules that their nodes don&#39;t actually suppo=
rt.<br>
=C2=A0 This was partially responsible for a six-block reorg shortly after t=
he<br>
=C2=A0 final BIP66 activation[8] and was found to still be a problem during=
<br>
=C2=A0 the BIP68 lockin period despite BIP9 being designed to avoid it.[9]<=
br>
<br>
=C2=A0 Because Speedy Trial only gives miners a maximum of three months to<=
br>
=C2=A0 signal support for taproot, it may encourage such false signaling.=
=C2=A0 If<br>
=C2=A0 taproot locks in as a result of their signaling but most of them fai=
l<br>
=C2=A0 to upgrade by the activation date several months later, unprepared<b=
r>
=C2=A0 miners could lose large amounts of money and users could see long<br=
>
=C2=A0 reorgs (with unupgraded nodes and SPV lite clients potentially losin=
g<br>
=C2=A0 money).<br>
<br>
=C2=A0 Compared to other activation proposals, I think the only difference =
is<br>
=C2=A0 Speedy Trial&#39;s short timeline.=C2=A0 False signaling is possible=
 with any<br>
=C2=A0 other proposal and the same problems can occur if miners fail to<br>
=C2=A0 upgrade for any mandatory activation.<br>
<br>
### Additional advantages<br>
<br>
- No mandatory signaling: at no time are miners required to signal by<br>
=C2=A0 Speedy Trial.=C2=A0 This includes no mandatory signaling during the<=
br>
=C2=A0 locked_in period(s), although such signaling will be encouraged (as =
it<br>
=C2=A0 was with BIP9[10]).<br>
<br>
- Party time: to a lesser degree, a benefit mentioned for flag day<br>
=C2=A0 activation may also apply here: we could get up to six months<br>
=C2=A0 advanced notice of taproot activation, allowing users, developers, a=
nd<br>
=C2=A0 organizations to prepare software, announcements, and celebrations f=
or<br>
=C2=A0 that event.<br>
<br>
## Implementation details and next steps<br>
<br>
Initial discussion about implementation may be found in today&#39;s<br>
##taproot-activation log.[11] If it appears Speedy Trial may have<br>
traction, Russell O&#39;Connor has offered to work on a patch against BIP8<=
br>
implementing it.<br>
<br>
## Acknowledgments<br>
<br>
The original idea for a short-duration attempt was discussed in the<br>
##taproot-activation IRC channel last July and the revised idea saw<br>
additional evaluation there this week.=C2=A0 Despite growing frustration,<b=
r>
discussion has been overwhelmingly constructive, for which all the<br>
contributors should be commended.=C2=A0 Although this should not in any way=
<br>
imply endorsement, I&#39;m grateful for the review and comments on a draft<=
br>
of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,<br=
>
Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell<br>
O&#39;Connor, and IRC users maybehuman and proofofkeags<br>
<br>
## Footnotes<br>
<br>
[1] <a href=3D"https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.=
E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29" rel=3D"noreferrer" tar=
get=3D"_blank">https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.=
E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29</a><br>
<br>
[2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period<br>
=C2=A0 =C2=A0 seemed to have near-universal support during the 2021-02-16 I=
RC<br>
=C2=A0 =C2=A0 meeting.=C2=A0 See: <a href=3D"https://en.bitcoin.it/wiki/Tap=
root_activation_proposal_202102" rel=3D"noreferrer" target=3D"_blank">https=
://en.bitcoin.it/wiki/Taproot_activation_proposal_202102</a><br>
<br>
[3] <a href=3D"https://en.bitcoin.it/w/index.php?title=3DTaproot_activation=
_proposals&amp;oldid=3D68062" rel=3D"noreferrer" target=3D"_blank">https://=
en.bitcoin.it/w/index.php?title=3DTaproot_activation_proposals&amp;oldid=3D=
68062</a><br>
<br>
[4] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19953" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19953</a><b=
r>
<br>
[5] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020=
-January/017547.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html</a><br>
<br>
[6] <a href=3D"https://github.com/bitcoin/bitcoin/pull/19573" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/19573</a><b=
r>
<br>
[7] BIP9&#39;s times are based on the median of the past 11 blocks, which<b=
r>
=C2=A0 =C2=A0 usually trails UTC by about 90 minutes but which can trail be=
hind<br>
=C2=A0 =C2=A0 realtime significantly if miners are doing weird things.<br>
<br>
[8] <a href=3D"https://en.bitcoin.it/wiki/July_2015_chain_forks" rel=3D"nor=
eferrer" target=3D"_blank">https://en.bitcoin.it/wiki/July_2015_chain_forks=
</a><br>
<br>
[9] <a href=3D"https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.=
html#l-32" rel=3D"noreferrer" target=3D"_blank">https://buildingbitcoin.org=
/bitcoin-core-dev/log-2016-06-21.html#l-32</a><br>
<br>
[10] <a href=3D"https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c7=
35f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339" rel=3D"nore=
ferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/ed25cb58f=
605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339</a=
><br>
<br>
[11] <a href=3D"http://gnusha.org/taproot-activation/2021-03-05.log" rel=3D=
"noreferrer" target=3D"_blank">http://gnusha.org/taproot-activation/2021-03=
-05.log</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000015bff705bcd6dcee--