7

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?

Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
4
  • 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
    Sep 26, 2013 at 23:12
  • I have corrected the original answer, thanks.
    – Anonymous
    Sep 27, 2013 at 3:29
  • 1
    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
    Apr 2, 2014 at 1:56
  • 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 ♦
    Apr 2, 2014 at 8:06
2

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.

Improve this answer
1
  • 1
    I 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
    Aug 28, 2013 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.