<p>Blockchain is built to have each block linked to the previous, as a result of; the hash in C has every information from B to duplicate that of C to D and D to E. To update the blockchain, care fully compare the time stamp and the information recorded in the Block E. Any discrepancies in Timestamp or recorded transaction would mean a tamper. The system won’t recognize such transaction. </p>

CC BY-SA 4.0
2019-05-06T22:45:02.637Z
2019-05-06T22:45:02.637Z
Klin nonso
<blockquote>
  <p>Will the miner simply ignore that block?</p>
</blockquote>

<p>Yes, the block will be just ignored by the miner.</p>

<blockquote>
  <p>how will the miner update to A-B-C-D-E (step by step)?</p>
</blockquote>

<p>When the miner's node gets online and start connecting to peers, it will start a “handshake” by transmitting a <code>version</code> message, which contains all basic identifying information, including <code>BestHeight</code> (the blockchain height of the node). Since v0.10, the nodes sync with 'headers-first'. This means that the nodes when restarted first ask peers for block headers and validate those. The <code>getheaders</code> message requests a headers message that provides block headers starting from a particular point in the blockchain. The connected peers will respond with a <code>headers</code> message that sends block headers to the node which requested certain headers with a <code>getheaders</code> message. The disconnected miner's node will then verify the difficulty until the tip. This allows a peer which has been disconnected to get the headers it hasn’t seen yet. </p>

<p>In a second stage, when the headers have been discovered, the node can then download the blocks. However, as the node already know about the whole chain in advance due to the block headers it has received, the blocks can be downloaded in parallel from all available peers. These blocks are received through <code>getdata</code> requests.</p>

<p>The above process describes the syncing of node when it was disconnected for some time. To make the answer more complete, I'll expand a bit further as to how new transactions and blocks are broadcasted. Nodes unsolicitedly transmits <code>inv</code> message (inventory message) containing one or more inventories of objects known to the transmitting peer. It can be sent to announce new transactions or blocks. The receiving peer can then compare the inventories from an <code>inv</code> message against the inventories it has already seen, and then use a follow-up <code>getdata</code> message to request unseen objects.</p>

CC BY-SA 4.0
2019-05-08T01:41:53.910Z
Good answer, but there is one amendment I'd like to propose: I believe that the synchronizing node will first get all the blockheaders leading up to the best chain-tip to verify its total difficulty, then retrieve the remaining block data. Ever since header-first propagation, orphan blocks as mentioned by the asker are essentially not occurring anymore.
Murch
CC BY-SA 4.0
2019-05-08T06:47:35.070Z
@Murch I think I have the same process. Get block headers through `inv` and then retrieve data through `getdata` command. I think I only need to add about verifying total difficulty. Does that sound fair or I'm missing something?
Ugam Kamat
CC BY-SA 4.0
2019-05-08T16:02:46.503Z
Right, but your text currently says it gets the only the hashes. It gets the complete headers, though. The headers are enough to check the links in the chain of blocks and the difficulty. That means that some attacks (like long low difficulty chaintips that end up not being the best chaintip) can be identified early, before the heavy lifting of actually validating the full block content is done.
Murch
CC BY-SA 4.0
2019-05-08T16:12:04.633Z
@Murch  Ah right! That was my bad. Read it before having my morning coffee. I'll incorporate it in my answer.
Ugam Kamat
CC BY-SA 4.0
2019-05-09T09:08:19.400Z
@Murch Looks like things had changed pretty dramatically since v0.10. I had read a previous version of sync process. It seems `getblocks` request is rarely used. I have revamped my answer. Feel free to edit if you notice a goof-up on my part.
Ugam Kamat
CC BY-SA 4.0
2019-05-07T06:05:31.363Z
2019-05-09T09:07:00.160Z
2019-05-09T09:07:00.160Z
Ugam Kamat
<p>Suppose the following:</p>

