getheaders does not handle sidechains correctly at all

[jrick]

Noticed when working on #426.

getheaders (either wire protocol or the new RPC version) does not behave as expected wrt the stop hash and the first located block. Our code is looking up the heights of these two blocks, and then returning blocks on the main chain until the max is reached or the height of the stop hash is reached (but not the stop block itself). This can result in a couple weird behaviors:

• If the stop hash is not on the main chain, getheaders will stop providing you headers when you reach that height, even when it has been providing headers on the main chain, and there may still be even more main chain headers to provide.
• If the first located block is not on the main chain, it will still start providing headers from the main chain instead of headers on the side chain.

For reference, bitcoin core only provides headers on the main chain, up until the stop hash is seen. If the stop hash is not encountered on the main chain, then it will continue to provide more main chain headers. If the first located block is on a side chain, it will actually go back and return headers starting at the fork point between the main chain and that side chain.

https://github.com/bitcoin/bitcoin/blob/53133c1c041d113c2a480a18e6ff38681d135dca/src/main.cpp#L5425

[jrick]

This is an upstream issue that also affects btcd.

[jrick]

Just a reminder, the "patch" version for the JSON-RPC server API needs to be bumped once this has been fixed. I currently have code in wallet to workaround this bug but it needs to be eventually removed, and wallet will need to check that the dcrd RPC server's API is compatible with that removal.