<blockquote>
  <p>ANSWER-2: when B broadcasts his new block, B by default accepts its own generated block (N+1) and immediately start to mine block N+2 upon that (at the time when B has not received A's block yet.) Then B receives A's block (N+1), in this case, B should keep A's chain but still continue to mine at his N+2 block height.</p>
</blockquote>

<p>This is basically correct. B will receive A's block, validate it, and if it is valid, he will store the block. However he will not change his view of the blockchain to include A's block. He merely holds onto A's block just in case more blocks are found on top of it which would then require B to change his view of the blockchain.</p>

<p>B's view of the blockchain will remain with his N + 1 block and continue to mine his N + 2.</p>

<p>In general, when two blocks are found at the same height around the same time, nodes will update their view of the blockchain to include the block which they saw first. The view of the blockchain only changes if there exists a blockchain that has more cumulative work than the one that the node currently sees as the correct blockchain. If the two blockchains have the same cumulative work (i.e. orphan race as described in this question), then the node uses the one it saw first.</p>

CC BY-SA 4.0
2018-11-15T23:30:29.550Z
FWIW, Bitcoin Core won't fetch (much less validate) a block unless it would become the best block if validation passed.
G. Maxwell
CC BY-SA 4.0
2018-11-16T01:02:07.920Z
Or is at least part of a chain whose tip would become the best block if validation passed.
Pieter Wuille
CC BY-SA 4.0
2018-09-13T15:47:25.890Z
2018-09-13T15:47:25.890Z
Ava Chow
<p>Two miners may find a block at pretty much the same time, and so the network may split, with some miners working on top of each of the two blocks.</p>
<p>It is possible, but quite rare, for a miner on each side of the split to then find a block at pretty much the same time again, thus repeating the situation, and the split goes another block deep.</p>
<p>The situation eventually resolves when one side of the split mines a new block before the other side. The network then converges onto the longer (most work) chain, and the other chain is 'orphaned'.</p>
<blockquote>
<p>i have 2 possible answers but not sure which one is correct, or neither. (assuming all TX/UTXO in the block has no issue)</p>
<p>ANSWER-1: B will discard B's block, and accept A's, because B block's timestamp is older than A's (make sense?)</p>
</blockquote>
<p>No, timestamps are not used to decide which block is kept.</p>
<blockquote>
<p>ANSWER-2: when B broadcasts his new block, B by default accepts its own generated block (N+1) and immediately start to mine block N+2 upon that (at the time when B has not received A's block yet.) Then B receives A's block (N+1), in this case, B should keep A's chain but still continue to mine at his N+2 block height.</p>
</blockquote>
<p>B will not necessarily keep the chain, but B will continue to mine on B's N+1 block.</p>

CC BY-SA 4.0
2018-09-13T11:09:22.127Z
2018-09-13T11:09:22.127Z
2020-06-16T11:10:03.350Z
chytrik
<p>It comes to my curiousity about how exactly the node A will mine block N+1 when he &amp; node B generated block N (not in same time but) in a fairly close timeframe.</p>

<p>In many articles, it says that when 2 nodes (A&amp;B) are generating the same height block at same time, it will cause a fork. This means some nodes will mine after A's new block and others mine B's. This is understood. However, it will take time when A's new block sync to B. Let's assume it takes 10 seconds to pass to B. In the middle of the sync (saying 5th or 6th second of total 10), B just generates the new block (with same height), and propagate it out before receiving A's block. What will happen when B receives A's block then?</p>

<p>I have 2 possible answers but not sure which one is correct, or neither.
(assuming all TX/UTXO in the block has no issue)</p>

<p>ANSWER-1: B will discard B's block, and accept A's, because B block's timestamp is older than A's (make sense?)</p>

<p>ANSWER-2: when B broadcasts his new block, B by default accepts its own generated block (N+1) and immediately start to mine block N+2 upon that (at the time when B has not received A's block yet.) Then B receives A's block (N+1), in this case, B should keep A's chain but still continue to mine at his N+2 block height.</p>

<p>Any advice?</p>

<stale-block>
Stale block verification at node level
user87441
# Stale block verification at node level

(Asked by: username_0 on 2018-09-13)

It comes to my curiousity about how exactly the node A will mine block N+1 when he & node B generated block N (not in same time but) in a fairly close timeframe.

In many articles, it says that when 2 nodes (A&B) are generating the same height block at same time, it will cause a fork. This means some nodes will mine after A's new block and others mine B's. This is understood. However, it will take time when A's new block sync to B. Let's assume it takes 10 seconds to pass to B. In the middle of the sync (saying 5th or 6th second of total 10), B just generates the new block (with same height), and propagate it out before receiving A's block. What will happen when B receives A's block then?

I have 2 possible answers but not sure which one is correct, or neither.
(assuming all TX/UTXO in the block has no issue)

ANSWER-1: B will discard B's block, and accept A's, because B block's timestamp is older than A's (make sense?)

ANSWER-2: when B broadcasts his new block, B by default accepts its own generated block (N+1) and immediately start to mine block N+2 upon that (at the time when B has not received A's block yet.) Then B receives A's block (N+1), in this case, B should keep A's chain but still continue to mine at his N+2 block height.

Any advice?

**Tags:** stale-block


---

## 2 answers

### Answer by username_1 on 2018-09-13. Score: 1

> ANSWER-2: when B broadcasts his new block, B by default accepts its own generated block (N+1) and immediately start to mine block N+2 upon that (at the time when B has not received A's block yet.) Then B receives A's block (N+1), in this case, B should keep A's chain but still continue to mine at his N+2 block height.

This is basically correct. B will receive A's block, validate it, and if it is valid, he will store the block. However he will not change his view of the blockchain to include A's block. He merely holds onto A's block just in case more blocks are found on top of it which would then require B to change his view of the blockchain.

B's view of the blockchain will remain with his N + 1 block and continue to mine his N + 2.

In general, when two blocks are found at the same height around the same time, nodes will update their view of the blockchain to include the block which they saw first. The view of the blockchain only changes if there exists a blockchain that has more cumulative work than the one that the node currently sees as the correct blockchain. If the two blockchains have the same cumulative work (i.e. orphan race as described in this question), then the node uses the one it saw first.

> **Comments:**
> **username_2**: FWIW, Bitcoin Core won't fetch (much less validate) a block unless it would become the best block if validation passed.  
> **username_3**: Or is at least part of a chain whose tip would become the best block if validation passed.  

---

### Answer by username_4 on 2018-09-13. Score: 0

Two miners may find a block at pretty much the same time, and so the network may split, with some miners working on top of each of the two blocks.

It is possible, but quite rare, for a miner on each side of the split to then find a block at pretty much the same time again, thus repeating the situation, and the split goes another block deep.

The situation eventually resolves when one side of the split mines a new block before the other side. The network then converges onto the longer (most work) chain, and the other chain is 'orphaned'.

> i have 2 possible answers but not sure which one is correct, or neither. (assuming all TX/UTXO in the block has no issue)
>
> ANSWER-1: B will discard B's block, and accept A's, because B block's timestamp is older than A's (make sense?)

No, timestamps are not used to decide which block is kept.

> ANSWER-2: when B broadcasts his new block, B by default accepts its own generated block (N+1) and immediately start to mine block N+2 upon that (at the time when B has not received A's block yet.) Then B receives A's block (N+1), in this case, B should keep A's chain but still continue to mine at his N+2 block height.

B will not necessarily keep the chain, but B will continue to mine on B's N+1 block.


---

