The seeder currently only bans misbehaving nodes. With D5380, this
change will allow the seeder to eventually ban a node on the wrong
chain.
As previously noted in D5380, the seeder cannot differentiate between
an IBD node/a node stuck behind the checkpoint a node on the wrong chain.
Only a node clearly on the wrong chain should be banned.
Given enough time, a good node should finish its IBD and pass
CSeederNode.Run(). On the other hand, a node on the wrong chain very likely
won't change become good later on.
Nodes worthy of being banned must have the following properties:
(1) Have failed the current run of CSeederNode.Run() (2) Be following the wrong chain (3) Have poor reliability (4) Have not recently (within the last two days) passed CSeederNode.Run()
(1) and (2) are determined by the communications from CSeederNode.Run().
(3) is determined by IsReliable(), the results of repeated iteration of a
reliability function. This prevents banning nodes that may only be following
part of the chain, but are at least useful as seeds for part of the chain.
Core nodes with high reliability, for example, are not following the correct
chain, but are still useful for IBD of a fresh node.
Excluding the edge case of previously untested node, (4) is determined
using ourLastSuccess. In order to solve the edge case, the seeder's
database must additionally track the time a node was first discovered
otherwise all fresh nodes would be banned on their first CSeederNode.Run() failure.
Review note: The seeder is currently unable to reach the unbanning logic
while it is running. In order for a node to be unbanned, the seeder
must be restarted with the --wipeban option enabled. As such banned
nodes are effectively banned forever.