I think this is a useful proposal. There are certainly things about BIP9 that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but a BIP spec was never produced for it afaik. A possibly unhelpful comment: > minimum_activation_height I think a minor improvement would be to specify this as minimum_activation_blocks, ie a number of blocks passed the start_height. Slightly easier to reason about and change when necessary. I proposed semantics like that here . In any case, I'll give this a concept ACK. I would very much like future soft forks to use a previously specified activation mechanism rather than rolling out a rushed unspeced thing as part of the (very orthogonal) soft fork implementation. On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Bitcoin Developers, > > There were some disagreements with speedy trial activation method recently > and BIP 8 became controversial because of LOT earlier. I have tried to > solve these two problems after reading some arguments for/against different > activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL > state based on threshold reached. > > BIP draft with no code and some changes in BIP 8: > https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1 > > State transitions diagram: https://i.imgur.com/dj4bFVK.png > > This proposal removes lockinontimeout flag, activation never fails > although MUST_SIGNAL can be longer if miners signaling does not reach the > threshold. Longer period for MUST_SIGNAL state is useful for coordination > if LOCKED_IN was not reached. > > MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and > blocks that fail to signal in MUST_SIGNAL phase are invalid. > > Example: > > - This activation method is used for a soft fork > - Only 60% miners signaled readiness and timeout height was reached > - MUST_SIGNAL phase starts and will last for 4*2016 blocks > - LOCKED_IN and ACTIVE states remain same as BIP 8 > - Soft fork is activated with a delay of 2 months > > > /dev/fd0 > > Sent with ProtonMail secure email. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >