path: root/e4/d80493873725fa2b6ade35a5d909fcb8e8ae1d

Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D10C4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 17:26:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B00D2415C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 17:26:24 +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 OQ9WOm5U0VIP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 17:26:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [IPv6:2a00:1450:4864:20::32f])
 by smtp4.osuosl.org (Postfix) with ESMTPS id F1576415DF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 17:26:22 +0000 (UTC)
Received: by mail-wm1-x32f.google.com with SMTP id
 c190-20020a1c35c7000000b0038e37907b5bso12987384wma.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 Apr 2022 10:26:22 -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=GVKo886PljPIpFjLRc7bhamVv6G3tiE0fDJ8BPRi6Yo=;
 b=bon42ODx+LsKbdXCvech7MKzTI+ecsGUcdVjMVQOO67eP01KplooeGGOWfm7GjOQSL
 3aaCQ6+u1Xa4Qoq5/5EOjyQ5O8sK5E13WEW5z84m8wjwVEhFvZKNNxrF5MCq1EASa7e8
 T5zQqvYxyiO/y65X3mPftodFuQcAYQta+Mj33USi8FYGga6W422frtyaMo/jYJRD0UXl
 UeRgPnOdAD36HeZQI5LyNlYY14ZLyeIU5eTX7l3NHqTVAPjQL0Y/HLy7E1/B+NSsmcu1
 IZm/CdqCnbgU2TjZNlcdXtltTrrynU/Cb//8ZE2kPmskYnUEY8OVZq+o1CRwxzptk7lj
 lSIg==
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=GVKo886PljPIpFjLRc7bhamVv6G3tiE0fDJ8BPRi6Yo=;
 b=bvgVbgPby6ChYWniXiVPReVOPX8JUQCPa+YDJTwhF79b3kXiiAIJHDfEAFWS+yFp1a
 JVOuLVj5mI/w6+ktaYLA0zp7BjcTArBbbCSVuFox66Ni+tjXpHsdo9hoVblR4mcL9lid
 +ljCpusaQcPYkHjSFzty2eev9Vthm8wUhJE50FQSdW3TfL78Mg9Ug3Bw3++X+P51DbCH
 QWn/b/aECl8MvV+GckqYMu3rSZV5tPTHYpP9Kjv7rfHIpGkvS0QlA42wh+/E8gOTz/6a
 4sW3PFxRlDtS3ALHu3iMC91eV/cTLBvAru+DDCBjlEWNDKmgT61Tysb/S9cWfU7MebPY
 dKiQ==
X-Gm-Message-State: AOAM532eTCpQKUtNcF/pSelxjfGQHFuptZCBttsZHr+FT4lBNzruviVX
 7gNCafIb9Ag7Qeap9vKMx9ggSCEmfjP61gkXIMdWmgg/G/0=
X-Google-Smtp-Source: ABdhPJxmyLBgET+nMlT2dkrGUiWTi4ZgBCHEek8qF9HhARzgHhq4q1BW9cKsXHMM+PWvoo13xCazsK1bN5GY0Bt93/0=
X-Received: by 2002:a7b:c844:0:b0:37b:b986:7726 with SMTP id
 c4-20020a7bc844000000b0037bb9867726mr18237432wml.160.1650907580877; Mon, 25
 Apr 2022 10:26:20 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDoC5Y=o6Vu7urzBoioVmXBf+YBLg95w-kupx9nidRDBPg@mail.gmail.com>
 <20220326014546.GA12225@erisian.com.au>
 <CABm2gDpMxN0sBCpcbmvYsQbdsGp=JRjAyLhsd6BWyAxdCY95+A@mail.gmail.com>
 <20220330042106.GA13161@erisian.com.au>
 <CABm2gDrsZ9ZimFTkNrdj+wr7328h2N2GmRCawq8xYv3BqyHNow@mail.gmail.com>
 <20220411130522.GA3633@erisian.com.au>
 <CABm2gDqw7ZSLwuFvWstLpkRAFT_4DLWkhNFBLW8m_E46_VWG3A@mail.gmail.com>
 <20220424121429.GA7363@erisian.com.au>
 <CABm2gDo0=psMAKY6Pvfp8b-RvAJdUabiESJpff_yzgwmy7cigQ@mail.gmail.com>
 <CALeFGL19G7eLdM7J9dQrumdVTgo1OyoK6UbzF3oJMkGG55qLzg@mail.gmail.com>
 <20220425170012.GA7453@erisian.com.au>
