Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4F2C1C000D for ; Sun, 12 Sep 2021 14:54:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 37FD981775 for ; Sun, 12 Sep 2021 14:54:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaVMOY3iqTFv for ; Sun, 12 Sep 2021 14:54:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by smtp1.osuosl.org (Postfix) with ESMTPS id CAFE68105C for ; Sun, 12 Sep 2021 14:54:44 +0000 (UTC) Received: by mail-yb1-xb33.google.com with SMTP id c206so14897256ybb.12 for ; Sun, 12 Sep 2021 07:54:44 -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=jxxf5sqr6KLtxkcDn5alSXoseSb6FlZagI/X69E7/Yg=; b=L0+IUkHNrvgDN8aX37aAUBXqHfeEUKkfatOf926Vv6w/u87RRlZG/vSaiJzh7JlvF+ Q8lwL+ncW6tI1SQ7BqID5Kk/FyawKGbWYlgV7c1nN+rcwTNaTtqvMxfCE8T2dWG5UD/F M2zCFZSB0zH+G5som6oZAVQAGXysDQaoughce4TFlbZM7gtD+F5gPqzLn8ddc8qO+T9C inAFKUJTSVKTEe/kheB2OlNUExLOpXzulzjS55RL58r9zG/i4u3xooHINEv/3gScXaEp u17txdFwFl0j/Z7qyz7geUaNCCZozod6dgLMLgpYRgHG9AvwyE3nsLjKEt2u3kut07ST owNw== 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=jxxf5sqr6KLtxkcDn5alSXoseSb6FlZagI/X69E7/Yg=; b=XpbwPRVso07xtSlKq5fmJ0CG7bNfj9bxVdUj3OMJSXEGRKj0YBgwLcHCFTstiR1X3F 4oPfYhMnarxr0pmQ05+pAXoj2dqCfgdMwyADtn/ID7IQ01e4nZ/lumgPh9JaeQiclHuF IyYHDi5wSDRDvlDkYz7bNcy1gs59ZcqcM3zZ38jJT1wIUAKcE58iy7T1Ns8KtsGeoNAr QPDEnL6svY80m+/jQsk5all3Nlb+sv4eSuGCMFSXRlxqWA9drXLO2Hb4JCu26MRU90ve Ky6jKkJyZqhlRfU7FIHL47WTpOrKFErZE4QiRHn6gO2MMxi7cXqjGvjln/kS9+pYLSN8 Ghzw== X-Gm-Message-State: AOAM532PDQ0kBrPat6ztCwgQHi+vkLGXcIRTHTZfnIrHxMU5d3Xa7Dba psm0eaOnUd6DtCip78W3voZDckGYs/zqC/mtA45ysMzLvcAJiB/E X-Google-Smtp-Source: ABdhPJxf+JlkiCOW7NKIm+I6e0JevRP40sDcdBdaoTOM1Ac6VGB8ME94Qyox7abfhj+1iaXlE8JQPRQ3QHg6TEvizLY= X-Received: by 2002:a25:4786:: with SMTP id u128mr9848291yba.539.1631458483760; Sun, 12 Sep 2021 07:54:43 -0700 (PDT) MIME-Version: 1.0 References: <20210908075903.GA21644@erisian.com.au> <140049304-b536fa7b4b29a5afe6fe058ef76145cb@pmq7v.m5r2.onet> In-Reply-To: <140049304-b536fa7b4b29a5afe6fe058ef76145cb@pmq7v.m5r2.onet> From: Greg Sanders Date: Sun, 12 Sep 2021 22:54:33 +0800 Message-ID: To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000063f4e805cbcd8785" Cc: Anthony Towns Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters 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: Sun, 12 Sep 2021 14:54:46 -0000 --00000000000063f4e805cbcd8785 Content-Type: text/plain; charset="UTF-8" > Sometimes that reorg could be deeper if you would be lucky enough to get a block with more work than N following blocks combined Each block is credited for its contribution to total chainwork by the difficulty target, not the hash of the block itself. On Sun, Sep 12, 2021 at 10:42 PM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > - 1 block reorgs: these are a regular feature on mainnet, everyone > should cope with them; having them happen multiple times a day to > make testing easier should be great > > Anyone can do 1 block reorg, because nonce is not signed, so anyone can > replace that with better value. For example, if you have block > 00000086d6b2636cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with > 0x0007f4cc nonce, you can replace that with 0x00110241 nonce and get > 000000096a1c4239d994547185c80308a552cba85d5bd28a51e9dc583ae5eadb block, > where everything is identical, except the nonce. > > Sometimes that reorg could be deeper if you would be lucky enough to get a > block with more work than N following blocks combined. > > On 2021-09-08 09:59:29 user Anthony Towns via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote: > > The reorg-interval X very much depends on the user's needs. One could > > argue that there should be, for example, three reorgs per day, each 48 > > blocks apart. > > Oh, wow, I think the last suggestion was every 100 blocks (every > ~16h40m). Once every ~8h sounds very convenient. > > > Such a short reorg interval allows developers in all time > > zones to be awake during one or two reorgs per day. > > And also for there to reliably be reorgs when they're not awake, which > might be a useful thing to be able to handle, too :) > > > Developers don't > > need to wait for, for example, a week until they can test their reorgs > > next. However, too frequent reorgs could hinder other SigNet users. > > Being able to run `bitcoind -signet -signetacceptreorg=0` and never > seeing any reorgs should presumably make this not a problem? > > For people who do see reorgs, having an average of 2 or 3 additional > blocks every 48 blocks is perhaps a 6% increase in storage/traffic. > > > # Scenario 1: Race between two chains > > > > For this scenario, at least two nodes and miner scripts need to be > > running. An always-miner A continuously produces blocks and rejects > > blocks with the to-be-reorged version bit flag set. And a race-miner R > > that only mines D blocks at the start of each interval and then waits X > > blocks. A and R both have the same hash rate. Assuming both are well > > connected to the network, it's random which miner will first mine and > > propagate a block. In the end, the A miner chain will always win the > race. > > I think this description is missing that all the blocks R mines have > the to-be-reorged flag set. > > > 3. How deep should the reorgs be on average? Do you want to test > > deeper reorgs (10+ blocks) too? > > Super interested in input on this -- perhaps we should get optech to > send a survey out to their members, or so? > > My feeling is: > > - 1 block reorgs: these are a regular feature on mainnet, everyone > should cope with them; having them happen multiple times a day to > make testing easier should be great > > - 2-3 block reorgs: good for testing the "your tx didn't get enough > confirms to be credited to your account" case, even though it barely > ever happens on mainnet > > - 4-6 block reorgs: likely to violate business assumptions, but > completely technically plausible, especially if there's an attack > against the network > > - 7-100 block reorgs: for this to happen on mainnet, it would probably > mean there was a bug and pools/miners agree the chain has to > be immediately reverted -- eg, someone discovers and exploits an > inflation bug, minting themselves free bitcoins and breaking the 21M > limit (eg, the 51 block reorg in Aug 2010); or someone discovers a > bug that splits the chain, and the less compatible chain is reverted > (eg, the 24 block reorg due to the bdb lock limit in Mar 2013); > or something similar. Obviously the bug would have to have been > discovered pretty quickly after it was exploited for the reorg to be > under a day's worth of blocks. > > - 100-2000+ block reorgs: severe bug that wasn't found quickly, or where > getting >50% of miners organised took more than a few hours. This will > start breaking protocol assumptions, like pool payouts, lightning's > relative locktimes, or liquid's peg-in confirmation requirements, and > result in hundres of MBs of changes to the utxo set > > Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a > special fire-drill event, perhaps once a month/quarter/year or so, > in some pre-announced window? > > I think sticking to 1-6 block reorgs initially is a fine way to start > though. > > > After enough testing, the default SigNet can start to do periodical > > reorgs, too. > > FWIW, the only thing that concerns me about doing this on the default > signet is making sure that nodes that set -signetacceptreorg=0 don't > end up partitioning the p2p network due to either rejecting a higher > work chain or rejecting txs due to double-spends across the two chains. > > A quick draft of code for -signetacceptreorg=0 is available at > > https://github.com/ajtowns/bitcoin/commits/202108-signetreorg > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000063f4e805cbcd8785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Sometimes that reorg could be deeper if you would be = lucky enough to get a block with more work than N following blocks combined=

