Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5C06BC0001 for ; Sat, 6 Mar 2021 09:29:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 349FE414EE for ; Sat, 6 Mar 2021 09:29:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NcUSnrcqUut for ; Sat, 6 Mar 2021 09:29:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp2.osuosl.org (Postfix) with ESMTPS id 02338414E0 for ; Sat, 6 Mar 2021 09:29:39 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1lITFf-0008E0-Lf; Sat, 06 Mar 2021 19:29:37 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Sat, 06 Mar 2021 19:29:31 +1000 Date: Sat, 6 Mar 2021 19:29:31 +1000 From: Anthony Towns To: "David A. Harding" , Bitcoin Protocol Discussion 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) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial" X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2021 09:29:41 -0000 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