public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2021-09-07 16:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 16:07 [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters 0xB10C
2021-09-07 16:44 ` Jeremy [this message]
2021-09-08  7:59 ` Anthony Towns
2021-09-12 14:29   ` vjudeu
2021-09-12 14:54     ` Greg Sanders
2021-09-10  0:50 ` Matt Corallo
2021-09-12  7:53   ` Anthony Towns
2021-09-13  5:33     ` Matt Corallo
2021-09-14  4:56       ` Anthony Towns
2021-09-15 15:24         ` Matt Corallo
2021-10-15  4:41           ` Anthony Towns
2021-09-10 13:05 Michael Folkson
2021-09-10 18:24 ` Matt Corallo
2021-09-10 19:00   ` Michael Folkson
2021-09-10 19:22     ` Matt Corallo
2021-09-10 20:00   ` David A. Harding
2021-09-13 12:30 Michael Folkson
2021-09-13 16:24 ` Matt Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD5xwhh7j5maMOs6TGHAAKz2_HqU0RYv9C1F_wPOMFrZftPdAQ@mail.gmail.com \
    --to=jlrubin@mit.edu \
    --cc=0xb10c@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox