aboutsummaryrefslogtreecommitdiff
path: root/src/net_processing.h
diff options
context:
space:
mode:
authorSuhas Daftuar <sdaftuar@gmail.com>2020-09-01 17:05:47 -0400
committerSuhas Daftuar <sdaftuar@gmail.com>2020-12-10 08:46:39 -0500
commitdaffaf03fbede6c01287779e464379ee3acb005a (patch)
tree106fddb539d273bed1168ccde48340f0071057d2 /src/net_processing.h
parent3cc8a7a0f5fa183cd7f0cf5e56f16f9a9d1f2441 (diff)
downloadbitcoin-daffaf03fbede6c01287779e464379ee3acb005a.tar.xz
Periodically make block-relay connections and sync headers
To make eclipse attacks more difficult, regularly initiate outbound connections and stay connected long enough to sync headers and potentially learn of new blocks. If we learn a new block, rotate out an existing block-relay peer in favor of the new peer. This augments the existing outbound peer rotation that exists -- currently we make new full-relay connections when our tip is stale, which we disconnect after waiting a small time to see if we learn a new block. As block-relay connections use minimal bandwidth, we can make these connections regularly and not just when our tip is stale. Like feeler connections, these connections are not aggressive; whenever our timer fires (once every 5 minutes on average), we'll try to initiate a new block-relay connection as described, but if we fail to connect we just wait for our timer to fire again before repeating with a new peer.
Diffstat (limited to 'src/net_processing.h')
-rw-r--r--src/net_processing.h4
1 files changed, 4 insertions, 0 deletions
diff --git a/src/net_processing.h b/src/net_processing.h
index d5b54dae56..12a4e9c38f 100644
--- a/src/net_processing.h
+++ b/src/net_processing.h
@@ -206,6 +206,10 @@ private:
//* Whether this node is running in blocks only mode */
const bool m_ignore_incoming_txs;
+ /** Whether we've completed initial sync yet, for determining when to turn
+ * on extra block-relay-only peers. */
+ bool m_initial_sync_finished{false};
+
/** Protects m_peer_map */
mutable Mutex m_peer_mutex;
/**