public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian•com.au>
To: Matt Corallo <lf-lists@mattcorallo•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Date: Thu, 4 Mar 2021 00:59:02 +1000	[thread overview]
Message-ID: <20210303145902.cl4mzg6l7avjboil@erisian.com.au> (raw)
In-Reply-To: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>

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



  parent reply	other threads:[~2021-03-03 14:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-28 16:45 Matt Corallo
2021-02-28 17:20 ` Luke Dashjr
2021-02-28 17:29   ` Matt Corallo
2021-02-28 19:43     ` Jeremy
2021-02-28 19:51       ` Matt Corallo
2021-02-28 20:02         ` Jeremy
2021-02-28 20:19           ` Eric Voskuil
2021-02-28 20:25             ` Matt Corallo
2021-02-28 20:38               ` Eric Voskuil
2021-02-28 20:20           ` Matt Corallo
2021-03-03 14:59 ` Anthony Towns [this message]
2021-03-03 16:49   ` Matt Corallo
2021-03-06 11:33     ` Anthony Towns
2021-03-08 12:51       ` Jorge Timón
2021-03-08 14:13         ` eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210303145902.cl4mzg6l7avjboil@erisian.com.au \
    --to=aj@erisian$(echo .)com.au \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lf-lists@mattcorallo$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox