From b191c7dfb7ede3f74edb3a32b8ac6fa2f4d6b78a Mon Sep 17 00:00:00 2001 From: James O'Beirne Date: Mon, 8 Oct 2018 22:19:56 -0400 Subject: [PATCH] doc: add comment explaining recentRejects-DoS behavior When we receive invalid txs for the first time, we mark the sender as misbehaving. If we receive the same tx before a new block is seen, we *don't* punish the second sender (in the same way we do the original sender). It wasn't initially clear to me that this is intentional, so add a clarifying comment. --- src/net_processing.cpp | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/net_processing.cpp b/src/net_processing.cpp index a1b6e021a..51b545efa 100644 --- a/src/net_processing.cpp +++ b/src/net_processing.cpp @@ -2357,6 +2357,23 @@ bool static ProcessMessage(CNode* pfrom, const std::string& strCommand, CDataStr for (const CTransactionRef& removedTx : lRemovedTxn) AddToCompactExtraTransactions(removedTx); + // If a tx has been detected by recentRejects, we will have reached + // this point and the tx will have been ignored. Because we haven't run + // the tx through AcceptToMemoryPool, we won't have computed a DoS + // score for it or determined exactly why we consider it invalid. + // + // This means we won't penalize any peer subsequently relaying a DoSy + // tx (even if we penalized the first peer who gave it to us) because + // we have to account for recentRejects showing false positives. In + // other words, we shouldn't penalize a peer if we aren't *sure* they + // submitted a DoSy tx. + // + // Note that recentRejects doesn't just record DoSy or invalid + // transactions, but any tx not accepted by the mempool, which may be + // due to node policy (vs. consensus). So we can't blanket penalize a + // peer simply for relaying a tx that our recentRejects has caught, + // regardless of false positives. + int nDoS = 0; if (state.IsInvalid(nDoS)) {