vjudeu at gazeta.pl [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-12 📝 Original message:> - 1 block reorgs: these ...
📅 Original date posted:2021-09-12
📝 Original message:> - 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
Anyone can do 1 block reorg, because nonce is not signed, so anyone can replace that with better value. For example, if you have block 00000086d6b2636cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with 0x0007f4cc nonce, you can replace that with 0x00110241 nonce and get 000000096a1c4239d994547185c80308a552cba85d5bd28a51e9dc583ae5eadb block, where everything is identical, except the nonce.
Sometimes that reorg could be deeper if you would be lucky enough to get a block with more work than N following blocks combined.
On 2021-09-08 09:59:29 user Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> 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.
Oh, wow, I think the last suggestion was every 100 blocks (every
~16h40m). Once every ~8h sounds very convenient.
> Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day.
And also for there to reliably be reorgs when they're not awake, which
might be a useful thing to be able to handle, too :)
> 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.
Being able to run `bitcoind -signet -signetacceptreorg=0` and never
seeing any reorgs should presumably make this not a problem?
For people who do see reorgs, having an average of 2 or 3 additional
blocks every 48 blocks is perhaps a 6% increase in storage/traffic.
> # 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.
I think this description is missing that all the blocks R mines have
the to-be-reorged flag set.
> 3. How deep should the reorgs be on average? Do you want to test
> deeper reorgs (10+ blocks) too?
Super interested in input on this -- perhaps we should get optech to
send a survey out to their members, or so?
My feeling is:
- 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
- 2-3 block reorgs: good for testing the "your tx didn't get enough
confirms to be credited to your account" case, even though it barely
ever happens on mainnet
- 4-6 block reorgs: likely to violate business assumptions, but
completely technically plausible, especially if there's an attack
against the network
- 7-100 block reorgs: for this to happen on mainnet, it would probably
mean there was a bug and pools/miners agree the chain has to
be immediately reverted -- eg, someone discovers and exploits an
inflation bug, minting themselves free bitcoins and breaking the 21M
limit (eg, the 51 block reorg in Aug 2010); or someone discovers a
bug that splits the chain, and the less compatible chain is reverted
(eg, the 24 block reorg due to the bdb lock limit in Mar 2013);
or something similar. Obviously the bug would have to have been
discovered pretty quickly after it was exploited for the reorg to be
under a day's worth of blocks.
- 100-2000+ block reorgs: severe bug that wasn't found quickly, or where
getting >50% of miners organised took more than a few hours. This will
start breaking protocol assumptions, like pool payouts, lightning's
relative locktimes, or liquid's peg-in confirmation requirements, and
result in hundres of MBs of changes to the utxo set
Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
special fire-drill event, perhaps once a month/quarter/year or so,
in some pre-announced window?
I think sticking to 1-6 block reorgs initially is a fine way to start
though.
> After enough testing, the default SigNet can start to do periodical
> reorgs, too.
FWIW, the only thing that concerns me about doing this on the default
signet is making sure that nodes that set -signetacceptreorg=0 don't
end up partitioning the p2p network due to either rejecting a higher
work chain or rejecting txs due to double-spends across the two chains.
A quick draft of code for -signetacceptreorg=0 is available at
https://github.com/ajtowns/bitcoin/commits/202108-signetreorg
Cheers,
aj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:> - 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
Anyone can do 1 block reorg, because nonce is not signed, so anyone can replace that with better value. For example, if you have block 00000086d6b2636cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with 0x0007f4cc nonce, you can replace that with 0x00110241 nonce and get 000000096a1c4239d994547185c80308a552cba85d5bd28a51e9dc583ae5eadb block, where everything is identical, except the nonce.
Sometimes that reorg could be deeper if you would be lucky enough to get a block with more work than N following blocks combined.
On 2021-09-08 09:59:29 user Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> 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.
Oh, wow, I think the last suggestion was every 100 blocks (every
~16h40m). Once every ~8h sounds very convenient.
> Such a short reorg interval allows developers in all time
> zones to be awake during one or two reorgs per day.
And also for there to reliably be reorgs when they're not awake, which
might be a useful thing to be able to handle, too :)
> 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.
Being able to run `bitcoind -signet -signetacceptreorg=0` and never
seeing any reorgs should presumably make this not a problem?
For people who do see reorgs, having an average of 2 or 3 additional
blocks every 48 blocks is perhaps a 6% increase in storage/traffic.
> # 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.
I think this description is missing that all the blocks R mines have
the to-be-reorged flag set.
> 3. How deep should the reorgs be on average? Do you want to test
> deeper reorgs (10+ blocks) too?
Super interested in input on this -- perhaps we should get optech to
send a survey out to their members, or so?
My feeling is:
- 1 block reorgs: these are a regular feature on mainnet, everyone
should cope with them; having them happen multiple times a day to
make testing easier should be great
- 2-3 block reorgs: good for testing the "your tx didn't get enough
confirms to be credited to your account" case, even though it barely
ever happens on mainnet
- 4-6 block reorgs: likely to violate business assumptions, but
completely technically plausible, especially if there's an attack
against the network
- 7-100 block reorgs: for this to happen on mainnet, it would probably
mean there was a bug and pools/miners agree the chain has to
be immediately reverted -- eg, someone discovers and exploits an
inflation bug, minting themselves free bitcoins and breaking the 21M
limit (eg, the 51 block reorg in Aug 2010); or someone discovers a
bug that splits the chain, and the less compatible chain is reverted
(eg, the 24 block reorg due to the bdb lock limit in Mar 2013);
or something similar. Obviously the bug would have to have been
discovered pretty quickly after it was exploited for the reorg to be
under a day's worth of blocks.
- 100-2000+ block reorgs: severe bug that wasn't found quickly, or where
getting >50% of miners organised took more than a few hours. This will
start breaking protocol assumptions, like pool payouts, lightning's
relative locktimes, or liquid's peg-in confirmation requirements, and
result in hundres of MBs of changes to the utxo set
Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
special fire-drill event, perhaps once a month/quarter/year or so,
in some pre-announced window?
I think sticking to 1-6 block reorgs initially is a fine way to start
though.
> After enough testing, the default SigNet can start to do periodical
> reorgs, too.
FWIW, the only thing that concerns me about doing this on the default
signet is making sure that nodes that set -signetacceptreorg=0 don't
end up partitioning the p2p network due to either rejecting a higher
work chain or rejecting txs due to double-spends across the two chains.
A quick draft of code for -signetacceptreorg=0 is available at
https://github.com/ajtowns/bitcoin/commits/202108-signetreorg
Cheers,
aj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev