[#node-TxDownloadManagerImpl-m_lazy_recent_rejects]
= xref:node.adoc[node]::xref:node/TxDownloadManagerImpl.adoc[TxDownloadManagerImpl]::m&lowbar;lazy&lowbar;recent&lowbar;rejects
:relfileprefix: ../../
:mrdocs:

Filter for transactions that were recently rejected by the mempool&period; These are not rerequested until the chain tip changes, at which point the entire filter is reset&period;

== Synopsis

Declared in `&lt;node&sol;txdownloadman&lowbar;impl&period;h&gt;`

[source,cpp,subs="verbatim,replacements,macros,-callouts"]
----
std::unique&lowbar;ptr&lt;CRollingBloomFilter&gt; m&lowbar;lazy&lowbar;recent&lowbar;rejects = &lcub;nullptr&rcub;;
----

== Description

Without this filter we&apos;d be re&hyphen;requesting txs from each of our peers, increasing bandwidth consumption considerably&period; For instance, with 100 peers, half of which relay a tx we don&apos;t accept, that might be a 50x bandwidth increase&period; A flooding attacker attempting to roll&hyphen;over the filter using minimum&hyphen;sized, 60byte, transactions might manage to send 1000&sol;sec if we have fast peers, so we pick 120,000 to give our peers a two minute window to send invs to us&period;

Decreasing the false positive rate is fairly cheap, so we pick one in a million to make it highly unlikely for users to have issues with this filter&period;

We typically only add wtxids to this filter&period; For non&hyphen;segwit transactions, the txid &equals;&equals; wtxid, so this only prevents us from re&hyphen;downloading non&hyphen;segwit transactions when communicating with non&hyphen;wtxidrelay peers &hyphen;&hyphen; which is important for avoiding malleation attacks that could otherwise interfere with transaction relay from non&hyphen;wtxidrelay peers&period; For communicating with wtxidrelay peers, having the reject filter store wtxids is exactly what we want to avoid redownload of a rejected transaction&period;

In cases where we can tell that a segwit transaction will fail validation no matter the witness, we may add the txid of such transaction to the filter as well&period; This can be helpful when communicating with txid&hyphen;relay peers or if we were to otherwise fetch a transaction via txid (eg in our orphan handling)&period;

Memory used&colon; 1&period;3 MB


[.small]#Created with https://www.mrdocs.com[MrDocs]#
