<p>The <code>getheaders</code> message allows you to list multiple block hashes. So instead of just putting the current chain tip, you can insert multiple block hashes. Responding nodes will see if any of those hashes are in its main chain and start sending headers from there. Since reorgs tend to be small, you could put the most recent 10 block hashes and it should be enough to handle the reorg.</p>
<p>Note that the maximum number of hashes you can put in a <code>getheaders</code> message is 101.</p>

CC BY-SA 4.0
2020-08-04T22:59:09.003Z
Awesome, this seems to fix the issue!
benthecarman
CC BY-SA 4.0
2020-08-04T22:51:09.563Z
2020-08-04T22:51:09.563Z
Ava Chow
<p>I work on <a href="https://github.com/bitcoin-s/bitcoin-s" rel="nofollow noreferrer">bitcoin-s</a>, and we've found a problem where if a node is stopped with it's chain tip being a one that is later reorged out it will not be able to continue syncing headers.</p>
<p>This happens because we request headers using a get headers message with hashes= <code>&lt;current chain tip&gt;</code> and stopHash=<code>&lt;00000..0000&gt;</code>. Since, our chain tip is reorged out we will receive the first 2000 block headers of the network.</p>
<p>My current solution is to walk back our chain tip, and each iteration check if don't get the first 2k blocks. However, I recognize this is a poor solution, is there a <code>GetHeadersMessage</code> that I should be using here, or a better alternative?</p>
<p>Thanks</p>

<block-header><chain-reorganization><p2p>
What is the proper way to handle reorgs when fetching headers
benthecarman
# What is the proper way to handle reorgs when fetching headers

(Asked by: username_0 on 2020-08-04)

I work on [bitcoin-s](https://github.com/bitcoin-s/bitcoin-s), and we've found a problem where if a node is stopped with it's chain tip being a one that is later reorged out it will not be able to continue syncing headers.

This happens because we request headers using a get headers message with hashes= `<current chain tip>` and stopHash=`<00000..0000>`. Since, our chain tip is reorged out we will receive the first 2000 block headers of the network.

My current solution is to walk back our chain tip, and each iteration check if don't get the first 2k blocks. However, I recognize this is a poor solution, is there a `GetHeadersMessage` that I should be using here, or a better alternative?

Thanks

**Tags:** block-header, chain-reorganization, p2p


---

## 1 answers

### Answer by username_1 on 2020-08-04. Score: 3 | Accepted answer

The `getheaders` message allows you to list multiple block hashes. So instead of just putting the current chain tip, you can insert multiple block hashes. Responding nodes will see if any of those hashes are in its main chain and start sending headers from there. Since reorgs tend to be small, you could put the most recent 10 block hashes and it should be enough to handle the reorg.

Note that the maximum number of hashes you can put in a `getheaders` message is 101.

> **Comments:**
> **username_0**: Awesome, this seems to fix the issue!  

---

