<p>First to clarify:<br>
Two competing blocks at the <strong>same height</strong> that build on the <strong>same parent block</strong> always have the <strong>same amount of proof of work</strong>, as that depends on the difficulty, which will be the same for both competitors.</p>

<p>Thus, a chain reorganization will only occur in practice if a competing chain tip pulls ahead of a previously accepted chain tip by accumulating a greater length.<sup>*</sup></p>

<p>Bitcoin Core stores competing blocks it receives as a sidebranch, if the headers would potentially make it the best chain. Otherwise it discards them.</p>

<p>When chain reorganization occurs, Bitcoin Core will undo each block from the tip one at a time, reverting back to the common ancestor with the new best chain, then will apply the blocks in the new best chain one at a time until it is at the new tip.</p>

<p><sup>* It is possible to construct a case around a difficulty change where competing chain tips have different difficulties at the same height. Then, the one with the higher difficulty would replace the one with lower difficulty at the same height. However, that would require a chain split of more than one block length.</sup></p>

CC BY-SA 4.0
2015-01-01T11:45:45.630Z
2019-04-22T02:21:57.703Z
2019-04-22T02:21:57.703Z
Murch
<p>When the client receives conflicting blockchains, the chain with the higher overall work will "win" and be the one that node A considers the true chain. If the two chains are equal (e.g. because two miners found a block at about the same time), it will hold on to both until it sees a new block on one of the chains make it the best chain. In the example you described, this is called a <a href="https://en.bitcoin.it/wiki/Chain_Reorganization" rel="nofollow">chain reorganization</a>.</p>

<p>I'm not familiar enough with the source code to tell you exactly <em>how</em> it does this, but it's apparent that it does. I would assume that it does remove an orphaned chain's blocks from the disk once it knows it's orphaned.</p>

CC BY-SA 3.0
2014-12-02T04:28:11.097Z
Hi Tim,Thank your answer. I think processing block is a serial not parallel.One node must process one by one and increment its mainchain height.  So if there are two same height new blocks(A and B), nodes would store the block that the node first get(A) and add its height by 1. when the node found B, its mainchain height is already higher than block B, so it won't accept B. But if some time later the node found a chain is longer than its mainchain and the chain maybe is forked by B, the node will reorganize.  My point is the node won't hold on both the same height blocks. Am I right?
Eleven
CC BY-SA 3.0
2014-12-01T21:58:11.980Z
2014-12-01T21:58:11.980Z
Tim S.
<p>Node A receives a newest block with height <code>h1</code>, which it determines to be valid, and therefore stores the block on disk. A little later, it receives another block with the same height <code>h1</code> but a greater amount of proof of work than the previous one. What would node A do? </p>

<p>Also I am confused about the order of processing a new block. The order in the source code:</p>

<pre><code>              success                          success
Check(block)-----------&gt;store block on disk------------------&gt;ReceivedBlockTransaction--------&gt;ActivateBestChain
</code></pre>

<p>If <code>ReceivedBlockTransaction</code> or <code>ActivateBestChain</code> were to fail, would the disk be rolled back or not? If it would rollback, why not put the <code>receivedBlockTransaction</code> and <code>ActivateBestchain</code> before <code>store block on disk</code>?</p>

<block><chain-reorganization><best-chain>
In what order do new blocks get processed?
Eleven
# In what order do new blocks get processed?

(Asked by: username_0 on 2014-12-01)

Node A receives a newest block with height `h1`, which it determines to be valid, and therefore stores the block on disk. A little later, it receives another block with the same height `h1` but a greater amount of proof of work than the previous one. What would node A do?

Also I am confused about the order of processing a new block. The order in the source code:

```
              success                          success
Check(block)----------->store block on disk------------------>ReceivedBlockTransaction-------->ActivateBestChain

```

If `ReceivedBlockTransaction` or `ActivateBestChain` were to fail, would the disk be rolled back or not? If it would rollback, why not put the `receivedBlockTransaction` and `ActivateBestchain` before `store block on disk`?

**Tags:** block, chain-reorganization, best-chain


---

## 2 answers

### Answer by username_1 on 2015-01-01. Score: 2

First to clarify:  
Two competing blocks at the **same height** that build on the **same parent block** always have the **same amount of proof of work**, as that depends on the difficulty, which will be the same for both competitors.

Thus, a chain reorganization will only occur in practice if a competing chain tip pulls ahead of a previously accepted chain tip by accumulating a greater length.\*

Bitcoin Core stores competing blocks it receives as a sidebranch, if the headers would potentially make it the best chain. Otherwise it discards them.

When chain reorganization occurs, Bitcoin Core will undo each block from the tip one at a time, reverting back to the common ancestor with the new best chain, then will apply the blocks in the new best chain one at a time until it is at the new tip.

\* It is possible to construct a case around a difficulty change where competing chain tips have different difficulties at the same height. Then, the one with the higher difficulty would replace the one with lower difficulty at the same height. However, that would require a chain split of more than one block length.


---

### Answer by username_2 on 2014-12-01. Score: 1

When the client receives conflicting blockchains, the chain with the higher overall work will "win" and be the one that node A considers the true chain. If the two chains are equal (e.g. because two miners found a block at about the same time), it will hold on to both until it sees a new block on one of the chains make it the best chain. In the example you described, this is called a [chain reorganization](https://en.bitcoin.it/wiki/Chain_Reorganization).

I'm not familiar enough with the source code to tell you exactly *how* it does this, but it's apparent that it does. I would assume that it does remove an orphaned chain's blocks from the disk once it knows it's orphaned.

> **Comments:**
> **username_0**: Hi Tim,Thank your answer. I think processing block is a serial not parallel.One node must process one by one and increment its mainchain height.  So if there are two same height new blocks(A and B), nodes would store the block that the node first get(A) and add its height by 1. when the node found B, its mainchain height is already higher than block B, so it won't accept B. But if some time later the node found a chain is longer than its mainchain and the chain maybe is forked by B, the node will reorganize.  My point is the node won't hold on both the same height blocks. Am I right?  

---

