Handling reorgs in bitcoin node

[hhanh00]

Let's say a node is synced up to block #100 and receives a chain from #90 to #100 that claims to be better. But in fact, in the block #95, there is a double spend (from a txo created in #91 of the new fork) that makes #95 to #100 invalid.
However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

I wonder how bitcoin core (and the alternate implementations) handle this case.

Thanks,
--h

PS: To give an idea, my reorg code rolls back the utxo set to #90 before attempting to attach the new fork. But I don't see where it's done in bitcoin core and libbitcoin. Maybe they work differently?

[1715442597]

1715442597

[1715442597]

1715442597

[achow101]

Let's say a node is synced up to block #100 and receives a chain from #90 to #100 that claims to be better. But in fact, in the block #95, there is a double spend (from a txo created in #91 of the new fork) that makes #95 to #100 invalid.
However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

What do you mean by "block #95, there is a double spend"? The blockchain does not allow double spends.

For reorgs, AFAIK Bitcoin Core goes with the chain it receives first unless the other chain is longer (sum of difficulty is higher). Due to the distribution of blocks, one chain will end up being longer than the other and Bitcoin core will change its blockchain to the other one.

[hhanh00]

Let's say a node is synced up to block #100 and receives a chain from #90 to #100 that claims to be better. But in fact, in the block #95, there is a double spend (from a txo created in #91 of the new fork) that makes #95 to #100 invalid.
However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

What do you mean by "block #95, there is a double spend"? The blockchain does not allow double spends.

For reorgs, AFAIK Bitcoin Core goes with the chain it receives first unless the other chain is longer (sum of difficulty is higher). Due to the distribution of blocks, one chain will end up being longer than the other and Bitcoin core will change its blockchain to the other one.

The question relates to the block validation code itself. Basically, I'm asking how a node detects a problem in blocks that are sent from a peer. In this scenario, a peer has given a block that contains a double spend.

[achow101]

Let's say a node is synced up to block #100 and receives a chain from #90 to #100 that claims to be better. But in fact, in the block #95, there is a double spend (from a txo created in #91 of the new fork) that makes #95 to #100 invalid.
However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

What do you mean by "block #95, there is a double spend"? The blockchain does not allow double spends.

For reorgs, AFAIK Bitcoin Core goes with the chain it receives first unless the other chain is longer (sum of difficulty is higher). Due to the distribution of blocks, one chain will end up being longer than the other and Bitcoin core will change its blockchain to the other one.

The question relates to the block validation code itself. Basically, I'm asking how a node detects a problem in blocks that are sent from a peer. In this scenario, a peer has given a block that contains a double spend.

So you mean an input was spent in a transaction confirmed in Block #91 and another transaction was confirmed in block 95 that spends that same input?

So in that case, the transaction would be rendered invalid since its input was already spent. Since that transaction is invalid, the whole block becomes invalid and thus is not accepted by Bitcoin Core or any other client since it violates the consensus rules

[hhanh00]

Thanks for taking the time to help but my question is not about "what" it should do. I mentioned it in the original post.

However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

It's about how the different implementations (specially bitcoin core) do it.

[achow101]

Thanks for taking the time to help but my question is not about "what" it should do. I mentioned it in the original post.

However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

It's about how the different implementations (specially bitcoin core) do it.

Well that will involve code digging that I don't want to do now (maybe at a later date) but here are some docs: https://dev.visucore.com/bitcoin/doxygen/ that will be useful for you (or whoever else) that wants to take a look to find this. My guess would be that it is under the CBlock or CChain classes or something related to those.

[TierNolan]

Let's say a node is synced up to block #100 and receives a chain from #90 to #100 that claims to be better. But in fact, in the block #95, there is a double spend (from a txo created in #91 of the new fork) that makes #95 to #100 invalid.
However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

I wonder how bitcoin core (and the alternate implementations) handle this case.

It downloads the header chain first.  Once it receives the new #90 to #100 headers, it will recognize the need for a re-org.

It the disconnects #100 back to #90, one at a time.  This causes an update to the UTXO set.  Each block is stored on the disk, but it also includes "undo" info that allows the disconnect to revert the changes made to the UTXO set by including that block.

Once it has disconnected #90, it will be back to the state from before that fork (#90 - #100) was used.

It then starts connecting the new #90 and onwards.  Once it hits #95, the ConnectTip function will fail to connect the new block due to the double spend.  This causes it to blacklist the block (RAM only, I think).  This means that it will ignore those headers from that point onward.  This prevents it switching over and back between forks.

If the new #94 has higher work than the old #100, it doesn't need to do anything more.  That block is the longest chain.  Miners will eventually extend that chain with an even newer #95.  Normally though, #100 would have higher work than #95, unless the forks cross a difficulty adjustment.