<blockquote>
<p>The problem here is that upon receiving block F (its header through header message) we will try to validate its parent hash first and since block E is unknown us, we will consider block F as orphaned and reject it.</p>
</blockquote>
<p>The behavior you describe would make no sense. Nodes obviously must be capable of catching up to chaintips across multiple blocks, e.g. when they were offline for a few hours.</p>
<p>When a node reorgs to a new chaintip, it calculates the <em>forkpoint</em>, i.e. the last shared ancestor block of the two chaintips. It uses the forkpoint to determine the blocks that other peers might be missing. Per peer it then checks against the last block that was announced from that peer and the last block itself announced to the peer, whether the peer might already have some of the blocks. The node then announces the remaining header to the peer if it’s just a few missing blocks. Otherwise, it provides an <code>inv</code> message, which the receiver may reply with a <code>getheaders</code> message to. The <code>getheaders</code> message includes a block locator which is a description of the requester’s best blockchain. The block locator includes the last few block hashes and then an exponentially spaced list of further block hashes that provide the other node with the ability to find a shared ancestor.</p>

CC BY-SA 4.0
2024-01-04T14:02:11.480Z
**Comments have been [moved to chat](https://chat.stackexchange.com/rooms/150642/discussion-on-answer-by-murch-how-is-the-problem-of-orphan-blocks-solved-in-this); please do not continue the discussion here.** Before posting a comment below this one, please review the [purposes of comments](/help/privileges/comment). Comments that do not request clarification or suggest improvements usually belong as an [answer](/help/how-to-answer), on [meta], or in [chat]. Comments continuing discussion may be removed.
Murch
CC BY-SA 4.0
2024-01-04T11:57:43.650Z
2024-01-04T17:28:43.117Z
2024-01-04T17:28:43.117Z
Murch
<p>All nodes are online all the time, they were not offline.</p>
<p>What will happen if some of my peers (blue peers) have their chains as follows:</p>
<pre><code>... -&gt; A -&gt; B -&gt; D  (main chain)
        \-&gt; C
</code></pre>
<p>while my other peers (green peers) and I have the following:</p>
<pre><code>... -&gt; A -&gt; B -&gt; D  (main chain)
</code></pre>
<p>We can get into this situation when the blue peers are connected to some other nodes that considered at some moment chain with the block C as the main. Thus, blue peers received the given block C. However, since for them (blue peers) main chain was the one with B block, they propagated only B to me (and later D), while C was just saved locally as stale block in their stale chain.</p>
<p>Now imagine the following scenario:</p>
<p>1.first comes block E whose parent is C; chains of blue peers looks like this:</p>
<pre><code>... -&gt; A -&gt; B -&gt; D  (main chain)
        \-&gt; C -&gt; E
</code></pre>
<p>In this case blue peers will just increase stale chain and won't propagate E since its not a part of the main chain.</p>
<p>2.then comes block F whose parent is E; chains of blue peers looks like this:</p>
<pre><code>... -&gt; A -&gt; B -&gt; D  
        \-&gt; C -&gt; E -&gt; F (main chain)
</code></pre>
<p>In this case blue peers will switch to chain with F and since that's their new main chain, they will propagate F (header message) to us.</p>
<p>The problem here is that upon receiving block F (its header through header message) we will try to validate its parent hash first and since block E is unknown us, we will consider block F as orphaned and reject it. This way we will consider all future blocks as orphaned and reject it. As a consequence of this we will remain completely isolated in the network (me and all my red peers). Even if we connect to some other networks peers now, the situation would stay the same. How is this solved?</p>

<blockchain-fork><p2p><stale-block><orphaned-blocks>
How is the problem of orphan blocks solved in this case?
Hurry Walk
# How is the problem of orphan blocks solved in this case?

(Asked by: username_0 on 2024-01-04)

All nodes are online all the time, they were not offline.

What will happen if some of my peers (blue peers) have their chains as follows:

```
... -> A -> B -> D  (main chain)
        \-> C

```

while my other peers (green peers) and I have the following:

```
... -> A -> B -> D  (main chain)

```

We can get into this situation when the blue peers are connected to some other nodes that considered at some moment chain with the block C as the main. Thus, blue peers received the given block C. However, since for them (blue peers) main chain was the one with B block, they propagated only B to me (and later D), while C was just saved locally as stale block in their stale chain.

Now imagine the following scenario:

1.first comes block E whose parent is C; chains of blue peers looks like this:

```
... -> A -> B -> D  (main chain)
        \-> C -> E

```

In this case blue peers will just increase stale chain and won't propagate E since its not a part of the main chain.

2.then comes block F whose parent is E; chains of blue peers looks like this:

```
... -> A -> B -> D  
        \-> C -> E -> F (main chain)

```

In this case blue peers will switch to chain with F and since that's their new main chain, they will propagate F (header message) to us.

The problem here is that upon receiving block F (its header through header message) we will try to validate its parent hash first and since block E is unknown us, we will consider block F as orphaned and reject it. This way we will consider all future blocks as orphaned and reject it. As a consequence of this we will remain completely isolated in the network (me and all my red peers). Even if we connect to some other networks peers now, the situation would stay the same. How is this solved?

**Tags:** blockchain-fork, p2p, stale-block, orphaned-blocks


---

## 1 answers

### Answer by username_1 on 2024-01-04. Score: 2

> The problem here is that upon receiving block F (its header through header message) we will try to validate its parent hash first and since block E is unknown us, we will consider block F as orphaned and reject it.

The behavior you describe would make no sense. Nodes obviously must be capable of catching up to chaintips across multiple blocks, e.g. when they were offline for a few hours.

When a node reorgs to a new chaintip, it calculates the *forkpoint*, i.e. the last shared ancestor block of the two chaintips. It uses the forkpoint to determine the blocks that other peers might be missing. Per peer it then checks against the last block that was announced from that peer and the last block itself announced to the peer, whether the peer might already have some of the blocks. The node then announces the remaining header to the peer if it’s just a few missing blocks. Otherwise, it provides an `inv` message, which the receiver may reply with a `getheaders` message to. The `getheaders` message includes a block locator which is a description of the requester’s best blockchain. The block locator includes the last few block hashes and then an exponentially spaced list of further block hashes that provide the other node with the ability to find a shared ancestor.

> **Comments:**
> **username_1**: **Comments have been [moved to chat](https://chat.stackexchange.com/rooms/150642/discussion-on-answer-by-username_1-how-is-the-problem-of-orphan-blocks-solved-in-this); please do not continue the discussion here.** Before posting a comment below this one, please review the [purposes of comments](/help/privileges/comment). Comments that do not request clarification or suggest improvements usually belong as an [answer](/help/how-to-answer), on [meta], or in [chat]. Comments continuing discussion may be removed.  

---

