The most sensible approach I’ve seen yet. e
> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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 > > _______________________________________________ > 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