Each block is credited for its contribution to total ch= ainwork by the difficulty target, not the hash of the block itself.

On= Sun, Sep 12, 2021 at 10:42 PM vjudeu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:
bitcoin-dev@l= ists.linuxfoundation.org> wrote:
> On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote= :
> The reorg-interval X very much depends on the user's needs. One co= uld
> argue that there should be, for example, three reorgs per day, each 48=
> blocks apart.

Oh, wow, I think the last suggestion was every 100 blocks (every
~16h40m). Once every ~8h sounds very convenient.

> Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day.

And also for there to reliably be reorgs when they're not awake, which<= br> might be a useful thing to be able to handle, too :)

> Developers don't
> need to wait for, for example, a week until they can test their reorgs=
> next. However, too frequent reorgs could hinder other SigNet users.
Being able to run `bitcoind -signet -signetacceptreorg=3D0` and never
seeing any reorgs should presumably make this not a problem?

For people who do see reorgs, having an average of 2 or 3 additional
blocks every 48 blocks is perhaps a 6% increase in storage/traffic.

> # Scenario 1: Race between two chains
>
> For this scenario, at least two nodes and miner scripts need to be
> running. An always-miner A continuously produces blocks and rejects > blocks with the to-be-reorged version bit flag set. And a race-miner R=
> that only mines D blocks at the start of each interval and then waits = X
> blocks. A and R both have the same hash rate. Assuming both are well > connected to the network, it's random which miner will first mine = and
> propagate a block. In the end, the A miner chain will always win the r= ace.

