{"type":"rich","version":"1.0","author_name":"npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","author_url":"https://nostr.ae/npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-03-06\n📝 Original message:The most sensible approach I’ve seen yet.\n\ne\n\n\u003e On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev wrote:\n\u003e\u003e ## Example timeline\n\u003e\u003e - T+0: release of one or more full nodes with activation code\n\u003e\u003e - T+14: signal tracking begins\n\u003e\u003e - T+28: earliest possible lock in\n\u003e\u003e - T+104: locked in by this date or need to try a different activation process\n\u003e\u003e - T+194: activation (if lockin occurred)\n\u003e \n\u003e\u003e ### Base activation protocol\n\u003e\u003e The idea can be implemented on top of either Bitcoin Core's existing\n\u003e\u003e BIP9 code or its proposed BIP8 patchset.[6]\n\u003e\u003e    BIP9 is already part of Bitcoin Core and I think the changes being\n\u003e\u003e    proposed would be relatively small, resulting in a small patch that\n\u003e\u003e    could be easy to review.\n\u003e \n\u003e To get to specifics, here's a PR, based on #21334, that updates bip9\n\u003e to support an extra parameter to delay the transition from LOCKED_IN\n\u003e to ACTIVE until a particular timestamp is reached, and to reduce the\n\u003e activation threshold to 90%:\n\u003e \n\u003e  https://github.com/bitcoin/bitcoin/pull/21377\n\u003e \n\u003e With that in mind, I think the example timeline above could translate\n\u003e to taproot parameters of:\n\u003e \n\u003e  nStartTime = 1618358400; // April 14, 2021\n\u003e  nTimeout = 1626220800; // July 14 2021\n\u003e  activation_time = 1633046400; // October 1 2021\n\u003e \n\u003e That is, signalling begins with the first retarget period whose parent's\n\u003e median time is at least April 14th; and concludes with the last retarget\n\u003e period whose final block's median time is prior to July 14th; that's\n\u003e 91 days which should be about ~6.5 retarget periods, so should cover 6\n\u003e full retarget periods, but could only cover 5.  Activation is delayed\n\u003e until the first retarget period where the final block of the previous\n\u003e retarget period has a timestamp of at least October 1st.\n\u003e \n\u003e Note that the timeout there is prior to the expected timestamp of the\n\u003e startheight block specified in the proposal for bip8 parameters:\n\u003e \n\u003e  https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102\n\u003e \n\u003e and earliest activation is after the expected release of 22.0 and hence\n\u003e the maintenance end of 0.20.\n\u003e \n\u003e Note also that the PR above specifies the delay as a deadline, not a\n\u003e delta between lockin and activation; so earlier lockin does not produce\n\u003e an earlier activation with the code referenced above.\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}