<p>If there are multiple chaintips that match in total work, Bitcoin Core will consider the one it heard first about the best chain. Only if another chaintip accumulates more work, it'll switch to that chaintip. As only one block can be part of the best chain at the same height, the competing block is essentially irrelevant unless it happens to become part of the best chaintip.</p>

<p>Example:<br>
After block 99, there were two competing blocks found at the same time. Our full node first hears about block <code>100A</code> (the asterisk marks the block our full node currently considers the chaintip), and a peer announces chaintip <code>B</code> with a different block at height 100. Bitcoin Core will not update its chaintip, but still consider <code>100A</code> the best chaintip.</p>

<pre><code>           100A*
98 ← 99 ↢
           100B
</code></pre>

<p>It's very unlikely that both <code>100A</code> and <code>100B</code> get a successor block at the same time. Let's say that the chaintip <code>B</code> is extended first.</p>

<pre><code>           100A*
98 ← 99 ↢
           100B ← 101B
</code></pre>

<p>Upon learning about the new best chain, our full node will first revert block <code>100A</code>: all of the transactions that got confirmed in block <code>100A</code> get added back to the mempool and marked unconfirmed.</p>

<pre><code>            100A
98 ← 99* ↢
            100B ← 101B
</code></pre>

<p>Then the full node follows the best chain by applying the two blocks <code>100B</code> and <code>101B</code>.</p>

<pre><code>           100A
98 ← 99 ↢
           100B ← 101B*
</code></pre>

<p>Any transactions that had been confirmed in <code>100A</code> might have now been associated with <code>100B</code> or <code>101B</code> instead, or they may still be in the mempool.</p>

CC BY-SA 4.0
2020-01-08T18:15:27.473Z
2020-01-08T18:15:27.473Z
Murch
<p>SeungJun <a href="https://github.com/bitpay/bitcore/issues/2659" rel="nofollow noreferrer">linked</a> above in a comment to the same question in the <code>bitcore</code> repository that got an answer from micahriggan. The answer states that <code>bitcore</code> removes information about the old block and processes the new block. It also links to the function <a href="https://github.com/bitpay/bitcore/blob/ae536af87a135b7b7d749d517a369be67abebea6/packages/bitcore-node/src/models/block.ts#L141" rel="nofollow noreferrer"><code>handleReorg</code></a> in the code.</p>

CC BY-SA 4.0
2023-10-20T14:25:52.357Z
2023-10-20T14:25:52.357Z
Murch
<p>I know stale blocks can occur naturally when two miners produce blocks at similar times. How is this handled in <code>bitcore</code>?
For example, when a chain reorganization occurs in the node, does <code>bitcore</code> change the <code>blockHeight</code> of transactions in the transactions table?</p>

CC BY-SA 4.0
2020-01-07T17:30:38.070Z
You might be thinking of stale blocks. Orphan blocks have no parents, and don't occur anymore since headers first synchronization.
pinhead
CC BY-SA 4.0
2020-01-07T17:37:42.600Z
Conceptually, every full node only has one "main" chain. There is only one block at each height in that chain.
pinhead
CC BY-SA 4.0
2020-01-08T18:17:06.003Z
Oh, I just realized that you mention `Bitcore`, not `Bitcoin Core`. If that was on purpose, my answer is probably obsolete, because I wrote about Bitcoin Core. Please let me know, then I'll delete it.
Murch
CC BY-SA 4.0
2020-01-10T04:26:55.150Z
Thank you for all response,
I mean orphan block in bitcore. in bitcore repository issue, micahriggan replyed to the question(https://github.com/bitpay/bitcore/issues/2659)
SeungJun
<bitcore><chain-reorganization>
How does bitcore handle transactions in a stale block situation?
SeungJun
# How does bitcore handle transactions in a stale block situation?

(Asked by: username_0 on 2020-01-06)

I know stale blocks can occur naturally when two miners produce blocks at similar times. How is this handled in `bitcore`?
For example, when a chain reorganization occurs in the node, does `bitcore` change the `blockHeight` of transactions in the transactions table?

**Tags:** bitcore, chain-reorganization

> **Comments:**
> **username_1**: You might be thinking of stale blocks. Orphan blocks have no parents, and don't occur anymore since headers first synchronization.  
> **username_1**: Conceptually, every full node only has one "main" chain. There is only one block at each height in that chain.  
> **username_2**: Oh, I just realized that you mention `Bitcore`, not `Bitcoin Core`. If that was on purpose, my answer is probably obsolete, because I wrote about Bitcoin Core. Please let me know, then I'll delete it.  
> **username_0**: Thank you for all response, I mean orphan block in bitcore. in bitcore repository issue, micahriggan replyed to the question(https://github.com/bitpay/bitcore/issues/2659)  

---

## 2 answers

### Answer by username_2 on 2020-01-08. Score: 1

If there are multiple chaintips that match in total work, Bitcoin Core will consider the one it heard first about the best chain. Only if another chaintip accumulates more work, it'll switch to that chaintip. As only one block can be part of the best chain at the same height, the competing block is essentially irrelevant unless it happens to become part of the best chaintip.

Example:  
After block 99, there were two competing blocks found at the same time. Our full node first hears about block `100A` (the asterisk marks the block our full node currently considers the chaintip), and a peer announces chaintip `B` with a different block at height 100. Bitcoin Core will not update its chaintip, but still consider `100A` the best chaintip.

```
           100A*
98 ← 99 ↢
           100B

```

It's very unlikely that both `100A` and `100B` get a successor block at the same time. Let's say that the chaintip `B` is extended first.

```
           100A*
98 ← 99 ↢
           100B ← 101B

```

Upon learning about the new best chain, our full node will first revert block `100A`: all of the transactions that got confirmed in block `100A` get added back to the mempool and marked unconfirmed.

```
            100A
98 ← 99* ↢
            100B ← 101B

```

Then the full node follows the best chain by applying the two blocks `100B` and `101B`.

```
           100A
98 ← 99 ↢
           100B ← 101B*

```

Any transactions that had been confirmed in `100A` might have now been associated with `100B` or `101B` instead, or they may still be in the mempool.


---

### Answer by username_2 on 2023-10-20. Score: 0

username_0 [linked](https://github.com/bitpay/bitcore/issues/2659) above in a comment to the same question in the `bitcore` repository that got an answer from micahriggan. The answer states that `bitcore` removes information about the old block and processes the new block. It also links to the function [`handleReorg`](https://github.com/bitpay/bitcore/blob/ae536af87a135b7b7d749d517a369be67abebea6/packages/bitcore-node/src/models/block.ts#L141) in the code.


---

