How does a Bitcoin client efficiently change forks?

Occasionally, a Bitcoin client will come across a fork of blocks that is longer than the chain it is currently on. Depending on how often orphaned blocks occur, this could be quite often. When this happens, any internal data structures relating to the "current" state of the blockchain (for example, a hashtable of unspent outputs) need to be updated to reflect the state of the new, longer fork.

How is this accomplished? Is history played "backwards" to the most recent common ancestor and then "forwards" to the new top block? Is it all just reconstructed from scratch?

interfect

Posted 2013-07-04T06:51:57.653

Reputation: 243

Answers

The UXTO set certainly isn't reconstructed from scratch, that would be an incredible DoS vector if it did. Even on fast machines a complete reconstruction takes hours, days on slower disks and processors.

From a look at the source on github, we can see that your assumption is correct. The UXTO set is reconstructed backwards to the point where the chain is forked, and then continues on down it as normal.

The client seems to assume that large (100+) reorganisations of the blocks are improbable, which is why coins need to "mature" to avoid the situation where there's transactions spending coins that no longer exist in the chain.

Anonymous

Posted 2013-07-04T06:51:57.653

Reputation: 891

Large reorganisations aren't assumed to be impossible, but they would certainly have a terrible effect if they occurred, as any transaction (recursively) that spends the coins generated in the reorganized chain will inevitable become invalid (and since the coinbases they originate from disappear, these cannot just be moved to the other chain, like other transactions in a reorganisations). – Pieter Wuille – 2013-09-26T23:12:29.030

I have corrected the original answer, thanks. – Anonymous – 2013-09-27T03:29:53.633

For those reading Anonymous's answer above, and noticed that his link to the Bitcoin source now points to something completely different (master has changed since then), the original reference was to this line which shows how Bitcoin Core steps back through transactions.

– XertroV – 2014-04-02T01:56:44.840

Thanks. However, we do have a workflow for that: You can just click "edit" and correct a mistake, it will then be added to a review queue automatically. – Murch – 2014-04-02T08:06:00.043

Each client can handle a blockchain reorg differently, internally.

The Bitcoin-Qt reference client simply uses the longest chain and rejects any competing blocks at the same height. So until there is a new block that is longer than the chain the client is already working on, competing chains that are not of a greater height are essentially ignored.

But if a block reorg occurs any transactions in those blocks that get reorged will first go back into the client's memory pool before blocks for the new longest chain are processed.

This can cause a transaction to have had at least one confirmation but then revert to having no confirmations (or a lower number of confirmations) after the reorg if the new longest chain didn't include that transaction.

Stephen Gornick

Posted 2013-07-04T06:51:57.653

Reputation: 26 118

1I believe the question was more about how do they undo the state of UTXO database. I believe there needs to be some kind of a history buffer, so the s/w is able to put back the UTXO records that got "spent" (removed from UTXO db) while processing a block that eventually gets orphaned when a different branch of a fork takes over it. – Gigi – 2013-08-28T10:47:50.557