Downloading headers from peers which are bootstrapping. #6861

Core will send a getheaders message to every peer it connects to. Should a peer respond with the first 2000 headers, Core will begin to download the headers chain from scratch, despite already having these. This is particularly strange while in parallel, the fresh peer may also be actively downloading blocks from the fully synced node.

This check is what causes it to redownload the chain: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L4434 I worry about this, since incoming peers can also trigger this - and only have to have the first 2000 headers for it to work.

So I'm wondering if there's a reason or if it's a bug. I thought headers messages started at the next best header in the main chain? Can we simply disregard a headers message that doesn't start with an unknown header?

The getheaders message we send to our peers uses a block locator calculated from pindexBestHeader.

Our peers, upon receving a getheaders message, should only return headers starting at the latest fork point between their tip and the tip of our locator. So in the normal case, our peers wouldn't respond to a getheaders message by starting at block 1. However, I think it is possible for a new node starting up to get an inv from a peer while its syncing the headers chain from one of its peers, and before pindexBestHeader is very far along. In that situation I would expect that you could end up downloading most or all of the headers chain from two different peers at the same time. This is similar to what is reported in #6755.

There is a comment in the code just below the line you linked, which is to continue from pindexBestHeader or chainActive.Tip() if the last header they send us is an ancestor of one of those. Come to think of it, that might go a long way towards mitigating the issue in #6755.

Also it's not okay to disregard a headers message that doesn't start with an unknown header -- if our peer is behaving properly, they might well send us a header we already have, if our chain tip happened to be on a different fork at the time we sent them a getheaders message, which didn't include the header in question. So it's possible for a valid headers message that would help us get to a more-work chain could start from a header that we already know about.

Closing and pushing future discussions to #6755 around duplicate getheaders requests.