From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 17C61C0001 for ; Sat, 6 Mar 2021 20:55:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 05D5246637 for ; Sat, 6 Mar 2021 20:55:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUx4kxKBDMjM for ; Sat, 6 Mar 2021 20:55:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by smtp4.osuosl.org (Postfix) with ESMTPS id 0279C465AC for ; Sat, 6 Mar 2021 20:55:50 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id v15so6797027wrx.4 for ; Sat, 06 Mar 2021 12:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V/wKKTDzvvKLCCE1/q1G7ixpAKvxVmOoUBzn57c4eQ0=; b=qYwgj3O4rguLwNPPCs07ciL24a9cnq7f7ZzERwuqcV1v30mccpOrc+rzZkHFlL/Td0 lRuo42BNpgu9WV1P9Bymsm+qzLdRhqMcHizPacSTKoZwGcfJiqI4uk0lLYGQcnTr6Fwm dOeZdfNEZprD7+Y3isl6ar4pxqtqpqgeXCu5nbQl5/eg8sDf15+Ge9XQ9B4ioPmpNbUM U4Xv+NJUNpE3P0px3h2EjrdYKGxg0ne8YXuwmDgvjPl+eggXam4r5WkAGQjRDmCbf32c mlhMICcaxMjRZQPyyUAaYeku2QcybBgKxR5g+Xwh225l9a1fqtTYwiQS4sINJ51moz8Z VlTQ== 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:cc; bh=V/wKKTDzvvKLCCE1/q1G7ixpAKvxVmOoUBzn57c4eQ0=; b=td4q3aFWL7ShDNfWziWMfYMMj4Me8P5wdbv2qt0NJa+b+m1gyAbEmpdOOITYTcSGUW szyCmySSX+MT1CA73YmQKhvgco8f28fvOqt7OujJ9OdmZNLogIzm/TqqUAoEvz0XHy3f CYPXiHb/fzQeaX1VHf5Ia6XWAA7EXm8Liskp6F2uOWC4yEFAR6ZC8oVmLWDvxfQ039/a ufDTNmcQuHnUK5hrnCvsfnrLeU2KwrmANtvcOHJGYmjS3M1zSdRbwdY93XNrF246OQBn UG8x71CfwdFoJkG12AupEOrWIJz3nz/q5kdPxGr22D7TuMh0mmwJAr1t+zVrkzYSDrLV khxg== X-Gm-Message-State: AOAM5304HLFSw9o9KDFUVzADRgRdgPgAinSW1xAHUYTsR3ft19LHAEBi NBf9ePxm9rkXMXdkxPv0gOpDuYeoCV80ihOpeNE= X-Google-Smtp-Source: ABdhPJzcnZJv3mwJwLThCkHJWuvLyac5Koiq90By5GU83LIiVKn0qVC6Cia+CqmIqCXbKZaZK3oLmpJEXplVEnjDMAU= X-Received: by 2002:adf:d84d:: with SMTP id k13mr15991989wrl.164.1615064149112; Sat, 06 Mar 2021 12:55:49 -0800 (PST) MIME-Version: 1.0 References: <20210306034343.fhwrxmq6gbb2os5m@ganymede> <2a6955d6-d242-89f5-d622-82889d499cc0@mattcorallo.com> In-Reply-To: From: Keagan McClelland Date: Sat, 6 Mar 2021 13:55:37 -0700 Message-ID: To: Ariel Luaces , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e5be4305bce46c33" X-Mailman-Approved-At: Sat, 06 Mar 2021 23:09:47 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2021 20:55:54 -0000 --000000000000e5be4305bce46c33 Content-Type: text/plain; charset="UTF-8" The assumption of malice on the part of those of us supporting a UASF is tragic and frankly ridiculous. Many of us backed off of the effort the second that this Speedy Trial solution was proposed in order to dislodge the gridlock on the LOT value. I can't say for certain that 100% of those working towards a UASF will abandon the effort but I can say for certain that a good portion of the would be contributors to Bitcoin Activation have already said that they would switch over to this Speedy Trial if it actually materialized. Given that the opposition towards the UASF to begin with was to not assume malice out of miners I would expect that the same good will be extended to those who were supporting a LOT=true client in good faith *given that Core already said they wouldn't ship any activation code at all.* Keagan On Sat, Mar 6, 2021 at 1:49 PM Ariel Luaces via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoin-dev > wrote: > > > > I'm really unsure that three months is a short enough time window that > there wouldn't be a material effort to split the > > network with divergent consensus rules. Instead, a three month window is > certainly long enough to organize and make a > > lot of noise around such an effort, given BIP 148 was organized and > reached its peak within a similar such window. > > > > Worse, because the obvious alternative after a three month activation > failure is a significant delay prior to > > activation, the vocal UASF minority may be encouraged to pursue such a > route to avoid such a delay. > > > > I agree with your concern, a three month window motivates a small > group to constantly tell people to upgrade as soon as possible. Which > is mostly fine, but if this group gets near 51% mining support in the > three months it will embolden them to switch the messaging from > "upgrade the client" to "run this new client that has the LOT flag > switched to true" (UASF) > This marketing group will attempt a UASF regardless of the timelines > because there is no cost if they fail a UASF and there is great reward > if they succeed by activating in 3 months. They can run an alt-node, > scare everyone else of being reorged, pretend they have a majority, > and say their chain is the safe one. I say there is no cost because > the leaders of that movement are likely savvy enough to give up the > effort and move back to running core even after the chain split. The > ones who get hurt are the followers of the UASF movement that don't > fully understand the discussion and drink the kool aid. > A short time window doesn't preclude this group from attempting a UASF. > > > One alternative may be to reduce the signaling windows involved and > start slightly later. Instead of the likelihood of > > failure growing on the horizon, simply have two signaling windows (maybe > two weeks, maybe a moth each?). In order to > > ensure success remains likely, begin them somewhat later after software > release to give pools and miners a chance to > > configure their mining software in advance. > > > > Matt > > The shorter the signaling windows the more unlikely they are to reach > a mining power supermajority. > With a short signaling window the supermajority threshold will > probably be configured to low levels (80% 70% 60%). Which makes the > activation period dangerous because it forces the other miners (20% > 30% 40%) to upgrade really suddenly once the threshold is reached. > Unless the LOCKED_IN period is made really long (1 year) but then we > have to wait a really long time. > As long as the mining power running the soft fork is above 50% the > chain will stay together. Anything above that is just a safety margin > to prevent orphan blocks. > > So why not encode this 50%+ dynamic into the activation logic. > Spread the deployment window out to a year, make the activation > threshold 95%, and at the end of the window the feature can activate > if there is above 51% signaling. > By definition, the activation will happen if either 95% is reached > early or if at the end of the deployment window mining support is > between 51% and 95%. With this setup the chain is guaranteed to stay > together and no need to rush miners and users. > > Cheers > Ariel Lorenzo-Luaces > > > > > On 3/5/21 22:43, 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000e5be4305bce46c33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The assumption of malice on the part of those of us suppor= ting a UASF is tragic and frankly ridiculous. Many of us backed off of the = effort the second that this Speedy Trial solution was proposed in order to = dislodge the gridlock on the LOT value. I can't say for certain that 10= 0% of those working towards a UASF will abandon the effort but I can say fo= r certain that a good portion of the would be contributors to Bitcoin Activ= ation have already said that they would switch over to this Speedy Trial if= it actually materialized.

