From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D0CE0C0001 for ; Wed, 3 Mar 2021 14:59:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id BF3584998D for ; Wed, 3 Mar 2021 14:59:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK3-cUVyHgfQ for ; Wed, 3 Mar 2021 14:59:12 +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 smtp4.osuosl.org (Postfix) with ESMTPS id EF0B949CE1 for ; Wed, 3 Mar 2021 14:59:11 +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 1lHSxv-0007mB-4d; Thu, 04 Mar 2021 00:59:09 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 04 Mar 2021 00:59:02 +1000 Date: Thu, 4 Mar 2021 00:59:02 +1000 From: Anthony Towns To: Matt Corallo , Bitcoin Protocol Discussion Message-ID: <20210303145902.cl4mzg6l7avjboil@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation 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: Wed, 03 Mar 2021 14:59:13 -0000 On Sun, Feb 28, 2021 at 11:45:22AM -0500, Matt Corallo via bitcoin-dev wrote: > Given this, it seems one way to keep the network in consensus would be to > simply activate taproot through a traditional, no-frills, flag-day (or > -height) activation with a flag day of roughly August, 2022. Going back to > my criteria laid out in [1], The timeout height proposed in: https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102 is block 745920, so bip8/lockinontimeout=true with that param would ensure activation by block 747936. That's 74,940 blocks away at present, which would be ~6th August 2022 if the block interval averaged at 10 minutes. So I think I'm going to treat this as reusing the same parameter, just dropping the consensus-critical signalling and hence the possibilty of early activation. I believe this sort of unsignalled flag day could be implemented fairly easily by merging PR #19438, adding "int TaprootHeight;" to Conensus::Params, moving "DEPLOYMENT_TAPROOT" from DeploymentPos to BuriedDeployment, adjusting DeploymentHeight(), and setting TaprootHeight=747936 for MAINNET. Might need to add a config param like "-segwitheight" for regtest in order to keep the tests working. I think it would be worthwhile to also update getblocktemplate so that miners signal uptake for something like three or four retarget periods prior to activation, without that signalling having any consensus-level effect. That should allow miners and businesses to adjust their expectations for how much hashpower might not be enforcing taproot rules when generating blocks -- potentially allowing miners to switch pools to one running an up to date node, pools to reduce the amount of time they spend mining on top of unvalidated headers, businesses to increase confirmation requirements or prepare for the possibility of an increase in invalid-block entries in their logs, etc. > 2) The high node-level-adoption bar is one of the most critical goals, and > the one most currently in jeopardy in a BIP 8 approach. A couple of days ago I would have disagreed with this; but with Luke now strongly pushing against implementing lot=false, I can at least see your point... Cheers, aj