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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
