public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Keagan McClelland <keagan.mcclelland@gmail•com>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy Trial
Date: Mon, 25 Apr 2022 11:26:09 -0600	[thread overview]
Message-ID: <CALeFGL3Ga+jqGDf0zGVev7RMYnZQVQaRQ7SXxsY=qH+CGhoPpg@mail.gmail.com> (raw)
In-Reply-To: <20220425170012.GA7453@erisian.com.au>

[-- Attachment #1: Type: text/plain, Size: 3038 bytes --]

> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 3801 bytes --]

  reply	other threads:[~2022-04-25 17:26 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11  0:12 Russell O'Connor
2022-03-11  0:28 ` Luke Dashjr
2022-03-11  5:41   ` Billy Tetrud
2022-03-11 12:19 ` Jorge Timón
2022-03-11 13:47   ` Russell O'Connor
2022-03-11 14:04     ` Jorge Timón
2022-03-12 13:34       ` Russell O'Connor
2022-03-12 17:52         ` Billy Tetrud
2022-03-17 12:18           ` Jorge Timón
2022-03-23 22:34           ` Kate Salazar
2022-03-15 17:21         ` Jeremy Rubin
2022-03-17  4:17           ` Billy Tetrud
2022-03-18 18:36           ` Jorge Timón
2022-03-17 12:08         ` Jorge Timón
2022-03-17 15:38           ` Billy Tetrud
2022-03-18 23:01             ` ZmnSCPxj
2022-03-21  3:41               ` Billy Tetrud
2022-03-21 15:56                 ` vjudeu
2022-03-22 15:19                   ` Billy Tetrud
2022-03-22 15:45                     ` Eric Voskuil
2022-03-22 16:37                     ` vjudeu
2022-03-19 16:43             ` vjudeu
2022-03-15 15:45       ` Anthony Towns
2022-03-17 14:04         ` Jorge Timón
2022-03-22 23:49           ` Anthony Towns
2022-03-24 18:30             ` Jorge Timón
2022-03-26  1:45               ` Anthony Towns
2022-03-28  8:31                 ` Jorge Timón
2022-03-30  4:21                   ` Anthony Towns
2022-04-08  9:58                     ` Jorge Timón
2022-04-11 13:05                       ` Anthony Towns
2022-04-24 11:13                         ` Jorge Timón
2022-04-24 12:14                           ` Anthony Towns
2022-04-24 12:44                             ` Jorge Timón
2022-04-25 16:11                               ` Keagan McClelland
2022-04-25 17:00                                 ` Anthony Towns
2022-04-25 17:26                                   ` Keagan McClelland [this message]
2022-04-26  5:42                                     ` Anthony Towns
2022-04-26 13:05                                       ` Erik Aronesty
2022-04-27  2:35                                         ` Billy Tetrud
2022-03-11 16:26     ` Billy Tetrud
2022-03-17 11:32       ` Jorge Timón
2022-03-11 11:14 pushd
2022-03-12 17:11 pushd
2022-03-17 14:34 pushd
2022-03-26 12:59 pushd
2022-03-30 10:34 pushd
2022-03-30 20:10 ` Billy Tetrud
2022-03-30 21:14   ` pushd
2022-03-31  4:31     ` Billy Tetrud
2022-03-31 14:19       ` pushd
2022-03-31 15:34         ` Billy Tetrud
2022-03-31 15:55           ` pushd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALeFGL3Ga+jqGDf0zGVev7RMYnZQVQaRQ7SXxsY=qH+CGhoPpg@mail.gmail.com' \
    --to=keagan.mcclelland@gmail$(echo .)com \
    --cc=aj@erisian$(echo .)com.au \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox