Merge #16974: Walk pindexBestHeader back to ChainActive().Tip() if it is invalid

0a50019fde7781263e0c8f041d1d9dcb0dee77e8 Walk pindexBestHeader back to ChainActive().Tip() if it is invalid (Matt Corallo)

Pull request description:

  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.

ACKs for top commit:
  fjahr:
    ACK 0a50019fde7781263e0c8f041d1d9dcb0dee77e8
  kallewoof:
    ACK 0a50019fde7781263e0c8f041d1d9dcb0dee77e8
  ariard:
    utACK 0a50019

Tree-SHA512: 2ecfa973a9878a00313ae7ede94a9bd7710e0caf55b544b10bbc46dc463a0478cbaf477e6cdd072356d5a0c5fb3848e9339284af785a2995c20bae8bd23f23e5

0 files changed, 0 insertions, 0 deletions