Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-06 📝 Original message:The most sensible approach ...
📅 Original date posted:2021-03-06
📝 Original message:The most sensible approach I’ve seen yet.
e
> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:The most sensible approach I’ve seen yet.
e
> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev