> Instead of keeping pindexBestHeader set to the best header we've
> ever seen, reset it back to our validated tip if we find an ancestor
> of it turns out to be invalid. While the name is now a bit confusing,
> this matches much better with how it is used in practice, see below.
> Further, this opens up more use-cases for it in the future, namely
> aggressively searching for new peers in case we have discovered
> (possibly via some covert channel) headers which we do not know to be
> invalid, but which we cannot find block data for.
>
> Places pindexBestHeader is used:
>
> * Various GUI displays of the best header and getblockchaininfo["headers"],
> I don't think changing this is bad, and if anything this is less confusing
> in the presence of an invalid block.
> * IsCurrentForFeeEstimation(): If anything I think ensuring pindexBestHeader
> isn't some crazy invalid chain is better than the alternative, even in the
> case where you are rejecting the current chain due to hardware error (since
> hopefully in that case you won't get any new blocks anyway).
> * ConnectBlock assumevalid checks: We use pindexBestHeader to check that the
> block we're connecting leads to something with nMinimumChainWork (preventing
> a user-set assumevalid from having bogus work) and that the block we're
> connecting leads to pindexBestHeader (I'm not too worried about this one -
> it's nice to "disable" assumevalid if we have a long invalid headers chain,
> but I don't see it as a critical protection).
> * BlockRequestAllowed() uses pindexBestHeader as its target to ensure the
> requested block is within a month of the "current chain". I don't think this
> is a meaningful difference, if we're rejecting the current tip we're
> trivially fingerprintable anyway, and if the chain really does have a bunch
> of invalid crap near the tip, using the best not-invalid header is likely a
> better criteria.
> * ProcessGetBlockData uses pindexBestHeader as the "current chain" definition
> of whether a block request is "historical" for the purpose of bandwidth
> limiting. Similarly, I don't see why this is a meaningful change.
> * We use pindexBestHeader for requesting missing headers on receipt of a
> headers/compact block message or block inv as well as for initial getheaders.
> I think this is definitely wrong, using the best not-invalid header for such
> requests is much better.
> * We use pindexBestHeader to define the "current chain" for deciding when
> we're close to done with initial headers sync. I don't think this is a
> meaningful change.
> * We use pindexBestHeader to decide if initial headers sync has timed out. If
> we're rejecting the chain due to hardware error this may result in
> additional cases where we ban a peer, but this is already true, so I think
> its fine.
This is a backport of Core PR16974