Ignore getheaders prior to passing all checkpoints. #9061

An improvement over #6172. Fixes #6971 rather than bypasses it as #6974 did, and reduces overloading of whitelisting.

Would it be better to use chain work here too? (ref #9053)

@dcousens A nice idea, but this change is to fix the concerns raised here: #5927 (comment) which requires it to be linked to the last checkpoint. For some reason additional criteria got added too that made it too strict.

Instead of adding more reliance on checkpoints, we should be getting rid of them (see #7591). @gmaxwell has work in progress to do this (#9053 is part of that).

NAK. No more reliance on checkpoints. Also-- IsInitialBlockDownload does a fine job here AFAIK-- this is literally its job (esp with my changes that are less likely to let it get tripped up on testnet with headers forked).

Needs rebase, if still relevant.

@laanwj This PR does not add more reliance on checkpoints, as the previous code also used checkpoints.

@rebroad Please, this is not an argument.

Because something was done in the past does not mean it is correct and encouraged forever. Often we keep code that works (but relies on bad pratices) because no one found time to fix it... I don't see a way where we restore the checkpoint functionality you are referencing in this pull.

@MarcoFalke A step in the right direction while waiting for a better solution is surely better than standing still while waiting for a better solution.

And in response to @gmaxwell https://botbot.me/freenode/bitcoin-core-dev/msg/75840350/ - this PR reduces the DoS effect you refer to - i.e. it ignores FEWER getheaders than previously.

However I do agree that ignoring getheaders is not ideal - I believe the node should disconnect when it decides to ignore a getheaders request. I didn't add this though, as it wasn't already in the code, for some reason I do not understand.

I think there must be some reality distortion going on here. I honestly have zero idea why this PR is not a quick and easy improvement and it introduces zero debt.

What are your real reasons for not merging this? There is a undisclosed agenda here I think, which clearly (to me at least) is not in the best interests of the P2P protocol.