In-Reply-To: <20220425170012.GA7453@erisian.com.au>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Mon, 25 Apr 2022 11:26:09 -0600
Message-ID: <CALeFGL3Ga+jqGDf0zGVev7RMYnZQVQaRQ7SXxsY=qH+CGhoPpg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000ea502a05dd7ddf6a"
X-Mailman-Approved-At: Mon, 25 Apr 2022 17:26:49 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy Trial
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: Mon, 25 Apr 2022 17:26:24 -0000

--000000000000ea502a05dd7ddf6a
Content-Type: text/plain; charset="UTF-8"

> BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period.

Thanks for the clarification.

> Semi-mandatory in that only "threshold" blocks must signal, so if
    only 4% or 9% of miners aren't signalling and the threshold is set
    at 95% or 90%, no blocks will be orphaned.

How do nodes decide on which blocks are orphaned if only some of them have
to signal, and others don't? Is it just any block that would cause the
whole threshold period to fail?

Keagan

On Mon, Apr 25, 2022 at 11:00 AM Anthony Towns <aj@erisian.com.au> wrote:

> On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Under *any* other circumstance, when they're used to activate a bad
> soft
> > > fork, speedy trial and bip8 are the same. If a resistance method works
> > > against bip8, it works against speedy trial; if it fails against speedy
> > > trial, it fails against bip8.
> > IIRC one essential difference between ST (which is a variant of BIP9) and
> > BIP8 is that since there is no mandatory signaling during the lockin
> > period,
>
> BIP8 doesn't have mandatory signaling during the lockin period, it has
> semi-mandatory [0] signalling during the must_signal period.
>
> > you can't do a counter soft fork as easily.
>
> The "counter" for bip8 activation is to reject any block during either
> the started or must_signal phases that would meet the threshold. In that
> case someone running bip8 might see blocks:
>
>   [elapsed=2010, count=1813, signal=yes]
>   [elapsed=2011, count=1813, signal=no]
>   [elapsed=2012, count=1814, signal=yes]
>   [elapsed=2013, count=1815, signal=yes, will-lockin!]
>   [elapsed=2014, count=1816, signal=yes]
>   [elapsed=2015, count=1816, signal=no]
>   [elapsed=2016, count=1816, signal=no]
>   [locked in!]
>
> But running software to reject the soft fork, you would reject the
> elapsed=2013 block, and any blocks that build on it. You would wait for
> someone else to mine a chain that looked like:
>
>   [elapsed=2013, count=1814, signal=no]
>   [elapsed=2014, count=1814, signal=no]
>   [elapsed=2015, count=1814, signal=no]
>   [elapsed=2016, count=1814, signal=no]
>   [failed!]
>
> That approach works *exactly* the same with speedy trial.
>
> Jeremy's written code that does exactly this using the getdeploymentinfo
> rpc to check the deployment status, and the invalidateblock rpc to
> reject a block. See: https://github.com/JeremyRubin/forkd
>
> The difference to bip8 with lot=true is that nodes running speedy trial
> will reorg to follow the resisting chain if it has the most work. bip8
> with lot=true nodes will not reorg to a failing chain, potentially
> creating an ongoing chain split, unless one group or the other gives up,
> and changes their software.
>
> Cheers,
> aj
>
> [0] Semi-mandatory in that only "threshold" blocks must signal, so if
>     only 4% or 9% of miners aren't signalling and the threshold is set
>     at 95% or 90%, no blocks will be orphaned.
>
>

