What is the proper way to handle reorgs when fetching headers


I work on 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?



Posted 2020-08-04T22:33:27.660

Reputation: 63



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.

Andrew Chow

Posted 2020-08-04T22:33:27.660

Reputation: 50 267

Awesome, this seems to fix the issue! – benthecarman – 2020-08-04T22:59:09.003