> 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:

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: michaelfolk...@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
bitcoin-dev mailing list

Reply via email to