diff options
author | Suhas Daftuar <sdaftuar@gmail.com> | 2017-10-12 13:55:43 -0400 |
---|---|---|
committer | Suhas Daftuar <sdaftuar@gmail.com> | 2017-10-26 13:43:53 -0400 |
commit | 5a6d00c6defc587e22c93e63029fdd538ce8858d (patch) | |
tree | d265b9667143005dda2f82a0415bdc4585c7cff6 /src/test/DoS_tests.cpp | |
parent | c60fd71a65e841efe187992f46c583a704cc37f5 (diff) | |
download | bitcoin-5a6d00c6defc587e22c93e63029fdd538ce8858d.tar.xz |
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.
Diffstat (limited to 'src/test/DoS_tests.cpp')
0 files changed, 0 insertions, 0 deletions