Date: Fri, 5 Mar 2021 17:43:43 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="gzjoh3sgenxla3vn"
Content-Disposition: inline
User-Agent: NeoMutt/20180716
Subject: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Precedence: list


--gzjoh3sgenxla3vn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
  =20
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 proce=
ss
- 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=20
    -----------------+------------+------------+----------
    BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days=20
    BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days

    Sources: BitcoinCore.org, https://gist.github.com/ajtowns/1c5e3b8bdead0=
1124c04c45f01c817bc

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]=20

### 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.
 =20
    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.
 =20
    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_s=
ee_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_2=
02102

[3] https://en.bitcoin.it/w/index.php?title=3DTaproot_activation_proposals&=
oldid=3D68062

[4] https://github.com/bitcoin/bitcoin/pull/19953

[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/01=
7547.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/ed25cb58f605ba583c735f330482df=
0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339

[11] http://gnusha.org/taproot-activation/2021-03-05.log

--gzjoh3sgenxla3vn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmBC+m8ACgkQ2dtBqWwi
adPAsQ/+PAedzXb/D4NPC/J3nj7AVYjDV4DG6Zy0qb/vnpdWH4oFMKZoW9IIvpja
lB/zz/XliF3mv91WmymmLm4FICLCYCfzwy9aymwmU57BxeuuGSILRi2GdxvMbCqX
NtAf/gcmQq+SPu3K6nu2kHCdflvTC70TDlSN/sUyOpZNVUchbIqbehJ7vSYD0vnJ
ZLTZDNnuWLt37L0OYS0hTprmY4NRszVUou8NFWvFqh3YBf+SNUrES3QHW4aFvwWh
Cq4vOvdfy4Z5EhjuTEM9isuaMKQXDN2mLmWcPIDHBUi0I4PNRg9/N358lV7/7b/s
x220P7ohe6VPuxg0wdgntfTnDgduqfGbL3Fy5zveFh/BAq+1io2dUeWbCMBQDFav
YzgLko/Y/xy3W6+nOJi1cpEfTyrTDCVuI+MxwJCuk0V7amYWSGd0TVrW0f+sRqKJ
49uDLXzfpSxy534kJD/xEK9D7NrkS55d4l/0jkPU+ghRs47N1l/TNFdjkDnCqZUA
kLs4I+Tuq3ZkDLaZspjpiCzwO0WJ/gGyhxQJLEYSh/Mg4x6EqI3PTg4P/8p6SGPL
FjmfrAhWeFfU7vxTeFFiQI8r0mSAdG4QRJJSi2u+BTcmG5ZAI+y5yiywTNOeXLyt
Oae3uhoHQgPngzvRrcVdg66PhYkafkPieCZodyjrDQfDBLg3c4E=
=+Fzi
-----END PGP SIGNATURE-----

--gzjoh3sgenxla3vn--