From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Andrew Chow <achow101-lists@achow101.com>
Date: Mon, 15 Mar 2021 02:51:46 +0000
User-Agent: KMail/1.9.10
References: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
 <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com>
In-Reply-To: <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202103150251.46902.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Precedence: list

The last period before timeoutheight here overlaps with the current BIP8(True) 
deployment plan. So if this period specifically were to reach 90% signalling, 
nodes would activate Taproot at height 697536, but ST-only nodes would still 
wait until 709632 instead.

Probably the best solution is to just move this ST window 1 period earlier?

Luke


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