Given that the opposition tow= ards the UASF to begin with was to not assume malice out of miners I would = expect that the same good will be extended to those who were supporting a L= OT=3Dtrue client in good faith given that Core already said they wouldn&= #39;t ship any activation code at all.

= Keagan

On Sat, Mar 6, 2021 at 1:49 PM Ariel Luaces via bitcoin-dev <= ;bitcoin-dev@lists= .linuxfoundation.org> wrote:
On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoi= n-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm really unsure that three months is a short enough time window = that there wouldn't be a material effort to split the
> network with divergent consensus rules. Instead, a three month window = is certainly long enough to organize and make a
> lot of noise around such an effort, given BIP 148 was organized and re= ached its peak within a similar such window.
>
> Worse, because the obvious alternative after a three month activation = failure is a significant delay prior to
> activation, the vocal UASF minority may be encouraged to pursue such a= route to avoid such a delay.
>

I agree with your concern, a three month window motivates a small
group to constantly tell people to upgrade as soon as possible. Which
is mostly fine, but if this group gets near 51% mining support in the
three months it will embolden them to switch the messaging from
"upgrade the client" to "run this new client that has the LO= T flag
switched to true" (UASF)
This marketing group will attempt a UASF regardless of the timelines
because there is no cost if they fail a UASF and there is great reward
if they succeed by activating in 3 months. They can run an alt-node,
scare everyone else of being reorged, pretend they have a majority,
and say their chain is the safe one. I say there is no cost because
the leaders of that movement are likely savvy enough to give up the
effort and move back to running core even after the chain split. The
ones who get hurt are the followers of the UASF movement that don't
fully understand the discussion and drink the kool aid.
A short time window doesn't preclude this group from attempting a UASF.=

> One alternative may be to reduce the signaling windows involved and st= art slightly later. Instead of the likelihood of
> failure growing on the horizon, simply have two signaling windows (may= be two weeks, maybe a moth each?). In order to
> ensure success remains likely, begin them somewhat later after softwar= e release to give pools and miners a chance to
> configure their mining software in advance.
>
> Matt

The shorter the signaling windows the more unlikely they are to reach
a mining power supermajority.
With a short signaling window the supermajority threshold will
probably be configured to low levels (80% 70% 60%). Which makes the
activation period dangerous because it forces the other miners (20%
30% 40%) to upgrade really suddenly once the threshold is reached.
Unless the LOCKED_IN period is made really long (1 year) but then we
have to wait a really long time.
As long as the mining power running the soft fork is above 50% the
chain will stay together. Anything above that is just a safety margin
to prevent orphan blocks.

So why not encode this 50%+ dynamic into the activation logic.
Spread the deployment window out to a year, make the activation
threshold 95%, and at the end of the window the feature can activate
if there is above 51% signaling.
By definition, the activation will happen if either 95% is reached
early or if at the end of the deployment window mining support is
between 51% and 95%. With this setup the chain is guaranteed to stay
together and no need to rush miners and users.

Cheers
Ariel Lorenzo-Luaces