--000000000000ea502a05dd7ddf6a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; BIP8 doesn&#39;t have mandatory signaling during the =
lockin period, it has<br>semi-mandatory [0] signalling during the must_sign=
al period.<div><br></div><div>Thanks for the clarification.</div><div><br><=
/div><div>&gt; Semi-mandatory in that only &quot;threshold&quot; blocks mus=
t signal, so if</div>=C2=A0 =C2=A0 only 4% or 9% of miners aren&#39;t signa=
lling and the threshold is set<br>=C2=A0 =C2=A0 at 95% or 90%, no blocks wi=
ll be orphaned.<div><br></div><div>How do nodes decide on which blocks are =
orphaned if only some of them have to signal, and others don&#39;t? Is it j=
ust any block that would cause the whole threshold period to fail?</div><di=
v><br></div><div>Keagan</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Mon, Apr 25, 2022 at 11:00 AM Anthony Town=
s &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Apr 25,=
 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev wrote:<br>
&gt; &gt; Under *any* other circumstance, when they&#39;re used to activate=
 a bad soft<br>
&gt; &gt; fork, speedy trial and bip8 are the same. If a resistance method =
works<br>
&gt; &gt; against bip8, it works against speedy trial; if it fails against =
speedy<br>
&gt; &gt; trial, it fails against bip8.<br>
&gt; IIRC one essential difference between ST (which is a variant of BIP9) =
and<br>
&gt; BIP8 is that since there is no mandatory signaling during the lockin<b=
r>
&gt; period, <br>
<br>
BIP8 doesn&#39;t have mandatory signaling during the lockin period, it has<=
br>
semi-mandatory [0] signalling during the must_signal period. <br>
<br>
&gt; you can&#39;t do a counter soft fork as easily.<br>
<br>
The &quot;counter&quot; for bip8 activation is to reject any block during e=
ither<br>
the started or must_signal phases that would meet the threshold. In that<br=
>
case someone running bip8 might see blocks:<br>
<br>
=C2=A0 [elapsed=3D2010, count=3D1813, signal=3Dyes]<br>
=C2=A0 [elapsed=3D2011, count=3D1813, signal=3Dno]<br>
=C2=A0 [elapsed=3D2012, count=3D1814, signal=3Dyes]<br>
=C2=A0 [elapsed=3D2013, count=3D1815, signal=3Dyes, will-lockin!]<br>
=C2=A0 [elapsed=3D2014, count=3D1816, signal=3Dyes]<br>
=C2=A0 [elapsed=3D2015, count=3D1816, signal=3Dno]<br>
=C2=A0 [elapsed=3D2016, count=3D1816, signal=3Dno]<br>
=C2=A0 [locked in!]<br>
<br>
But running software to reject the soft fork, you would reject the<br>
elapsed=3D2013 block, and any blocks that build on it. You would wait for<b=
r>
someone else to mine a chain that looked like:<br>
<br>
=C2=A0 [elapsed=3D2013, count=3D1814, signal=3Dno]<br>
=C2=A0 [elapsed=3D2014, count=3D1814, signal=3Dno]<br>
=C2=A0 [elapsed=3D2015, count=3D1814, signal=3Dno]<br>
=C2=A0 [elapsed=3D2016, count=3D1814, signal=3Dno]<br>
=C2=A0 [failed!]<br>
<br>
That approach works *exactly* the same with speedy trial.<br>
<br>
Jeremy&#39;s written code that does exactly this using the getdeploymentinf=
o<br>
rpc to check the deployment status, and the invalidateblock rpc to<br>
reject a block. See: <a href=3D"https://github.com/JeremyRubin/forkd" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/JeremyRubin/forkd</a><=
br>
<br>
The difference to bip8 with lot=3Dtrue is that nodes running speedy trial<b=
r>
will reorg to follow the resisting chain if it has the most work. bip8<br>
with lot=3Dtrue nodes will not reorg to a failing chain, potentially<br>
creating an ongoing chain split, unless one group or the other gives up,<br=
>
and changes their software.<br>
<br>
Cheers,<br>
aj<br>
<br>
[0] Semi-mandatory in that only &quot;threshold&quot; blocks must signal, s=
o if<br>
=C2=A0 =C2=A0 only 4% or 9% of miners aren&#39;t signalling and the thresho=
ld is set<br>
=C2=A0 =C2=A0 at 95% or 90%, no blocks will be orphaned.<br>
<br>
</blockquote></div>

--000000000000ea502a05dd7ddf6a--