diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2022-05-13 07:23:39 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-05-13 12:23:56 +0000 |
| commit | 400ff0f2812fb989d1a6fe77fdf82681c1efa528 (patch) | |
| tree | 5b4c5e5e47b4ed95f500d20c5f9c9aa90d67cfca | |
| parent | 4888838b3ade4623deb912559774b973947be518 (diff) | |
| download | pi-bitcoindev-400ff0f2812fb989d1a6fe77fdf82681c1efa528.tar.gz pi-bitcoindev-400ff0f2812fb989d1a6fe77fdf82681c1efa528.zip | |
Re: [bitcoin-dev] Improving BIP 8 soft fork activation
| -rw-r--r-- | 8d/addd3c5199eee825835dba67fbd81313da1a8b | 338 |
1 files changed, 338 insertions, 0 deletions
diff --git a/8d/addd3c5199eee825835dba67fbd81313da1a8b b/8d/addd3c5199eee825835dba67fbd81313da1a8b new file mode 100644 index 000000000..6b3dd36db --- /dev/null +++ b/8d/addd3c5199eee825835dba67fbd81313da1a8b @@ -0,0 +1,338 @@ +Return-Path: <fresheneesz@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A0C05C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 May 2022 12:23:56 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 8742041577 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 May 2022 12:23:56 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id cX8GfE4n_TDv + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 May 2022 12:23:55 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com + [IPv6:2607:f8b0:4864:20::102d]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 25606408AC + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 May 2022 12:23:55 +0000 (UTC) +Received: by mail-pj1-x102d.google.com with SMTP id + c1-20020a17090a558100b001dca2694f23so7640530pji.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 13 May 2022 05:23:55 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=rOkIy+O0dfSOrrtW4xSHuncX1l59INc+PwbUsP/lmHE=; + b=IjwHM1BgHF1enVj1WDu+K9QVSCu/qkUfkRx1ptUG7HXdjb4vnBcwF4YDXpivFX30Jr + q6hwuh2VQwMcY3G2yJbQsB2r/RaMHmOLZg+c0r54DmrbeUQi4BZ9/zsZSafSXHL0/98I + vS9RINpCbP8bsCXstiM/1xM6SJjgfa80wdoSmQ5E8FHgKvVV112KoQNiEq2xTy+1VmUz + KVH0VMIfBbXyuWL54uj0I0ZyAjCPzLPRApZDeQ6Pji9SVqPePblIR/08L2hLndWZw6E2 + 0iMotIFGOflju0+VCPjZ+BP8WTAYE+2iCYkMWLMCOZvRa09fLFPxUaLYGVgDqNuC8y9h + njYQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=rOkIy+O0dfSOrrtW4xSHuncX1l59INc+PwbUsP/lmHE=; + b=CTgeahfRjuj0YI6hi1iBqUZ7KQJFoTANDmIG9ERIvT/yhj2o6Tsx2sDPN7q/JlvD3l + Hmp87dN3o2huEZe6JijzMiZ4mTi6aBVzqFVQQza7rN2NzpZfLRhhK/RBnba59NqMRRDX + AXrJ7PIAW1x97nUUiF95B5e9zaVN9qnELXXMfsOn1zx6T/WU8uqWiW9HwibSA2yWWzfJ + a3QgK3apYwFBgdz6xr7L18c4kR3dW+mhO53aIVkM5XwTcZfsl2sGTS/ihSO/pkN4NJtY + s3c8f5mpvm5oI92hPGHG0N4ZnHwPIb1MHNp1huIlKnk6JJktd4UC0yxbBbMJY/QX4NKs + 1T3w== +X-Gm-Message-State: AOAM533lpVrik7Ej4IRdRUaV8VL2JfRb+x913UQ/V9msM8x547lR53Ec + z7+968RtVMrCIXHKFXULiXDHXjgZldkaURCd6l9jTSqiDWk= +X-Google-Smtp-Source: ABdhPJzXK02YRYa9Lr3/Zx4bmm/lBLaORQiyPXMkvcaRQZoIKYZ5sRYUSVDeNfsYK5vkMv0z6LNhPFRdGJ5/MmO3yzM= +X-Received: by 2002:a17:90a:930b:b0:1d5:684b:8e13 with SMTP id + p11-20020a17090a930b00b001d5684b8e13mr4671775pjo.153.1652444634526; Fri, 13 + May 2022 05:23:54 -0700 (PDT) +MIME-Version: 1.0 +References: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com> + <CAGpPWDbHUqf5_APr3e_hr7npo=ObJvLuWooJc5azMDCDOVSfOA@mail.gmail.com> + <k_QSGEzNPna1m81VnNhvzXE1e6asLJwXOslQNRTOs6Sqv2BG9K3t0UznguMpoeB11V3I4by5QxbNpyWlRTjtGrO8Y_nlGOaO03Qj-2H9a7A=@protonmail.com> +In-Reply-To: <k_QSGEzNPna1m81VnNhvzXE1e6asLJwXOslQNRTOs6Sqv2BG9K3t0UznguMpoeB11V3I4by5QxbNpyWlRTjtGrO8Y_nlGOaO03Qj-2H9a7A=@protonmail.com> +From: Billy Tetrud <billy.tetrud@gmail.com> +Date: Fri, 13 May 2022 07:23:39 -0500 +Message-ID: <CAGpPWDb=O1UxgbvZi2pwxA+4vnMbjcymwCjT2+hp5L=Kw6JGfQ@mail.gmail.com> +To: alicexbt <alicexbt@protonmail.com> +Content-Type: multipart/alternative; boundary="00000000000073b89505dee3bf7b" +X-Mailman-Approved-At: Fri, 13 May 2022 12:27:07 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Improving BIP 8 soft fork activation +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 13 May 2022 12:23:56 -0000 + +--00000000000073b89505dee3bf7b +Content-Type: text/plain; charset="UTF-8" + +@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 +> + +--00000000000073b89505dee3bf7b +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>@alicexbt<br></div>>=C2=A0 + +I think 'support' and 'opposition' can be replaced with rea= +diness. Miners should not consider signaling as voting.<div><br></div><div>= +I agree that it isn't voting, its signaling. But whether or not you cal= +l it 'readiness' or 'support', some miners will use it to s= +ignal 'support' and will refuse to become ready if they do not supp= +ort the change. Regardless, I'm open to calling it "readiness"= +; instead.=C2=A0</div><div><br></div><div>@Russell=C2=A0<br></div><div>>= +=C2=A0 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.</div><div><br><= +/div><div>I tend to agree. The case where the fork has not locked in, but s= +ome miners are beginning to orphan other miners' blocks, seems like a r= +ather 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 <i>already</i> locked in, but such a thing should be done at a l= +ow 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 lot= +s of orphans and loss of hashpower.=C2=A0</div><div><br></div></div><br><di= +v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 1= +1, 2022 at 10:15 AM alicexbt <<a href=3D"mailto:alicexbt@protonmail.com"= + target=3D"_blank">alicexbt@protonmail.com</a>> wrote:<br></div><blockqu= +ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= + solid rgb(204,204,204);padding-left:1ex">Hi Billy,<br> +<br> +Thanks for the feedback. I agree with everything and=C2=A0bip-trinary-versi= +on-signaling looks interesting.<br> +<br> +> A primary difference from both BIP8 and BIP9 is that this proposal use= +s tri-state version signaling (rather than binary version bits) that can en= +code both active support as well as active opposition to an active soft for= +k.<br> +<br> +<br> +I think 'support' and 'opposition' can be replaced with rea= +diness. Miners should not consider signaling as voting.<br> +<br> +> The meaning for each ternary value is as follows:<br> +<br> +<br> +0 - No signal<br> +1 - Ready for new consensus rules<br> +2 - Not ready for new consensus rules<br> +<br> +The concept of a minimum and maximum threshold sounds intriguing, and I'= +;m interested to read what other developers have to say about it.<br> +<br> +Concept ACK on removing LOT, using tri-state version signaling,=C2=A0min/ma= +x threshold and required threshold calculation.<br> +<br> +<br> +/dev/fd0<br> +<br> +Sent with ProtonMail secure email.<br> +------- Original Message -------<br> +On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud <a href=3D"mailto:billy= +.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a> wrote:<br> +<br> +<br> +<br> +> I think this is a useful proposal. There are certainly things about BI= +P9 that BIP8 fixes. I believe taproot's speedy trial did kind of a hybr= +id, but a BIP spec was never produced for it afaik. A possibly unhelpful co= +mment:<br> +><br> +> > minimum_activation_height<br> +> > I think a minor improvement would be to specify this as minimum_a= +ctivation_blocks, ie a number of blocks passed the start_height. Slightly e= +asier to reason about and change when necessary. I proposed semantics like = +that here.<br> +> > 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 r= +ather than rolling out a rushed unspeced thing as part of the (very orthogo= +nal) soft fork implementation.<br> +> > On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev <a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= +-dev@lists.linuxfoundation.org</a> wrote:<br> +><br> +> > Hi Bitcoin Developers,<br> +> ><br> +> > There were some disagreements with speedy trial activation method= + recently and BIP 8 became controversial because of LOT earlier. I have tri= +ed to solve these two problems after reading some arguments for/against dif= +ferent activation methods by removing LOT from BIP 8 and calculating MUST_S= +IGNAL state based on threshold reached.<br> +> ><br> +> > BIP draft with no code and some changes in BIP 8: <a href=3D"http= +s://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1" rel=3D"n= +oreferrer" target=3D"_blank">https://gist.github.com/1440000bytes/5e58cad7b= +a9d9c1a7000d304920fe6f1</a><br> +> ><br> +> > State transitions diagram: <a href=3D"https://i.imgur.com/dj4bFVK= +.png" rel=3D"noreferrer" target=3D"_blank">https://i.imgur.com/dj4bFVK.png<= +/a><br> +> ><br> +> > This proposal removes lockinontimeout flag, activation never fail= +s 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.<br> +> ><br> +> > MUST_SIGNAL =3D ((100-t)/10)*2016 blocks, where t is threshold re= +ached and blocks that fail to signal in MUST_SIGNAL phase are invalid.<br> +> ><br> +> > Example:<br> +> ><br> +> > - This activation method is used for a soft fork<br> +> > - Only 60% miners signaled readiness and timeout height was reach= +ed<br> +> > - MUST_SIGNAL phase starts and will last for 4*2016 blocks<br> +> > - LOCKED_IN and ACTIVE states remain same as BIP 8<br> +> > - Soft fork is activated with a delay of 2 months<br> +> ><br> +> > /dev/fd0<br> +> ><br> +> > Sent with ProtonMail secure email._______________________________= +________________<br> +> > bitcoin-dev mailing list<br> +> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= +=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit= +coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio= +n.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000073b89505dee3bf7b-- + |