aboutsummaryrefslogtreecommitdiff
path: root/src/net_processing.h
AgeCommit message (Collapse)Author
2020-08-28Merge #19607: [p2p] Add Peer struct for per-peer data in net processingWladimir J. van der Laan
8e35bf59062b3a823182588e0bf809b3367c2be0 scripted-diff: rename misbehavior members (John Newbery) 1f96d2e673a78220eebf3bbd15b121c51c4cd97b [net processing] Move misbehavior tracking state to Peer (John Newbery) 7cd4159ac834432dadd60a5e8ee817f3cadbee55 [net processing] Add Peer (John Newbery) aba03359a6e62a376ae44914f609f82a1556fc89 [net processing] Remove CNodeState.name (John Newbery) Pull request description: We currently have two structures for per-peer data: - `CNode` in net, which should just contain connection layer data (eg socket, send/recv buffers, etc), but currently also contains some application layer data (eg tx/block inventory). - `CNodeState` in net processing, which contains p2p application layer data, but requires cs_main to be locked for access. This PR adds a third struct `Peer`, which is for p2p application layer data, and doesn't require cs_main. Eventually all application layer data from `CNode` should be moved to `Peer`, and any data that doesn't strictly require cs_main should be moved from `CNodeState` to `Peer` (probably all of `CNodeState` eventually). `Peer` objects are stored as shared pointers in a net processing global map `g_peer_map`, which is protected by `g_peer_mutex`. To use a `Peer` object, `g_peer_mutex` is locked, a copy of the shared pointer is taken, and the lock is released. Individual members of `Peer` are protected by different mutexes that guard related data. The lifetime of the `Peer` object is managed by the shared_ptr refcount. This PR adds the `Peer` object and moves the misbehaving data from `CNodeState` to `Peer`. This allows us to immediately remove 15 `LOCK(cs_main)` instances. For more motivation see #19398 ACKs for top commit: laanwj: Code review ACK 8e35bf59062b3a823182588e0bf809b3367c2be0 troygiorshev: reACK 8e35bf59062b3a823182588e0bf809b3367c2be0 via `git range-diff master 9510938 8e35bf5` theuni: ACK 8e35bf59062b3a823182588e0bf809b3367c2be0. jonatack: ACK 8e35bf59062b3a823182588e0bf809b3367c2be0 keeping in mind Cory's comment (https://github.com/bitcoin/bitcoin/pull/19607#discussion_r470173964) for the follow-up Tree-SHA512: ad84a92b78fb34c9f43813ca3dfbc7282c887d55300ea2ce0994d134da3e0c7dbc44d54380e00b13bb75a57c28857ac3236bea9135467075d78026767a19e4b1
2020-08-21[net_processing] Move ProcessMessage to PeerLogicValidationJohn Newbery
2020-08-12[net_processing] Change PeerLogicValidation to hold a connman referenceJohn Newbery
Hold a reference to connman rather than a pointer because: - PeerLogicValidation can't run without a connman - The pointer never gets reseated The alternative is to always assert that the pointer is non-null before dereferencing. Change the name from connman to m_connman at the same time to conform with current style guidelines.
2020-08-12scripted-diff: rename misbehavior membersJohn Newbery
-BEGIN VERIFY SCRIPT- sed -i 's/nMisbehavior/m_misbehavior_score/g' src/net_processing.cpp src/net_processing.h src/rpc/net.cpp src/qt/rpcconsole.cpp -END VERIFY SCRIPT-
2020-07-24Merge #19472: [net processing] Reduce cs_main scope in ↵Wladimir J. van der Laan
MaybeDiscourageAndDisconnect() 655b1957470c39bcab64917747c9f467444bd809 [net processing] Continue SendMessages processing if not disconnecting peer (John Newbery) a49781e56d2bd6a61ec027a09c1db9ee1a4abf2e [net processing] Only call MaybeDiscourageAndDisconnect from SendMessages (John Newbery) a1d5a428a24afe4f600be29e9d0d3bb4c720e816 [net processing] Fix bad indentation in SendMessages() (John Newbery) 1a1c23f8d40116741f0e26cdf22688fd91c923fc [net processing] Change cs_main TRY_LOCK to LOCK in SendMessages() (John Newbery) Pull request description: The motivation for this PR is to reduce the scope of cs_main locking in misbehavior logic. It is the first set of commits from a larger branch to move the misbehavior data out of CNodeState and into a new struct that doesn't take cs_main. There are some very minor behavior changes in this branch, such as: - Not checking for discouragement/disconnect in `ProcessMessages()` (and instead relying on the following check in `SendMessages()`) - Checking for discouragement/disconnect as the first action in `SendMessages()` (and not doing ping message sending first) - Continuing through `SendMessages()` if `MaybeDiscourageAndDisconnect()` doesn't disconnect the peer (rather than dropping out of `SendMessages()` ACKs for top commit: jonatack: re-ACK 655b195 per `git range-diff 505b4ed f54af5e 655b195`, code/commit messages review, a bit of code history, and debug build. MarcoFalke: ACK 655b195747 only some style-nits 🚁 promag: Code review ACK 655b1957470c39bcab64917747c9f467444bd809. ariard: Code Review ACK 655b195 Tree-SHA512: fd6d7bc6bb789f5fb7771fb6a45f61a8faba32af93b766554f562144f9631d15c9cc849a383e71743ef73e610b4ee14853666f6fbf08a3ae35176d48c76c65d3
2020-07-19Add support for tx-relay via wtxidSuhas Daftuar
This adds a field to CNodeState that tracks whether to relay transactions with that peer via wtxid, instead of txid. As of this commit the field will always be false, but in a later commit we will add a way to negotiate turning this on via p2p messages exchanged with the peer.
2020-07-14[net/net processing] check banman pointer before dereferencingJohn Newbery
Although we currently don't do this, it should be possible to create a CConnman or PeerLogicValidation without a Banman instance. Therefore always check that banman exists before dereferencing the pointer. Also add comments to the m_banman members of CConnman and PeerLogicValidation to document that these may be nullptr.
2020-07-11net: rename DEFAULT_BANSCORE_THRESHOLD to DISCOURAGEMENT_THRESHOLDJon Atack
and move it from validation to net processing.
2020-07-11[net processing] Only call MaybeDiscourageAndDisconnect from SendMessagesJohn Newbery
`nMisbehavior` is a tally in `CNodeState` that can be incremented from anywhere. That almost always happens inside a `ProcessMessages()` call (because we increment the misbehavior score when receiving a bad messages from a peer), but not always. See, for example, the call to `MaybePunishNodeForBlock()` inside `BlockChecked()`, which is an asynchronous callback from the validation interface, executed on the scheduler thread. As long as `MaybeDiscourageAndDisconnect()` is called regularly for the node, then the misbehavior score exceeding the 100 threshold will eventually result in the peer being punished. It doesn't really matter where that `MaybeDiscourageAndDisconnect()` happens, but it makes most sense in `SendMessages()` which is where we do general peer housekeeping/maintenance. Therefore, remove the `MaybeDiscourageAndDisconnect()` call in `ProcessMessages()` and move the `MaybeDiscourageAndDisconnect()` call in `SendMessages()` to the top of the function. This moves it out of the cs_main lock scope, so take that lock directly inside `MaybeDiscourageAndDisconnect()`. Historic note: `MaybeDiscourageAndDisconnect()` was previously `SendRejectsAndCheckIfBanned()`, and before that was just sending rejects. All of those things required cs_main, which is why `MaybeDiscourageAndDisconnect()` was called after the ping logic.
2020-07-03Clean up separated ban/discourage interfacePieter Wuille
2020-06-02refactor: replace CNode pointers by references within net_processing.{h,cpp}Sebastian Falbesoner
2020-05-21net: Pass chainman into PeerLogicValidationMarcoFalke
2020-05-08[init] Add -peerblockfilters optionJim Posen
When a node is configured with --blockfilterindex=basic and -peerblockfilters it can serve compact block filters to its peers. This commit adds the configuration option handling. Future commits add compact block serving and service bits signaling.
2020-04-29Merge #18038: P2P: Mempool tracks locally submitted transactions to improve ↵fanquake
wallet privacy 50fc4df6c4e8a84bdda13ade7bed7a2131796f00 [mempool] Persist unbroadcast set to mempool.dat (Amiti Uttarwar) 297a1785360c4db662a7f3d3ade7b6b503258d39 [test] Integration tests for unbroadcast functionality (Amiti Uttarwar) 6851502472d3625416f0e7796e9f2a0379d14d49 [refactor/test] Extract P2PTxInvStore into test framework (Amiti Uttarwar) dc1da48dc5e5526215561311c184a8cbc345ecdc [wallet] Update the rebroadcast frequency to be ~1/day. (Amiti Uttarwar) e25e42f20a3aa39651fbc1f9fa3df1a49f1f5868 [p2p] Reattempt initial send of unbroadcast transactions (Amiti Uttarwar) 7e93eecce3bc5a1b7bb0284e06f9e2e69454f5ba [util] Add method that returns random time in milliseconds (Amiti Uttarwar) 89eeb4a3335f8e871cc3f5286af4546dff66172a [mempool] Track "unbroadcast" transactions (Amiti Uttarwar) Pull request description: This PR introduces mempool tracking of unbroadcast transactions and periodic reattempts at initial broadcast. This is a part of the rebroadcast project, and a standalone privacy win. The current rebroadcast logic is terrible for privacy because 1. only the source wallet rebroadcasts transactions and 2. it does so quite frequently. In the current system, if a user submits a transaction that does not immediately get broadcast to the network (eg. they are offline), this "rebroadcast" behavior is the safety net that can actually serve as the initial broadcast. So, keeping the attempts frequent is important for initial delivery within a reasonable timespan. This PR aims to improve # 2 by reducing the wallet rebroadcast frequency to ~1/day from ~1/15 min. It achieves this by separating the notion of initial broadcast from rebroadcasts. With these changes, the mempool tracks locally submitted transactions & periodically reattempts initial broadcast. Transactions submitted via the wallet or RPC are added to an "unbroadcast" set & are removed when a peer sends a `getdata` request, or the transaction is removed from the mempool. Every 10-15 minutes, the node reattempts an initial broadcast. This enables reducing the wallet rebroadcast frequency while ensuring the transactions will be propagated to the network. For privacy improvements around # 1, please see #16698. Thank you to gmaxwell for the idea of how to break out this subset of functionality (https://github.com/bitcoin/bitcoin/pull/16698#issuecomment-571399346) ACKs for top commit: fjahr: Code review ACK 50fc4df6c4e8a84bdda13ade7bed7a2131796f00 MarcoFalke: ACK 50fc4df6c4e8a84bdda13ade7bed7a2131796f00, I think this is ready for merge now 👻 amitiuttarwar: The current tip `50fc4df` currently has 6 ACKs on it, so I've opened #18807 to address the last bits. jnewbery: utACK 50fc4df6c4e8a84bdda13ade7bed7a2131796f00. ariard: Code Review ACK 50fc4df (minor points no need to invalid other ACKs) robot-visions: ACK 50fc4df6c4e8a84bdda13ade7bed7a2131796f00 sipa: utACK 50fc4df6c4e8a84bdda13ade7bed7a2131796f00 naumenkogs: utACK 50fc4df Tree-SHA512: 2dd935d645d5e209f8abf87bfaa3ef0e4492705ce7e89ea64279cb27ffd37f4727fa94ad62d41be331177332f8edbebf3c7f4972f8cda10dd951b80a28ab3c0f
2020-04-23[p2p] Reattempt initial send of unbroadcast transactionsAmiti Uttarwar
Every 10-15 minutes, the scheduler kicks off a job that queues unbroadcast transactions onto each node.
2020-03-29net: Add missing cs_vNodes lockMarcoFalke
2020-03-19Merge #17477: Remove the mempool's NotifyEntryAdded and NotifyEntryRemoved ↵Wladimir J. van der Laan
signals e57980b4738c10344baf136de3e050a3cb958ca5 [mempool] Remove NotifyEntryAdded and NotifyEntryRemoved callbacks (John Newbery) 2dd561f36124972d2364f941de9c3417c65f05b6 [validation] Remove pool member from ConnectTrace (John Newbery) 969b65f3f527631ede1a31c7855151e5c5d91f8f [validation] Remove NotifyEntryRemoved callback from ConnectTrace (John Newbery) 5613f9842b4000fed088b8cf7b99674c328d15e1 [validation] Remove conflictedTxs from PerBlockConnectTrace (John Newbery) cdb893443cc16edf974f099b8485e04b3db1b1d7 [validation interface] Remove vtxConflicted from BlockConnected (John Newbery) 1168394d759b13af68acec6d5bfa04aaa24561f8 [wallet] Notify conflicted transactions in TransactionRemovedFromMempool (John Newbery) Pull request description: These boost signals were added in #9371, before we had a `TransactionRemovedFromMempool` method in the validation interface. The `NotifyEntryAdded` callback was used by validation to build a vector of conflicted transactions when connecting a block, which the wallet was notified of in the `BlockConnected` CValidationInterface callback. Now that we have a `TransactionRemovedFromMempool` callback, we can fire that signal directly from the mempool for conflicted transactions. Note that #9371 was implemented to ensure `-walletnotify` events were fired for these conflicted transaction. We inadvertently stopped sending these notifications in #16624 (Sep 2019 commit 7e89994). We should probably fix that, but in a different PR. ACKs for top commit: jonatack: Re-ACK e57980b ryanofsky: Code review ACK e57980b4738c10344baf136de3e050a3cb958ca5, no code changes since previous review, but helpful new code comments have been added and the PR description is now more clear about where the old code came from Tree-SHA512: 3bdbaf1ef2731e788462d4756e69c42a1efdcf168691ce1bbfdaa4b7b55ac3c5b1fd4ab7b90bcdec653703600501b4224d252cfc086aef28f9ce0da3b0563a69
2020-03-12refactor: Remove mempool global from netMarcoFalke
This refactor does two things: * Pass mempool in to PeerLogicValidation * Pass m_mempool around where needed
2020-03-11[validation interface] Remove vtxConflicted from BlockConnectedJohn Newbery
The wallet now uses TransactionRemovedFromMempool to be notified about conflicted wallet, and no other clients use vtxConflicted.
2020-01-29Use rolling bloom filter of recent block tx's for AlreadyHave() checkSuhas Daftuar
In order to determine whether to download or process a relayed transaction, we try to determine if we already have the transaction, either in the mempool, in our recently rejected filter, in our orphan pool, or already confirmed in the chain itself. Prior to this commit, the heuristic for checking the chain is based on whether there's an output corresponding to the 0- or 1-index vout in our coin cache. While that is a quick check, it is very imprecise (say if those outputs were already spent in a block) -- we can do better by just keeping a rolling bloom filter of the transactions in recent blocks, which will capture the case of a transaction which has been confirmed and then fully spent already. To avoid relay problems for transactions which have been included in a recent block but then reorged out of the chain, we clear the bloom filter whenever a block is disconnected.
2020-01-15scripted-diff: Bump copyright of files changed in 2020MarcoFalke
-BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./ -END VERIFY SCRIPT-
2020-01-15scripted-diff: Replace CCriticalSection with RecursiveMutexMarcoFalke
-BEGIN VERIFY SCRIPT- # Delete outdated alias for RecursiveMutex sed -i -e '/CCriticalSection/d' ./src/sync.h # Replace use of outdated alias with RecursiveMutex sed -i -e 's/CCriticalSection/RecursiveMutex/g' $(git grep -l CCriticalSection) -END VERIFY SCRIPT-
2019-12-30scripted-diff: Bump copyright of files changed in 2019MarcoFalke
-BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./ -END VERIFY SCRIPT-
2019-10-29[validation] Add CValidationState subclassesJohn Newbery
Split CValidationState into TxValidationState and BlockValidationState to store validation results for transactions and blocks respectively.
2019-10-02p2p: Remove BIP61 reject messagesMarcoFalke
2019-07-24refactor : use RelayTransaction in BroadcastTransaction utilityAntoine Riard
To do so, we also refactor RelayTransaction to take a txid instead of passing a tx
2019-06-06Move DEFAULT_PEERBLOOMFILTERS from validation.h to net_processing.hMatt Corallo
2019-01-16banman: create and split out banmanCory Fields
Some say he has always been.
2018-09-30Merge #14331: doxygen: Fix member commentsMarcoFalke
fa69ac7614 doxygen: Fix member comments (MarcoFalke) Pull request description: Trailing comments must be indicted with the caret `//!<`. Not all places do this right now, see for example https://dev.visucore.com/bitcoin/doxygen/txmempool_8h.html#a2bc6653552b5871101b6cbefdbaf251f, but they can be fixed with an almost-scripted-diff: ``` sed -i --regexp-extended -e 's/((,|;) *\/\/!) /\1< /g' $(git grep --extended-regexp -l '(,|;)\s*//!\s') ``` (Same as [doxygen] Fix member comments #7793) Tree-SHA512: 451077008353ccc6fcc795f34094b2d022feb7a171b562a07ba4de0dcb0aebc137e12b03970764bd81e2da386751d042903db4c4831900f43c0cfde804c81b2b
2018-09-27Merge #14027: Skip stale tip checking if outbound connections are off or if ↵MarcoFalke
reindexing. 66b3fc5437 Skip stale tip checking if outbound connections are off or if reindexing. (Gregory Maxwell) Pull request description: I got tired of the pointless stale tip notices in reindex and on nodes with connections disabled. Tree-SHA512: eb07d9c5c787ae6dea02cdd1d67a48a36a30adc5ccc74d6f1c0c7364d404dc8848b35d2b8daf5283f7c8f36f1a3c463aacb190d70a22d1fe796a301bb1f03228
2018-09-26doxygen: Fix member commentsMarcoFalke
2018-09-07p2p: Disable BIP 61 by defaultMarcoFalke
2018-08-26Add compile time checking for all cs_main runtime locking assertionspracticalswift
2018-08-23Skip stale tip checking if outbound connections are off or if reindexing.Gregory Maxwell
2018-07-27Update copyright headers to 2018DrahtBot
2018-07-13Merge #13417: [net] Tighten scope in net_processingPieter Wuille
3339ba28e9 Make g_enable_bip61 a member variable of PeerLogicValidation (Jesse Cohen) 6690a28606 Restrict as much as possible in net_processing to translation unit (Jesse Cohen) 1d4df02b7e [move-only] Move things only referenced in net_processing out of header file (Jesse Cohen) 02bbc05310 Rescope g_enable_bip61 to net_processing (Jesse Cohen) Pull request description: As part of a larger effort to decouple net_processing and validation a bit, these are a bunch of simple scope cleanups. I've moved things out of the header file that are only referenced in net_processing and added static (or anonymous namespace) modifiers to everything possible in net_processing. There are a handful of functions which could be static except that they are exposed for the sake of unit testing - these are explicitly commented. There has been some discussion of a compile time annotation, but no conclusion has been reached on that yet. This is somewhat related to other prs #12934 #13413 #13407 and will be followed by prs that reduce reliance on cs_main to synchronize data structures which are translation unit local to net_processing Tree-SHA512: 46c9660ee4e06653feb42ba92189565b0aea17aac2375c20747c0d091054c63829cbf66d2daddf65682b58ce1d6922e23aefea051a7f2c8abbb6db253a609082
2018-07-09Make g_enable_bip61 a member variable of PeerLogicValidationJesse Cohen
2018-07-08net: Remove unused interrupt from SendMessagesfanquake
2018-06-19[move-only] Move things only referenced in net_processing out of header fileJesse Cohen
2018-06-19Rescope g_enable_bip61 to net_processingJesse Cohen
2018-06-12tests: Fix lock-order-inversion (potential deadlock) in DoS_tests. Reported ↵practicalswift
by TSAN. Makes `src/test/test_bitcoin --run_test=DoS_tests` pass also when compiled with TreadSanitizer (`./configure --with-sanitizers=thread`).
2018-05-13net: Add option `-enablebip61` to configure sending of BIP61 notificationsWladimir J. van der Laan
This commit adds a boolean option `-enablebip61`, defaulting to `1`, that can be used to disable the sending of BIP61 `reject` messages. This functionality has been requested for various reasons: - security (DoS): reject messages can reveal internal state that can be used to target certain resources such as the mempool more easily. - bandwidth: a typical node sends lots of reject messages; this counts against upstream bandwidth. Also the reject messages tend to be larger than the message that was rejected. On the other hand, reject messages can be useful while developing client software (I found them indispensable while creating bitcoin-submittx), as well as for our own test cases, so whatever the default becomes on the long run, IMO the functionality should be retained as option. But that's a discussion for later.
2018-04-04Remove direct bitcoin calls from qt/peertablemodel.cppRussell Yanofsky
2018-03-14Polish interfaces around PeerLogicValidationVasil Dimov
* Make PeerLogicValidation final to prevent deriving from it [1] * Prevent deletions of NetEventsInterface and CValidationInterface objects via a base class pointer [1] silences the following compiler warning (from Clang 7.0.0): /usr/include/c++/v1/memory:2285:5: error: delete called on non-final 'PeerLogicValidation' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor] delete __ptr; ^ /usr/include/c++/v1/memory:2598:7: note: in instantiation of member function 'std::__1::default_delete<PeerLogicValidation>::operator()' requested here __ptr_.second()(__tmp); ^ init.cpp:201:15: note: in instantiation of member function 'std::__1::unique_ptr<PeerLogicValidation, std::__1::default_delete<PeerLogicValidation> >::reset' requested here peerLogic.reset(); ^
2018-03-06Add documentation to PeerLogicValidation interface and related functionsJames O'Beirne
2018-01-24net: Move misbehaving logging to net logging categoryWladimir J. van der Laan
This moves the error messages for misbehavior (when available) into the line that reports the misbehavior, as well as moves the logging to the `net` category. This is a continuation of #11583 and avoids serious-looking errors due to misbehaving peers. To do this, Misbehaving() gains an optional `message` argument. E.g. change: 2018-01-18 16:02:27 Misbehaving: x.x.x.x:62174 peer=164603 (80 -> 100) BAN THRESHOLD EXCEEDED 2018-01-18 16:02:27 ERROR: non-continuous headers sequence to 2018-01-18 16:02:27 Misbehaving: x.x.x.x:62174 peer=164603 (80 -> 100) BAN THRESHOLD EXCEEDED: non-continuous headers sequence
2018-01-03Increment MIT Licence copyright header year on files modified in 2017Akira Takizawa
2017-11-16scripted-diff: Replace #include "" with #include <> (ryanofsky)MeshCollider
-BEGIN VERIFY SCRIPT- for f in \ src/*.cpp \ src/*.h \ src/bench/*.cpp \ src/bench/*.h \ src/compat/*.cpp \ src/compat/*.h \ src/consensus/*.cpp \ src/consensus/*.h \ src/crypto/*.cpp \ src/crypto/*.h \ src/crypto/ctaes/*.h \ src/policy/*.cpp \ src/policy/*.h \ src/primitives/*.cpp \ src/primitives/*.h \ src/qt/*.cpp \ src/qt/*.h \ src/qt/test/*.cpp \ src/qt/test/*.h \ src/rpc/*.cpp \ src/rpc/*.h \ src/script/*.cpp \ src/script/*.h \ src/support/*.cpp \ src/support/*.h \ src/support/allocators/*.h \ src/test/*.cpp \ src/test/*.h \ src/wallet/*.cpp \ src/wallet/*.h \ src/wallet/test/*.cpp \ src/wallet/test/*.h \ src/zmq/*.cpp \ src/zmq/*.h do base=${f%/*}/ relbase=${base#src/} sed -i "s:#include \"\(.*\)\"\(.*\):if test -e \$base'\\1'; then echo \"#include <\"\$relbase\"\\1>\\2\"; else echo \"#include <\\1>\\2\"; fi:e" $f done -END VERIFY SCRIPT-
2017-11-02Connect to an extra outbound peer if our tip is staleSuhas Daftuar
If our tip hasn't updated in a while, that may be because our peers are not relaying blocks to us that we would consider valid. Allow connection to an additional outbound peer in that circumstance. Also, periodically check to see if we are exceeding our target number of outbound peers, and disconnect the one which has least recently announced a new block to us (choosing the newest such peer in the case of tie).
2017-10-26Permit disconnection of outbound peers on bad/slow chainsSuhas Daftuar
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.