Date: Thu, 4 Mar 2021 00:59:02 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210303145902.cl4mzg6l7avjboil@erisian.com.au>
References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Precedence: list

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