Hi Billy, Thanks for the feedback. I agree with everything and bip-trinary-version-signaling looks interesting.
> A primary difference from both BIP8 and BIP9 is that this proposal uses > tri-state version signaling (rather than binary version bits) that can encode > both active support as well as active opposition to an active soft fork. I think 'support' and 'opposition' can be replaced with readiness. Miners should not consider signaling as voting. > The meaning for each ternary value is as follows: 0 - No signal 1 - Ready for new consensus rules 2 - Not ready for new consensus rules The concept of a minimum and maximum threshold sounds intriguing, and I'm interested to read what other developers have to say about it. Concept ACK on removing LOT, using tri-state version signaling, min/max threshold and required threshold calculation. /dev/fd0 Sent with ProtonMail secure email. ------- Original Message ------- On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tet...@gmail.com wrote: > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
