Date: Sat, 6 Mar 2021 19:29:31 +1000
From: Anthony Towns <aj@erisian.com.au>
To: "David A. Harding" <dave@dtrt.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210306092931.6jmw6o2u7a2gewwb@erisian.com.au>
References: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Precedence: list

On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev wrote:
> ## Example timeline
> - 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)

> ### 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 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.

To get to specifics, here's a PR, based on #21334, that updates bip9
to support an extra parameter to delay the transition from LOCKED_IN
to ACTIVE until a particular timestamp is reached, and to reduce the
activation threshold to 90%:

  https://github.com/bitcoin/bitcoin/pull/21377

With that in mind, I think the example timeline above could translate
to taproot parameters of:

  nStartTime = 1618358400; // April 14, 2021
  nTimeout = 1626220800; // July 14 2021
  activation_time = 1633046400; // October 1 2021

That is, signalling begins with the first retarget period whose parent's
median time is at least April 14th; and concludes with the last retarget
period whose final block's median time is prior to July 14th; that's
91 days which should be about ~6.5 retarget periods, so should cover 6
full retarget periods, but could only cover 5.  Activation is delayed
until the first retarget period where the final block of the previous
retarget period has a timestamp of at least October 1st.

Note that the timeout there is prior to the expected timestamp of the
startheight block specified in the proposal for bip8 parameters:

  https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102

and earliest activation is after the expected release of 22.0 and hence
the maintenance end of 0.20.

Note also that the PR above specifies the delay as a deadline, not a
delta between lockin and activation; so earlier lockin does not produce
an earlier activation with the code referenced above.

Cheers,
aj