Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

From: Jeremy <jlrubin@mit•edu>
To: 0xB10C <0xb10c@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
Date: Tue, 7 Sep 2021 09:44:17 -0700	[thread overview]
Message-ID: <CAD5xwhh7j5maMOs6TGHAAKz2_HqU0RYv9C1F_wPOMFrZftPdAQ@mail.gmail.com> (raw)
In-Reply-To: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com>

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

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
>

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