Merge #14436: doc: add comment explaining recentRejects-DoS behavior

b191c7dfb7 doc: add comment explaining recentRejects-DoS behavior (James O'Beirne)

Pull request description:

  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.

Tree-SHA512: d12c674db137ed3ad83e0b941bffe6ddcd2982238048742afa574a4235881f0e58cfc0a4a576a0503e74c5c5240c270b9520fa30221e8b43a371fb3e0b37066b
This commit is contained in:
MarcoFalke 2018-11-07 14:59:33 -05:00 committed by Munkybooty
parent 13cb92e27f
commit 6fb718dc96

View File

@ -3007,6 +3007,23 @@ bool static ProcessMessage(CNode* pfrom, const std::string& strCommand, CDataStr
llmq::quorumInstantSendManager->TransactionRemovedFromMempool(ptx);
}
// 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))
{