Permit disconnection of outbound peers on bad/slow chains
commit5a6d00c6defc587e22c93e63029fdd538ce8858d
authorSuhas Daftuar <sdaftuar@gmail.com>
Thu, 12 Oct 2017 17:55:43 +0000 (12 13:55 -0400)
committerSuhas Daftuar <sdaftuar@gmail.com>
Thu, 26 Oct 2017 17:43:53 +0000 (26 13:43 -0400)
treed265b9667143005dda2f82a0415bdc4585c7cff6
parentc60fd71a65e841efe187992f46c583a704cc37f5
Permit disconnection of outbound peers on bad/slow chains

Currently we have no rotation of outbound peers.  If an outbound peer
stops serving us blocks, or is on a consensus-incompatible chain with
less work than our tip (but otherwise valid headers), then we will never
disconnect that peer, even though that peer is using one of our 8
outbound connection slots.  Because we rely on our outbound peers to
find an honest node in order to reach consensus, allowing an
incompatible peer to occupy one of those slots is undesirable,
particularly if it is possible for all such slots to be occupied by such
peers.

Protect against this by always checking to see if a peer's best known
block has less work than our tip, and if so, set a 20 minute timeout --
if the peer is still not known to have caught up to a chain with as much
work as ours after 20 minutes, then send a single getheaders message,
wait 2 more minutes, and if a better header hasn't been received by then,
disconnect that peer.

Note:

- we do not require that our peer sync to the same tip as ours, just an
equal or greater work tip.  (Doing otherwise would risk partitioning the
network in the event of a chain split, and is also unnecessary.)

- we pick 4 of our outbound peers and do not subject them to this logic,
to be more conservative. We don't wish to permit temporary network
issues (or an attacker) to excessively disrupt network topology.
src/net_processing.cpp
src/net_processing.h