Date: Wed, 11 May 2022 15:15:15 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>
From: alicexbt <alicexbt@protonmail.com>
Reply-To: alicexbt <alicexbt@protonmail.com>
Message-ID: <k_QSGEzNPna1m81VnNhvzXE1e6asLJwXOslQNRTOs6Sqv2BG9K3t0UznguMpoeB11V3I4by5QxbNpyWlRTjtGrO8Y_nlGOaO03Qj-2H9a7A=@protonmail.com>
In-Reply-To: <CAGpPWDbHUqf5_APr3e_hr7npo=ObJvLuWooJc5azMDCDOVSfOA@mail.gmail.com>
References: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com>
 <CAGpPWDbHUqf5_APr3e_hr7npo=ObJvLuWooJc5azMDCDOVSfOA@mail.gmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving BIP 8 soft fork activation
Precedence: list

Hi Billy,

Thanks for the feedback. I agree with everything and=C2=A0bip-trinary-versi=
on-signaling looks interesting.

> A primary difference from both BIP8 and BIP9 is that this proposal uses t=
ri-state version signaling (rather than binary version bits) that can encod=
e both active support as well as active opposition to an active soft fork.


I think 'support' and 'opposition' can be replaced with readiness. Miners s=
hould 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 i=
nterested to read what other developers have to say about it.

Concept ACK on removing LOT, using tri-state version signaling,=C2=A0min/ma=
x 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_activat=
ion_blocks, ie a number of blocks passed the start_height. Slightly easier =
to reason about and change when necessary. I proposed semantics like that h=
ere.
> > In any case, I'll give this a concept ACK. I would very much like futur=
e 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@li=
sts.linuxfoundation.org wrote:
>
> > Hi Bitcoin Developers,
> >
> > There were some disagreements with speedy trial activation method recen=
tly 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.c=
om/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
> >
> > State transitions diagram: https://i.imgur.com/dj4bFVK.png
> >
> > This proposal removes lockinontimeout flag, activation never fails alth=
ough MUST_SIGNAL can be longer if miners signaling does not reach the thres=
hold. Longer period for MUST_SIGNAL state is useful for coordination if LOC=
KED_IN was not reached.
> >
> > MUST_SIGNAL =3D ((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