diff options
| author | Anthony Towns <aj@erisian.com.au> | 2021-09-08 17:59:04 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-09-08 07:59:14 +0000 |
| commit | 4cecc2d9cfe3f1bf39b64cce70366cb2743c227e (patch) | |
| tree | 22abd550ee687d9ffe80449799bc92028ad2b792 | |
| parent | fd08d21a699dd3cc6127e7f6e5613c405e248743 (diff) | |
| download | pi-bitcoindev-4cecc2d9cfe3f1bf39b64cce70366cb2743c227e.tar.gz pi-bitcoindev-4cecc2d9cfe3f1bf39b64cce70366cb2743c227e.zip | |
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
| -rw-r--r-- | f9/b5ceef81b752aed9f110f8b764e43603aa85e0 | 157 |
1 files changed, 157 insertions, 0 deletions
diff --git a/f9/b5ceef81b752aed9f110f8b764e43603aa85e0 b/f9/b5ceef81b752aed9f110f8b764e43603aa85e0 new file mode 100644 index 000000000..3ba049b78 --- /dev/null +++ b/f9/b5ceef81b752aed9f110f8b764e43603aa85e0 @@ -0,0 +1,157 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 5CDB0C000D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 8 Sep 2021 07:59:14 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 46D6180F55 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 8 Sep 2021 07:59:14 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.099 +X-Spam-Level: +X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 + tests=[BAYES_05=-0.5, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, + SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] + autolearn=no autolearn_force=no +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 7MBIpYUgcAVR + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 8 Sep 2021 07:59:13 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 390A180F51 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 8 Sep 2021 07:59:13 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) + id 1mNsU7-0001lj-S0; Wed, 08 Sep 2021 17:59:10 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Wed, 08 Sep 2021 17:59:04 +1000 +Date: Wed, 8 Sep 2021 17:59:04 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: 0xB10C <0xb10c@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20210908075903.GA21644@erisian.com.au> +References: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com> +User-Agent: Mutt/1.10.1 (2018-07-13) +X-Spam-Score-int: -18 +X-Spam-Bar: - +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 <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: Wed, 08 Sep 2021 07:59:14 -0000 + +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 + + |