I think this description is missing that all the blocks R mines have
the to-be-reorged flag set.

>=C2=A0 =C2=A0 =C2=A03. How deep should the reorgs be on average? Do you= want to test
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 deeper reorgs (10+ blocks) too?

Super interested in input on this -- perhaps we should get optech to
send a survey out to their members, or so?

My feeling is:

=C2=A0- 1 block reorgs: these are a regular feature on mainnet, everyone =C2=A0 =C2=A0should cope with them; having them happen multiple times a day= to
=C2=A0 =C2=A0make testing easier should be great

=C2=A0- 2-3 block reorgs: good for testing the "your tx didn't get= enough
=C2=A0 =C2=A0confirms to be credited to your account" case, even thoug= h it barely
=C2=A0 =C2=A0ever happens on mainnet

=C2=A0- 4-6 block reorgs: likely to violate business assumptions, but
=C2=A0 =C2=A0completely technically plausible, especially if there's an= attack
=C2=A0 =C2=A0against the network

=C2=A0- 7-100 block reorgs: for this to happen on mainnet, it would probabl= y
=C2=A0 =C2=A0mean there was a bug and pools/miners agree the chain has to =C2=A0 =C2=A0be immediately reverted -- eg, someone discovers and exploits = an
=C2=A0 =C2=A0inflation bug, minting themselves free bitcoins and breaking t= he 21M
=C2=A0 =C2=A0limit (eg, the 51 block reorg in Aug 2010); or someone discove= rs a
=C2=A0 =C2=A0bug that splits the chain, and the less compatible chain is re= verted
=C2=A0 =C2=A0(eg, the 24 block reorg due to the bdb lock limit in Mar 2013)= ;
=C2=A0 =C2=A0or something similar. Obviously the bug would have to have bee= n
=C2=A0 =C2=A0discovered pretty quickly after it was exploited for the reorg= to be
=C2=A0 =C2=A0under a day's worth of blocks.

=C2=A0- 100-2000+ block reorgs: severe bug that wasn't found quickly, o= r where
=C2=A0 =C2=A0getting >50% of miners organised took more than a few hours= . This will
=C2=A0 =C2=A0start breaking protocol assumptions, like pool payouts, lightn= ing's
=C2=A0 =C2=A0relative locktimes, or liquid's peg-in confirmation requir= ements, and
=C2=A0 =C2=A0result in hundres of MBs of changes to the utxo set

Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
special fire-drill event, perhaps once a month/quarter/year or so,
in some pre-announced window?

I think sticking to 1-6 block reorgs initially is a fine way to start
though.

> After enough testing, the default SigNet can start to do periodical > reorgs, too.

FWIW, the only thing that concerns me about doing this on the default
signet is making sure that nodes that set -signetacceptreorg=3D0 don't<= br> end up partitioning the p2p network due to either rejecting a higher
work chain or rejecting txs due to double-spends across the two chains.

A quick draft of code for -signetacceptreorg=3D0 is available at

=C2=A0 https://github.com/ajtowns/bitco= in/commits/202108-signetreorg

Cheers,
aj

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000063f4e805cbcd8785--