Re: [bitcoin-dev] Improving BIP 8 soft fork activation

From: alicexbt <alicexbt@protonmail•com>
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving BIP 8 soft fork activation
Date: Wed, 11 May 2022 15:15:15 +0000	[thread overview]
Message-ID: <k_QSGEzNPna1m81VnNhvzXE1e6asLJwXOslQNRTOs6Sqv2BG9K3t0UznguMpoeB11V3I4by5QxbNpyWlRTjtGrO8Y_nlGOaO03Qj-2H9a7A=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDbHUqf5_APr3e_hr7npo=ObJvLuWooJc5azMDCDOVSfOA@mail.gmail.com>

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