<p>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. </p>

<p><a href="https://github.com/bitcoin/bitcoin/blob/8d750f1d21d8578794a765415fe9d0e9e74d2852/src/main.cpp#L2049" rel="nofollow">From a look at the source on github</a>, 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.</p>

<p>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. </p>

CC BY-SA 3.0
2013-09-26T23:12:29.030Z
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
CC BY-SA 3.0
2013-09-27T03:29:53.633Z
I have corrected the original answer, thanks.
Anonymous
CC BY-SA 3.0
2014-04-02T01:56:44.840Z
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](https://github.com/bitcoin/bitcoin/blob/8d750f1d21d8578794a765415fe9d0e9e74d2852/src/main.cpp#L2049) which shows how Bitcoin Core steps back through transactions.
XertroV
CC BY-SA 3.0
2014-04-02T08:06:00.043Z
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
CC BY-SA 3.0
2013-09-26T22:27:27.440Z
2014-04-02T08:08:18.260Z
2014-04-02T08:08:18.260Z
Anonymous
<p>Each client can handle a blockchain reorg differently, internally.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2013-08-28T10:47:50.557Z
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
CC BY-SA 3.0
2013-08-27T20:44:20.027Z
2013-08-27T20:44:20.027Z
Stephen Gornick
<p>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.</p>

<p>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?</p>

<blockchain-fork><database><chain-reorganization>
How does a Bitcoin client efficiently change forks?
interfect
# How does a Bitcoin client efficiently change forks?

(Asked by: username_0 on 2013-07-04)

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?

**Tags:** blockchain-fork, database, chain-reorganization


---

## 2 answers

### Answer by username_1 on 2013-09-26. Score: 3 | Accepted answer

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](https://github.com/bitcoin/bitcoin/blob/8d750f1d21d8578794a765415fe9d0e9e74d2852/src/main.cpp#L2049), 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.

> **Comments:**
> **username_2**: 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).  
> **username_1**: I have corrected the original answer, thanks.  
> **username_3**: For those reading username_1'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](https://github.com/bitcoin/bitcoin/blob/8d750f1d21d8578794a765415fe9d0e9e74d2852/src/main.cpp#L2049) which shows how Bitcoin Core steps back through transactions.  
> **username_4**: 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.  

---

### Answer by username_5 on 2013-08-27. Score: 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.

> **Comments:**
> **username_6**: 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.  

---

