@alicexbt
>  I think 'support' and 'opposition' can be replaced with readiness. Miners should not consider signaling as voting.

I agree that it isn't voting, its signaling. But whether or not you call it 'readiness' or 'support', some miners will use it to signal 'support' and will refuse to become ready if they do not support the change. Regardless, I'm open to calling it "readiness" instead. 

@Russell 
>  I'm sure there are lots of design choices available better than a MUST_SIGNAL state that does not risk potentially taking a large fraction of mining hardware offline for a protracted period of time.

I tend to agree. The case where the fork has not locked in, but some miners are beginning to orphan other miners' blocks, seems like a rather chaotic state to program into an activation mechanism. I do like the idea of using orphaning to ensure that miners are alerted to the fact that a fork has already locked in, but such a thing should be done at a low level (eg orphan <10% of their blocks) - just high enough so the drop in revenue makes them investigate, but as minimal as possible to avoid lots of orphans and loss of hashpower. 


On Wed, May 11, 2022 at 10:15 AM alicexbt <alicexbt@protonmail.com> wrote:
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.tetrud@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