multi: Rework old fork rejection logic.

[davecgh]

This requires #2942 and #2943.

Historically, checkpoints have been manually specified and used both for various optimizations and to protect against cheap DoS attacks by rejecting forks deep in history. The primary motivation for manually specifying the checkpoints was said optimizations, however, those optimization portions have now been decoupled from checkpoints in favor of other methods, so the only remaining use of checkpoints is the aforementioned rejection of forks deep in history.

Thus, this reworks the old fork rejection logic to make it automatic based on an ancestor that is two weeks worth of blocks behind the hard-coded assumevalid block (clamped to the genesis block if necessary) that is manually specified at each release as opposed to needing to additionally manually specify checkpoints.

Note the distinction here between the hard-coded assumevalid block specified at each release and the potentially overridden value specified by a user via CLI configuration options. This is an important distinction because old fork rejection affects consensus and thus must not move around based on user configuration.

This approach means the user can still specify a more recent assume valid hash or disable assume valid optimizations independently without affecting the consensus logic while still removing the need to manually specify additional checkpoints.

The changes have been split into multiple commits to help ease review.

The following is a high level overview of the changes:

• Removes the findcheckpoints utility
• Caches the number of expected blocks in two weeks for the network to avoid repeated calculation
• Modifies the blockchain.Config struct as follows:
  • Removes the LastestCheckpoint option
  • Adds a AllowOldForks option
• Removes all code related to manually specified checkpoints and finding candidates
• Removes the following errors since they are no longer used:
  • ErrBadCheckpoint
  • ErrCheckpointTimeTooOld
• Renames checkpointNode to rejectForksCheckpoint to make it clear that is the only thing it applies to
  • Adds logic to potentially reject forks deep in history as follows:
    • Do not reject old forks if they are manually allowed or the hard-coded assumevalid block is not specified for the network
    • Automatically choose an ancestor that is two weeks worth of blocks prior to the hard-coded assumevalid block (clamped to the genesis block if necessary)
• Replaces the --nocheckpoints CLI option with --allowoldforks
  • Updates doc.go to match the changes to the CLI options
• Deprecates the following:
  • chaincfg.LatestCheckpointHeight
  • chaincfg.Checkpoints
• Removes all chaincfg.Checkpoints entries since they are no longer used

[rstaudt2]

This looks great. It's nice to consolidate this logic and not deal with both checkpoints and assume valid separately. I also think referring to the concept as allowing old forks is more self-explanatory than calling it checkpoints.

I don't see any logic issues and ran a few full syncs on mainnet without issue with various combinations of --allowoldforks and --assumevalid options.

[rstaudt2]

Nice, good call to cache this.