>
> On 3/5/21 22:43, David A. Harding via bitcoin-dev wrote:
> > On the ##taproot-activation IRC channel, Russell O'Connor rec= ently
> > proposed a modification of the "Let's see what happens&q= uot; activation
> > proposal.[1] The idea received significant discussion and seemed<= br> > > acceptable to several people who could not previously agree on a<= br> > > proposal (although this doesn't necessarily make it their fir= st
> > choice).=C2=A0 The following is my attempt at a description.
> >
> > 1. Start soon: shortly after the release of software containing t= his
> >=C2=A0 =C2=A0 =C2=A0proposed activation logic, nodes will begin co= unting blocks towards
> >=C2=A0 =C2=A0 =C2=A0the 90% threshold required to lock in taproot.= [2]
> >
> > 2. Stop soon: if the lockin threshold isn't reached within ap= proximately
> >=C2=A0 =C2=A0 =C2=A0three months, the activation attempt fails.=C2= =A0 There is no mandatory
> >=C2=A0 =C2=A0 =C2=A0activation and everyone is encouraged to try a= gain using different
> >=C2=A0 =C2=A0 =C2=A0activation parameters.
> >
> > 2. Delayed activation: in the happy occasion where the lockin thr= eshold
> >=C2=A0 =C2=A0 =C2=A0is reached, taproot is guaranteed to eventuall= y activate---but not
> >=C2=A0 =C2=A0 =C2=A0until approximately six months after signal tr= acking 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 activa= tion 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 saf= ety in
> > either case.=C2=A0 Details below:
> >
> > ### Mitigating the problems of early success
> >
> > New rules added in a soft fork need to be enforced by a large par= t of
> > the economy or there's a risk that a long chain of blocks bre= aking the
> > rules will be accepted by some users and rejected by others, caus= ing 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 a= doption
> > 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.=C2=A0 For example: > >
> >=C2=A0 =C2=A0 =C2=A0 Soft fork=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Releas= e=C2=A0 =C2=A0 | Start=C2=A0 =C2=A0 =C2=A0 | Delta
> >=C2=A0 =C2=A0 =C2=A0 -----------------+------------+------------+-= ---------
> >=C2=A0 =C2=A0 =C2=A0 BIP68 (v0.12.1)=C2=A0 | 2016-04-15 | 2016-05-= 11 | 26 days
> >=C2=A0 =C2=A0 =C2=A0 BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | = 24 days
> >
> >=C2=A0 =C2=A0 =C2=A0 Sources: BitcoinCore.org, https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45= f01c817bc
> >
> > Speedy Trial replaces most of that upfront delay with a backend d= elay.
> > 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.=C2=A0 This gives = the userbase even
> > more time to upgrade than if we had used the most recently propos= ed 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 ov= er 140 days
> > ago.[4]=C2=A0 If we had started Speedy Trial at the time taproot<= br> > > was merged (which is a bit unrealistic), we would've either b= e 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 a= ny closer to
> > what I think is a widely acceptable solution than when the mailin= g list
> > began discussing post-segwit activation schemes over a year ago.[= 5]=C2=A0 I
> > think Speedy Trial is a way to generate fast progress that will e= ither
> > end the debate (for now, if activation is successful) or give us = some
> > actual data upon which to base future taproot activation proposal= s.
> >
> > Of course, for those who enjoy the debate, discussion can continu= e while
> > waiting for the results of Speedy Trial.
> >
> > ### Base activation protocol
> >
> > The idea can be implemented on top of either Bitcoin Core's e= xisting
> > BIP9 code or its proposed BIP8 patchset.[6]
> >
> > - BIP9 uses two time-based[7] parameters, starttime and timeout.= =C2=A0 Using
> >=C2=A0 =C2=A0 these values plus a time-based parameter for the min= imum activation
> >=C2=A0 =C2=A0 delay would give three months for miners to activate= taproot, but some
> >=C2=A0 =C2=A0 of that time near the start or the end might not be = usable due to
> >=C2=A0 =C2=A0 signals only being measured in full retarget periods= .=C2=A0 However, the
> >=C2=A0 =C2=A0 six month time for users to upgrade their node would= be not be
> >=C2=A0 =C2=A0 affected by either slow or fast block production. > >
> >=C2=A0 =C2=A0 =C2=A0 BIP9 is already part of Bitcoin Core and I th= ink the changes being
> >=C2=A0 =C2=A0 =C2=A0 proposed would be relatively small, resulting= in a small patch that
> >=C2=A0 =C2=A0 =C2=A0 could be easy to review.
> >
> > - BIP8 uses two height-based parameters, startheight and timeouth= eight.
> >=C2=A0 =C2=A0 Using height values would ensure miners had a certai= n number of
> >=C2=A0 =C2=A0 retarget periods (6) to lock in taproot and that the= re'd be a certain
> >=C2=A0 =C2=A0 number of blocks (about 24,000) until activation, al= though latest lock
> >=C2=A0 =C2=A0 in and expected activation could occur moderately ea= rlier or later
> >=C2=A0 =C2=A0 than the estimated three and six months.
> >
> >=C2=A0 =C2=A0 =C2=A0 BIP8 would likely be used if Speedy Trial fai= ls, so it could be
> >=C2=A0 =C2=A0 =C2=A0 advantageous to base this proposal on BIP8 so= that we gain
> >=C2=A0 =C2=A0 =C2=A0 experience running that code in production. > >
> > For additional discussion about using times versus heights, see t= oday's
> > log for ##taproot-activation.[11]
> >
> > ### Additional concerns
> >
> > - Encourages false signaling: false signaling is when miners sign= al
> >=C2=A0 =C2=A0 readiness to enforce rules that their nodes don'= t actually support.
> >=C2=A0 =C2=A0 This was partially responsible for a six-block reorg= shortly after the
> >=C2=A0 =C2=A0 final BIP66 activation[8] and was found to still be = a problem during
> >=C2=A0 =C2=A0 the BIP68 lockin period despite BIP9 being designed = to avoid it.[9]
> >
> >=C2=A0 =C2=A0 Because Speedy Trial only gives miners a maximum of = three months to
> >=C2=A0 =C2=A0 signal support for taproot, it may encourage such fa= lse signaling.=C2=A0 If
> >=C2=A0 =C2=A0 taproot locks in as a result of their signaling but = most of them fail
> >=C2=A0 =C2=A0 to upgrade by the activation date several months lat= er, unprepared
> >=C2=A0 =C2=A0 miners could lose large amounts of money and users c= ould see long
> >=C2=A0 =C2=A0 reorgs (with unupgraded nodes and SPV lite clients p= otentially losing
> >=C2=A0 =C2=A0 money).
> >
> >=C2=A0 =C2=A0 Compared to other activation proposals, I think the = only difference is
> >=C2=A0 =C2=A0 Speedy Trial's short timeline.=C2=A0 False signa= ling is possible with any
> >=C2=A0 =C2=A0 other proposal and the same problems can occur if mi= ners fail to
> >=C2=A0 =C2=A0 upgrade for any mandatory activation.
> >
> > ### Additional advantages
> >
> > - No mandatory signaling: at no time are miners required to signa= l by
> >=C2=A0 =C2=A0 Speedy Trial.=C2=A0 This includes no mandatory signa= ling during the
> >=C2=A0 =C2=A0 locked_in period(s), although such signaling will be= encouraged (as it
> >=C2=A0 =C2=A0 was with BIP9[10]).
> >
> > - Party time: to a lesser degree, a benefit mentioned for flag da= y
> >=C2=A0 =C2=A0 activation may also apply here: we could get up to s= ix months
> >=C2=A0 =C2=A0 advanced notice of taproot activation, allowing user= s, developers, and
> >=C2=A0 =C2=A0 organizations to prepare software, announcements, an= d celebrations for
> >=C2=A0 =C2=A0 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 aga= inst BIP8
> > implementing it.
> >
> > ## Acknowledgments
> >
> > The original idea for a short-duration attempt was discussed in t= he
> > ##taproot-activation IRC channel last July and the revised idea s= aw
> > additional evaluation there this week.=C2=A0 Despite growing frus= tration,
> > discussion has been overwhelmingly constructive, for which all th= e
> > contributors should be commended.=C2=A0 Although this should not = in any way
> > imply endorsement, I'm grateful for the review and comments o= n a draft
> > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris B= elcher,
> > 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_prop= osals#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
> >=C2=A0 =C2=A0 =C2=A0 seemed to have near-universal support during = the 2021-02-16 IRC
> >=C2=A0 =C2=A0 =C2=A0 meeting.=C2=A0 See: https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> >
> > [3] https://en.bitcoin.it/w/index.php?title=3DTaproot_activation_proposals&am= p;oldid=3D68062
> >
> > [4] https://github.com/bitcoin/bitcoin/pull/1= 9953
> >
> > [5] https:= //lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html<= /a>
> >
> > [6] https://github.com/bitcoin/bitcoin/pull/1= 9573
> >
> > [7] BIP9's times are based on the median of the past 11 block= s, which
> >=C2=A0 =C2=A0 =C2=A0 usually trails UTC by about 90 minutes but wh= ich can trail behind
> >=C2=A0 =C2=A0 =C2=A0 realtime significantly if miners are doing we= ird things.
> >
> > [8] https://en.bitcoin.it/wiki/July_2015_c= hain_forks
> >
> > [9] https://buildingb= itcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
> >
> > [10] https://github.com/bitcoin/bitcoin/blob= /ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L3= 37-L339
> >
> > [11] http://gnusha.org/taproot-activati= on/2021-03-05.log
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> 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/mail= man/listinfo/bitcoin-dev
--000000000000e5be4305bce46c33--