MIME-Version: 1.0
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Mon, 15 Mar 2021 14:06:45 +0000
Message-ID: <CAFvNmHRbH3oRFdvbCHGSaB2zmL2dvo-n71dKK8=Qs7Qa6SGVXg@mail.gmail.com>
To: achow101-lists@achow101.com
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Precedence: list

> I don't think we should have a followup deployment start so close to to
timeout of ST. I think it would be better to schedule the followup
around ST, especially since the details around that are fuzzier and
dependent on the results of ST itself.

Until Core pull request(s) are merged I don't think we can finalize
startheight (and hence the timeout) for Speedy Trial either.

Speedy Trial seems to have the most community consensus of any
activation proposal thus far and I'm confident it will at some point
in the near future it will be merged into Core.

Community feedback:
https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f

Therefore I think the onus is on any UASF release to fit around a
Speedy Trial deployment in Core. I haven't thought enough about what
my preference would be assuming activation fails with Speedy Trial re
a follow up deployment in Core and/or a UASF release. However, I would
be 100 percent opposed to any UASF release that conflicts or is not
compatible with a Speedy Trial deployment in Core.

On 3/14/21 10:51 PM, Luke Dashjr wrote:
> The last period before timeoutheight here overlaps with the current BIP8(True)
> deployment plan. So if this period specifically were to reach 90% signalling,
> nodes would activate Taproot at height 697536, but ST-only nodes would still
> wait until 709632 instead.
>
> Probably the best solution is to just move this ST window 1 period earlier?
>
> Luke


-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3