From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3B2ECC000D for ; Sun, 12 Sep 2021 14:34:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 129646076B for ; Sun, 12 Sep 2021 14:34:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 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, HEXHASH_WORD=1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6oWqgK2oLax for ; Sun, 12 Sep 2021 14:34:21 +0000 (UTC) X-Greylist: delayed 00:05:01 by SQLgrey-1.8.0 Received: from smtpo104.poczta.onet.pl (smtpo104.poczta.onet.pl [213.180.149.157]) by smtp3.osuosl.org (Postfix) with ESMTPS id 7F01E608B8 for ; Sun, 12 Sep 2021 14:34:21 +0000 (UTC) Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4H6sS62NkGz2K2ncH; Sun, 12 Sep 2021 16:29:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1631456951; bh=rJzjG5xaZuuaE6pDUbNj54mEBEsVghcRZzDRelQcwtE=; h=From:To:In-Reply-To:Date:Subject:From; b=JW+4BrQFaaQXdXHh8QbIKYYKPkJ8720NDvxdQdIU/2c16xaUNSijDBnOiT5P2CmWb eHRDn5q2eAWk0goAcSVhjwv1zPR38AfL/iypoI89uj31N9oiQnDGoeTbU2LOpQ1Gcl RfhQt4zvPBjNxESOlEoD35ocuwPDSHxh546F4Co4= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.232.77] by pmq7v.m5r2.onet via HTTP id ; Sun, 12 Sep 2021 16:29:10 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: Anthony Towns ,bitcoin-dev@lists.linuxfoundation.org In-Reply-To: <20210908075903.GA21644@erisian.com.au> Date: Sun, 12 Sep 2021 16:29:08 +0200 Message-Id: <140049304-b536fa7b4b29a5afe6fe058ef76145cb@pmq7v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.232.77;PL;2 X-Mailman-Approved-At: Sun, 12 Sep 2021 14:42:36 +0000 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:34:23 -0000 > - 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 rep= lace that with better value. For example, if you have block 00000086d6b2636= cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with 0x0007f4cc nonce, yo= u can replace that with 0x00110241 nonce and get 000000096a1c4239d994547185= c80308a552cba85d5bd28a51e9dc583ae5eadb 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 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=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 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=3D0 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=3D0 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