path: root/8d/addd3c5199eee825835dba67fbd81313da1a8b

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>&gt;=C2=A0

I think &#39;support&#39; and &#39;opposition&#39; can be replaced with rea=
diness. Miners should not consider signaling as voting.<div><br></div><div>=
I agree that it isn&#39;t voting, its signaling. But whether or not you cal=
l it &#39;readiness&#39; or &#39;support&#39;, some miners will use it to s=
ignal &#39;support&#39; and will refuse to become ready if they do not supp=
ort the change. Regardless, I&#39;m open to calling it &quot;readiness&quot=
; instead.=C2=A0</div><div><br></div><div>@Russell=C2=A0<br></div><div>&gt;=
=C2=A0 I&#39;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&#39; 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 &lt;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 &lt;<a href=3D"mailto:alicexbt@protonmail.com"=
 target=3D"_blank">alicexbt@protonmail.com</a>&gt; 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>
&gt; 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 &#39;support&#39; and &#39;opposition&#39; can be replaced with rea=
diness. Miners should not consider signaling as voting.<br>
<br>
&gt; 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&#39=
;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>
&gt; I think this is a useful proposal. There are certainly things about BI=
P9 that BIP8 fixes. I believe taproot&#39;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>
&gt;<br>
&gt; &gt; minimum_activation_height<br>
&gt; &gt; 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>
&gt; &gt; In any case, I&#39;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>
&gt; &gt; 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>
&gt;<br>
&gt; &gt; Hi Bitcoin Developers,<br>
&gt; &gt;<br>
&gt; &gt; 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>
&gt; &gt;<br>
&gt; &gt; 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>
&gt; &gt;<br>
&gt; &gt; 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>
&gt; &gt;<br>
&gt; &gt; 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>
&gt; &gt;<br>
&gt; &gt; 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>
&gt; &gt;<br>
&gt; &gt; Example:<br>
&gt; &gt;<br>
&gt; &gt; - This activation method is used for a soft fork<br>
&gt; &gt; - Only 60% miners signaled readiness and timeout height was reach=
ed<br>
&gt; &gt; - MUST_SIGNAL phase starts and will last for 4*2016 blocks<br>
&gt; &gt; - LOCKED_IN and ACTIVE states remain same as BIP 8<br>
&gt; &gt; - Soft fork is activated with a delay of 2 months<br>
&gt; &gt;<br>
&gt; &gt; /dev/fd0<br>
&gt; &gt;<br>
&gt; &gt; Sent with ProtonMail secure email._______________________________=
________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <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--