š
Original date posted:2021-09-07
š Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210907/4f2f687d/attachment.html>;
Jeremy [ARCHIVE] /
npub1q8ā¦8qwta
2023-06-07 22:58:47
in reply to nevent1qā¦0z0a
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 22:58:47Event JSON
{
"id": "d9ce1fc507f9ab87a02eae38a9170da5bcaf43c2eea8db0ae9be5448682f8ca7",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686178727,
"kind": 1,
"tags": [
[
"e",
"82e0f12d7f35467c29cd59e777250289c4cb4554dc58ceaaad44bec4613bd98c",
"",
"root"
],
[
"e",
"9fb0bc576feb8a2dac3a9109ec08f8c8d306d93b41cda94c3ab9469f41d6e2dc",
"",
"reply"
],
[
"p",
"559073fb989f61f2de8444958a5a056e4d66f1e086ee68d4ece66518f4076cf7"
]
],
"content": "š
Original date posted:2021-09-07\nš Original message:If you make the to be reorged flag 2 bits, 1 bit can mark final block and\nthe other can mark to be reorged.\n\nThat way the nodes opting into reorg can see the reorg and ignore the final\nblocks (until a certain time? Or until it's via a reorg?), and the nodes\nwanting not to see reorgs get continuous service without disruption\n\nOn Tue, Sep 7, 2021, 9:12 AM 0xB10C via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hello,\n\u003e\n\u003e tl;dr: We want to make reorgs on SigNet a reality and are looking for\n\u003e feedback on approach and parameters.\n\u003e\n\u003e One of the ideas for SigNet is the possibility for it to be reliably\n\u003e unreliable, for example, planned chain reorganizations. These have not\n\u003e been implemented yet.\n\u003e\n\u003e My summerofbitcoin.org mentee Nikhil Bartwal and I have been looking at\n\u003e implementing support for reorgs on SigNet. We are looking for feedback\n\u003e on which approach and parameters to use. Please consider answering the\n\u003e questions below if you or your company is interested in chain\n\u003e reorganizations on SigNet.\n\u003e\n\u003e With feedback from AJ and Kalle Alm (thanks again!), we came up with two\n\u003e scenarios that could be implemented in the current SigNet miner script\n\u003e [0]. Both would trigger automatically in a fixed block interval.\n\u003e Scenario 1 simulates a race scenario where two chains compete for D\n\u003e blocks. Scenario 2 simulates a chain rollback where the top D blocks get\n\u003e replaced by a chain that outgrows the earlier branch.\n\u003e\n\u003e AJ proposed to allow SigNet users to opt-out of reorgs in case they\n\u003e explicitly want to remain unaffected. This can be done by setting a\n\u003e to-be-reorged version bit flag on the blocks that won't end up in the\n\u003e most work chain. Node operators could choose not to accept to-be-reorged\n\u003e SigNet blocks with this flag set via a configuration argument.\n\u003e\n\u003e The reorg-interval X very much depends on the user's needs. One could\n\u003e argue that there should be, for example, three reorgs per day, each 48\n\u003e blocks apart. Such a short reorg interval allows developers in all time\n\u003e zones to be awake during one or two reorgs per day. Developers don't\n\u003e need to wait for, for example, a week until they can test their reorgs\n\u003e next. However, too frequent reorgs could hinder other SigNet users.\n\u003e\n\u003e We propose that the reorg depth D is deterministically random between a\n\u003e minimum and a maximum based on, e.g., the block hash or the nonce of the\n\u003e last block before the reorg. Compared to a local randint() based\n\u003e implementation, this allows reorg-handling tests and external tools to\n\u003e calculate the expected reorg depth.\n\u003e\n\u003e # Scenario 1: Race between two chains\n\u003e\n\u003e For this scenario, at least two nodes and miner scripts need to be\n\u003e running. An always-miner A continuously produces blocks and rejects\n\u003e blocks with the to-be-reorged version bit flag set. And a race-miner R\n\u003e that only mines D blocks at the start of each interval and then waits X\n\u003e blocks. A and R both have the same hash rate. Assuming both are well\n\u003e connected to the network, it's random which miner will first mine and\n\u003e propagate a block. In the end, the A miner chain will always win the race.\n\u003e\n\u003e # Scenario 2: Chain rollback\n\u003e\n\u003e This scenario only requires one miner and Bitcoin Core node but also\n\u003e works in a multiminer setup. The miners mine D blocks with the\n\u003e to-be-reorged version bit flag set at the start of the interval. After\n\u003e allowing the block at height X+D to propagate, they invalidate the block\n\u003e at height X+1 and start mining on block X again. This time without\n\u003e setting the to-be-reorged version bit flag. Non-miner nodes will reorg\n\u003e to the new tip at height X+D+1, and the first-seen branch stalls.\n\u003e\n\u003e # Questions\n\u003e\n\u003e 1. How do you currently test your applications reorg handling? Do\n\u003e the two discussed scenarios (race and chain rollback) cover your\n\u003e needs? Are we missing something you'd find helpful?\n\u003e\n\u003e 2. How often should reorgs happen on the default SigNet? Should\n\u003e there be multiple reorgs a day (e.g., every 48 or 72 blocks\n\u003e assuming 144 blocks per day) as your engineers need to be awake?\n\u003e Do you favor less frequent reorgs (once per week or month)? Why?\n\u003e\n\u003e 3. How deep should the reorgs be on average? Do you want to test\n\u003e deeper reorgs (10+ blocks) too?\n\u003e\n\u003e\n\u003e # Next Steps\n\u003e\n\u003e We will likely implement Scenario 1, the race between two chains, first.\n\u003e We'll set up a public test-SigNet along with a faucet, block explorer,\n\u003e and a block tree visualization. If there is interest in the second\n\u003e approach, chain rollbacks can be implemented too. Future work will add\n\u003e the possibility to include conflicting transactions in the two branches.\n\u003e After enough testing, the default SigNet can start to do periodical\n\u003e reorgs, too.\n\u003e\n\u003e Thanks,\n\u003e 0xB10C\n\u003e\n\u003e [0]: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210907/4f2f687d/attachment.html\u003e",
"sig": "72a3e507b20e44c725ef6bfad3b09d7e12bd4fd5038ee0e15fcc04253ae3be7c98993474cf7a9dccd283bc0b63ddc9d5e3ec4ef6804cdfe4e8bc580fb8ba69b6"
}