<ol>
<li>A miner has stored the current blockchain A-B-C.</li>
<li>It stops listening for blocks during some time.</li>
<li>During that time, blocks D and E are mined and broadcasted.</li>
<li>The miner reconnects and immediately listens to the block E, before even knowing about D. </li>
</ol>

<p>Will the miner simply ignore that block? And, how will the miner update to A-B-C-D-E (step by step)?</p>

<blockchain><synchronization><relay><orphaned-blocks>
What happens if a miner receives a block but not its previous?
Carlos Pinzón
# What happens if a miner receives a block but not its previous?

(Asked by: username_0 on 2019-05-06)

Suppose the following:

1. A miner has stored the current blockchain A-B-C.
2. It stops listening for blocks during some time.
3. During that time, blocks D and E are mined and broadcasted.
4. The miner reconnects and immediately listens to the block E, before even knowing about D.

Will the miner simply ignore that block? And, how will the miner update to A-B-C-D-E (step by step)?

**Tags:** blockchain, synchronization, relay, orphaned-blocks


---

## 2 answers

### Answer by username_2 on 2019-05-07. Score: 5 | Accepted answer

> Will the miner simply ignore that block?

Yes, the block will be just ignored by the miner.

> how will the miner update to A-B-C-D-E (step by step)?

When the miner's node gets online and start connecting to peers, it will start a “handshake” by transmitting a `version` message, which contains all basic identifying information, including `BestHeight` (the blockchain height of the node). Since v0.10, the nodes sync with 'headers-first'. This means that the nodes when restarted first ask peers for block headers and validate those. The `getheaders` message requests a headers message that provides block headers starting from a particular point in the blockchain. The connected peers will respond with a `headers` message that sends block headers to the node which requested certain headers with a `getheaders` message. The disconnected miner's node will then verify the difficulty until the tip. This allows a peer which has been disconnected to get the headers it hasn’t seen yet.

In a second stage, when the headers have been discovered, the node can then download the blocks. However, as the node already know about the whole chain in advance due to the block headers it has received, the blocks can be downloaded in parallel from all available peers. These blocks are received through `getdata` requests.

The above process describes the syncing of node when it was disconnected for some time. To make the answer more complete, I'll expand a bit further as to how new transactions and blocks are broadcasted. Nodes unsolicitedly transmits `inv` message (inventory message) containing one or more inventories of objects known to the transmitting peer. It can be sent to announce new transactions or blocks. The receiving peer can then compare the inventories from an `inv` message against the inventories it has already seen, and then use a follow-up `getdata` message to request unseen objects.

> **Comments:**
> **username_3**: Good answer, but there is one amendment I'd like to propose: I believe that the synchronizing node will first get all the blockheaders leading up to the best chain-tip to verify its total difficulty, then retrieve the remaining block data. Ever since header-first propagation, orphan blocks as mentioned by the asker are essentially not occurring anymore.  
> **username_2**: @username_3 I think I have the same process. Get block headers through `inv` and then retrieve data through `getdata` command. I think I only need to add about verifying total difficulty. Does that sound fair or I'm missing something?  
> **username_3**: Right, but your text currently says it gets the only the hashes. It gets the complete headers, though. The headers are enough to check the links in the chain of blocks and the difficulty. That means that some attacks (like long low difficulty chaintips that end up not being the best chaintip) can be identified early, before the heavy lifting of actually validating the full block content is done.  
> **username_2**: @username_3  Ah right! That was my bad. Read it before having my morning coffee. I'll incorporate it in my answer.  
> **username_2**: @username_3 Looks like things had changed pretty dramatically since v0.10. I had read a previous version of sync process. It seems `getblocks` request is rarely used. I have revamped my answer. Feel free to edit if you notice a goof-up on my part.  

---

### Answer by username_1 on 2019-05-06. Score: -2

Blockchain is built to have each block linked to the previous, as a result of; the hash in C has every information from B to duplicate that of C to D and D to E. To update the blockchain, care fully compare the time stamp and the information recorded in the Block E. Any discrepancies in Timestamp or recorded transaction would mean a tamper. The system won’t recognize such transaction.


---

