<blockquote>
  <p>If a node X receives first the blockchain from A, and it approves it, when it receives the blockchain from B, it simply reject it ?</p>
</blockquote>

<p>It will keep the block locally as an alternate chain, but not immediately discard it.</p>

<blockquote>
  <p>If a node X receives first then blockchain from A, and then the B's blockchain in which also a node C has put another correct block (so is longer then A's blockchain), does the node X reject A's blockchain (applying the longest chain rule) and use the other blockchain as the correct one ?</p>
</blockquote>

<p>Correct, once any one chain has accumulated more difficulty, the minor chain is discarded.</p>

<p>Note that here accumulated difficulty is a measure of how much hashpower was spent to produce the amount of work required for that chain. This is generally in sync with the chain being longer (a chain with more blocks will have more difficult in most cases), but it is not a guarantee.</p>

<blockquote>
  <p>Due to latency a miner node may not have the complete list of transactions, so it may start to build an incorrect block (for example some transaction misses). If the miner recognize is building an incorrect block (because for example, it received other transactions while it was building the block) it simply throws away the block and start building another one?</p>
</blockquote>

<p>This is really a separate question, but the answer is mostly "ASICs are fast, it doesn't matter". Miners are constantly producing update block templates with altered timestamps, secondary nonces in the coinbase transaction, and transaction lists. These are then passed to the actual machines doing the mining, which can burn through the nonce space in the header in a matter of seconds. A miner will simply wait for the old block template to be non-viable and create a new one with the better transactions.</p>

<p>Of course, if a miner does find a valid block on a slightly out of date template, they will broadcast that block - it makes no sense to give up a guaranteed 12.5 BTC for the possibility of slightly higher fees in a block you might not find before another miner.</p>

CC BY-SA 4.0
2019-11-30T20:11:41.330Z
The rule is most difficult, no longest.
Claris
CC BY-SA 4.0
2019-12-01T00:44:57.283Z
@Anonymous Absolutely, I've updated the answer. Thanks!
Raghav Sood
CC BY-SA 4.0
2019-11-30T11:09:04.877Z
2019-12-01T00:44:47.143Z
2019-12-01T00:44:47.143Z
Raghav Sood
<p>At the same time, A and B succeed in resolving the "Proof of work" challenge and both add a new block to their local blockchain, then they propagate the new blockchains to other nodes. I have 2 questions:</p>

<p>1) If a node X receives first the blockchain from A, and it approves it, when it receives the blockchain from B, it simply reject it ? </p>

<p>2) If a node X receives first then blockchain from A, and then the B's blockchain in which also a node C has put another correct block (so is longer then A's blockchain), does the node X reject A's blockchain (applying the longest chain rule) and use the other blockchain as the correct one ?</p>

<p>2) Due to latency a miner node may not have the complete list of transactions, so it may start to build an incorrect block (for example some transaction misses). If the miner recognize is building an incorrect block (because for example, it received other transactions while it was building the block) it simply throws away the block and start building another one?</p>

<transactions><blockchain><blockchain-fork><best-chain>
Fork and Longest Chain Rule
AleWolf
# Fork and Longest Chain Rule

(Asked by: username_0 on 2019-11-30)

At the same time, A and B succeed in resolving the "Proof of work" challenge and both add a new block to their local blockchain, then they propagate the new blockchains to other nodes. I have 2 questions:

1) If a node X receives first the blockchain from A, and it approves it, when it receives the blockchain from B, it simply reject it ?

2) If a node X receives first then blockchain from A, and then the B's blockchain in which also a node C has put another correct block (so is longer then A's blockchain), does the node X reject A's blockchain (applying the longest chain rule) and use the other blockchain as the correct one ?

2) Due to latency a miner node may not have the complete list of transactions, so it may start to build an incorrect block (for example some transaction misses). If the miner recognize is building an incorrect block (because for example, it received other transactions while it was building the block) it simply throws away the block and start building another one?

**Tags:** transactions, blockchain, blockchain-fork, best-chain


---

## 1 answers

### Answer by username_1 on 2019-11-30. Score: 2

> If a node X receives first the blockchain from A, and it approves it, when it receives the blockchain from B, it simply reject it ?

It will keep the block locally as an alternate chain, but not immediately discard it.

> If a node X receives first then blockchain from A, and then the B's blockchain in which also a node C has put another correct block (so is longer then A's blockchain), does the node X reject A's blockchain (applying the longest chain rule) and use the other blockchain as the correct one ?

Correct, once any one chain has accumulated more difficulty, the minor chain is discarded.

Note that here accumulated difficulty is a measure of how much hashpower was spent to produce the amount of work required for that chain. This is generally in sync with the chain being longer (a chain with more blocks will have more difficult in most cases), but it is not a guarantee.

> Due to latency a miner node may not have the complete list of transactions, so it may start to build an incorrect block (for example some transaction misses). If the miner recognize is building an incorrect block (because for example, it received other transactions while it was building the block) it simply throws away the block and start building another one?

This is really a separate question, but the answer is mostly "ASICs are fast, it doesn't matter". Miners are constantly producing update block templates with altered timestamps, secondary nonces in the coinbase transaction, and transaction lists. These are then passed to the actual machines doing the mining, which can burn through the nonce space in the header in a matter of seconds. A miner will simply wait for the old block template to be non-viable and create a new one with the better transactions.

Of course, if a miner does find a valid block on a slightly out of date template, they will broadcast that block - it makes no sense to give up a guaranteed 12.5 BTC for the possibility of slightly higher fees in a block you might not find before another miner.

> **Comments:**
> **username_2**: The rule is most difficult, no longest.  
> **username_1**: @Anonymous Absolutely, I've updated the answer. Thanks!  

---

