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?



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.

  • Awesome, this seems to fix the issue! Aug 4 '20 at 22:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.