Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D10C4C002D for ; 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 ; 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 ; 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 ; Mon, 25 Apr 2022 17:26:22 +0000 (UTC) Received: by mail-wm1-x32f.google.com with SMTP id c190-20020a1c35c7000000b0038e37907b5bso12987384wma.0 for ; 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: <20220326014546.GA12225@erisian.com.au> <20220330042106.GA13161@erisian.com.au> <20220411130522.GA3633@erisian.com.au> <20220424121429.GA7363@erisian.com.au> <20220425170012.GA7453@erisian.com.au> In-Reply-To: <20220425170012.GA7453@erisian.com.au> From: Keagan McClelland Date: Mon, 25 Apr 2022 11:26:09 -0600 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="000000000000ea502a05dd7ddf6a" X-Mailman-Approved-At: Mon, 25 Apr 2022 17:26:49 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
> BIP8 doesn't have mandatory signaling during the = lockin period, it has
semi-mandatory [0] signalling during the must_sign= al period.

Thanks for the clarification.

<= /div>
> Semi-mandatory in that only "threshold" blocks mus= t signal, so if
=C2=A0 =C2=A0 only 4% or 9% of miners aren't signa= lling and the threshold is set
=C2=A0 =C2=A0 at 95% or 90%, no blocks wi= ll 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 j= ust any block that would cause the whole threshold period to fail?

Keagan

On Mon, Apr 25, 2022 at 11:00 AM Anthony Town= s <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<= br> 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 e= ither
the started or must_signal phases that would meet the threshold. In that case someone running bip8 might see blocks:

=C2=A0 [elapsed=3D2010, count=3D1813, signal=3Dyes]
=C2=A0 [elapsed=3D2011, count=3D1813, signal=3Dno]
=C2=A0 [elapsed=3D2012, count=3D1814, signal=3Dyes]
=C2=A0 [elapsed=3D2013, count=3D1815, signal=3Dyes, will-lockin!]
=C2=A0 [elapsed=3D2014, count=3D1816, signal=3Dyes]
=C2=A0 [elapsed=3D2015, count=3D1816, signal=3Dno]
=C2=A0 [elapsed=3D2016, count=3D1816, signal=3Dno]
=C2=A0 [locked in!]

But running software to reject the soft fork, you would reject the
elapsed=3D2013 block, and any blocks that build on it. You would wait for someone else to mine a chain that looked like:

=C2=A0 [elapsed=3D2013, count=3D1814, signal=3Dno]
=C2=A0 [elapsed=3D2014, count=3D1814, signal=3Dno]
=C2=A0 [elapsed=3D2015, count=3D1814, signal=3Dno]
=C2=A0 [elapsed=3D2016, count=3D1814, signal=3Dno]
=C2=A0 [failed!]

That approach works *exactly* the same with speedy trial.

Jeremy's written code that does exactly this using the getdeploymentinf= o
rpc to check the deployment status, and the invalidateblock rpc to
reject a block. See: https://github.com/JeremyRubin/forkd<= br>
The difference to bip8 with lot=3Dtrue is that nodes running speedy trial will reorg to follow the resisting chain if it has the most work. bip8
with lot=3Dtrue 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, s= o if
=C2=A0 =C2=A0 only 4% or 9% of miners aren't signalling and the thresho= ld is set
=C2=A0 =C2=A0 at 95% or 90%, no blocks will be orphaned.

--000000000000ea502a05dd7ddf6a--