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