diff options
author | Amiti Uttarwar <amiti@uttarwar.org> | 2020-08-12 09:56:17 -0700 |
---|---|---|
committer | Amiti Uttarwar <amiti@uttarwar.org> | 2020-09-02 17:18:22 -0700 |
commit | 1e563aed785565af6b7aed7f7399c52205d8f19c (patch) | |
tree | 6acec39230a46e254a5df6013d8e78e1ebe21064 | |
parent | da3a0be61b025224231206cb4656e420453bfdeb (diff) |
[refactor] Simplify check for block-relay-only connection.
Previously we deduced it was a block-relay-only based on presence of the
m_tx_relay structure. Now we have the ability to identify it directly via a
connection type accessor function.
-rw-r--r-- | src/net_processing.cpp | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/net_processing.cpp b/src/net_processing.cpp index b419ee7e61..ce4ac3cd75 100644 --- a/src/net_processing.cpp +++ b/src/net_processing.cpp @@ -2018,7 +2018,7 @@ static void ProcessHeadersMessage(CNode& pfrom, CConnman& connman, ChainstateMan } } - if (!pfrom.fDisconnect && pfrom.IsOutboundOrBlockRelayConn() && nodestate->pindexBestKnownBlock != nullptr && pfrom.m_tx_relay != nullptr) { + if (!pfrom.fDisconnect && pfrom.IsFullOutboundConn() && nodestate->pindexBestKnownBlock != nullptr) { // If this is an outbound full-relay peer, check to see if we should protect // it from the bad/lagging chain logic. // Note that block-relay-only peers are already implicitly protected, so we |