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