0xB10C [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-07 📝 Original message:Hello, tl;dr: We want to ...
📅 Original date posted:2021-09-07
📝 Original message: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
📝 Original message: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