From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 304E8C000D for ; Tue, 7 Sep 2021 16:44:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 11E5D4018D for ; Tue, 7 Sep 2021 16:44:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c6j_UwVl2Uu for ; Tue, 7 Sep 2021 16:44:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp2.osuosl.org (Postfix) with ESMTPS id 1EA4140150 for ; Tue, 7 Sep 2021 16:44:32 +0000 (UTC) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 187GiUPa028162 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 7 Sep 2021 12:44:31 -0400 Received: by mail-lj1-f179.google.com with SMTP id h1so17553946ljl.9 for ; Tue, 07 Sep 2021 09:44:31 -0700 (PDT) X-Gm-Message-State: AOAM530NP6EeCzckERoXljJ7q6G39wtML/ecT0wrUfj8OkJI4a37jk3H F9Vg4FiiwCMEmfjVO5+Kq4epg3iSHTkacIdst7k= X-Google-Smtp-Source: ABdhPJx+I2IV+vqTdVKi7apFMG3ufUMIh6G9fgNoq07VZkV0jpFWmrkJF908WkxHGVOBlD/SLA0416zFdJMxwk3kZ8s= X-Received: by 2002:a2e:9049:: with SMTP id n9mr15552078ljg.425.1631033069773; Tue, 07 Sep 2021 09:44:29 -0700 (PDT) MIME-Version: 1.0 References: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com> In-Reply-To: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com> From: Jeremy Date: Tue, 7 Sep 2021 09:44:17 -0700 X-Gmail-Original-Message-ID: Message-ID: To: 0xB10C <0xb10c@gmail.com>, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000bdab0a05cb6a7ac4" 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: Tue, 07 Sep 2021 16:44:35 -0000 --000000000000bdab0a05cb6a7ac4 Content-Type: text/plain; charset="UTF-8" If you make the to be reorged flag 2 bits, 1 bit can mark final block and the other can mark to be reorged. That way the nodes opting into reorg can see the reorg and ignore the final blocks (until a certain time? Or until it's via a reorg?), and the nodes wanting not to see reorgs get continuous service without disruption On Tue, Sep 7, 2021, 9:12 AM 0xB10C via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > tl;dr: We want to make reorgs on SigNet a reality and are looking for > feedback on approach and parameters. > > One of the ideas for SigNet is the possibility for it to be reliably > unreliable, for example, planned chain reorganizations. These have not > been implemented yet. > > My summerofbitcoin.org mentee Nikhil Bartwal and I have been looking at > implementing support for reorgs on SigNet. We are looking for feedback > on which approach and parameters to use. Please consider answering the > questions below if you or your company is interested in chain > reorganizations on SigNet. > > With feedback from AJ and Kalle Alm (thanks again!), we came up with two > scenarios that could be implemented in the current SigNet miner script > [0]. Both would trigger automatically in a fixed block interval. > Scenario 1 simulates a race scenario where two chains compete for D > blocks. Scenario 2 simulates a chain rollback where the top D blocks get > replaced by a chain that outgrows the earlier branch. > > AJ proposed to allow SigNet users to opt-out of reorgs in case they > explicitly want to remain unaffected. This can be done by setting a > to-be-reorged version bit flag on the blocks that won't end up in the > most work chain. Node operators could choose not to accept to-be-reorged > SigNet blocks with this flag set via a configuration argument. > > 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. Such a short reorg interval allows developers in all time > zones to be awake during one or two reorgs per day. 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. > > We propose that the reorg depth D is deterministically random between a > minimum and a maximum based on, e.g., the block hash or the nonce of the > last block before the reorg. Compared to a local randint() based > implementation, this allows reorg-handling tests and external tools to > calculate the expected reorg depth. > > # 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. > > # Scenario 2: Chain rollback > > This scenario only requires one miner and Bitcoin Core node but also > works in a multiminer setup. The miners mine D blocks with the > to-be-reorged version bit flag set at the start of the interval. After > allowing the block at height X+D to propagate, they invalidate the block > at height X+1 and start mining on block X again. This time without > setting the to-be-reorged version bit flag. Non-miner nodes will reorg > to the new tip at height X+D+1, and the first-seen branch stalls. > > # Questions > > 1. How do you currently test your applications reorg handling? Do > the two discussed scenarios (race and chain rollback) cover your > needs? Are we missing something you'd find helpful? > > 2. How often should reorgs happen on the default SigNet? Should > there be multiple reorgs a day (e.g., every 48 or 72 blocks > assuming 144 blocks per day) as your engineers need to be awake? > Do you favor less frequent reorgs (once per week or month)? Why? > > 3. How deep should the reorgs be on average? Do you want to test > deeper reorgs (10+ blocks) too? > > > # Next Steps > > We will likely implement Scenario 1, the race between two chains, first. > We'll set up a public test-SigNet along with a faucet, block explorer, > and a block tree visualization. If there is interest in the second > approach, chain rollbacks can be implemented too. Future work will add > the possibility to include conflicting transactions in the two branches. > After enough testing, the default SigNet can start to do periodical > reorgs, too. > > Thanks, > 0xB10C > > [0]: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000bdab0a05cb6a7ac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you make the to be reorged flag 2 bits, 1 bit can mark= final block and the other can mark to be reorged.

That way the nodes opting into reorg can see the reorg= and ignore the final blocks (until a certain time? Or until it's via a= reorg?), and the nodes wanting not to see reorgs get continuous service wi= thout disruption

On Tue, Sep 7, 2021, 9:12 AM 0xB10C via bitcoin-dev &= lt;bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
Hello,

tl;dr: We want to make reorgs on SigNet a reality and are looking for
feedback on approach and parameters.

One of the ideas for SigNet is the possibility for it to be reliably
unreliable, for example, planned chain reorganizations. These have not
been implemented yet.

My summerofbitcoin.org mentee Nikhil Bartwal and I have bee= n looking at
implementing support for reorgs on SigNet. We are looking for feedback
on which approach and parameters to use. Please consider answering the
questions below if you or your company is interested in chain
reorganizations on SigNet.

With feedback from AJ and Kalle Alm (thanks again!), we came up with two scenarios that could be implemented in the current SigNet miner script
[0]. Both would trigger automatically in a fixed block interval.
Scenario 1 simulates a race scenario where two chains compete for D
blocks. Scenario 2 simulates a chain rollback where the top D blocks get replaced by a chain that outgrows the earlier branch.

AJ proposed to allow SigNet users to opt-out of reorgs in case they
explicitly want to remain unaffected. This can be done by setting a
to-be-reorged version bit flag on the blocks that won't end up in the most work chain. Node operators could choose not to accept to-be-reorged SigNet blocks with this flag set via a configuration argument.

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. Such a short reorg interval allows developers in all time
zones to be awake during one or two reorgs per day. 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.

We propose that the reorg depth D is deterministically random between a
minimum and a maximum based on, e.g., the block hash or the nonce of the last block before the reorg. Compared to a local randint() based
implementation, this allows reorg-handling tests and external tools to
calculate the expected reorg depth.

# 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.<= br>
# Scenario 2: Chain rollback

This scenario only requires one miner and Bitcoin Core node but also
works in a multiminer setup. The miners mine D blocks with the
to-be-reorged version bit flag set at the start of the interval. After
allowing the block at height X+D to propagate, they invalidate the block at height X+1 and start mining on block X again. This time without
setting the to-be-reorged version bit flag. Non-miner nodes will reorg
to the new tip at height X+D+1, and the first-seen branch stalls.

# Questions

=C2=A0=C2=A0=C2=A0 1. How do you currently test your applications reorg han= dling? Do
=C2=A0 =C2=A0 =C2=A0 =C2=A0the two discussed scenarios (race and chain roll= back) cover your
=C2=A0 =C2=A0 =C2=A0 =C2=A0needs? Are we missing something you'd find h= elpful?

=C2=A0=C2=A0=C2=A0 2. How often should reorgs happen on the default SigNet?= Should
=C2=A0 =C2=A0 =C2=A0 =C2=A0there be multiple reorgs a day (e.g., every 48 o= r 72 blocks
=C2=A0 =C2=A0 =C2=A0 =C2=A0assuming 144 blocks per day) as your engineers n= eed to be awake?
=C2=A0 =C2=A0 =C2=A0 =C2=A0Do you favor less frequent reorgs (once per week= or month)? Why?

=C2=A0 =C2=A0 3. How deep should the reorgs be on average? Do you want to t= est
=C2=A0 =C2=A0 =C2=A0 =C2=A0deeper reorgs (10+ blocks) too?


# Next Steps

We will likely implement Scenario 1, the race between two chains, first. We'll set up a public test-SigNet along with a faucet, block explorer,<= br> and a block tree visualization. If there is interest in the second
approach, chain rollbacks can be implemented too. Future work will add
the possibility to include conflicting transactions in the two branches. After enough testing, the default SigNet can start to do periodical
reorgs, too.

Thanks,
0xB10C

[0]: https://github.co= m/bitcoin/bitcoin/blob/master/contrib/signet/miner

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000bdab0a05cb6a7ac4--