Filter for transactions that were recently rejected by the mempool. These are not rerequested until the chain tip changes, at which point the entire filter is reset.
Declared in <node/txdownloadman_impl.h>
std::unique_ptr<CRollingBloomFilter> m_lazy_recent_rejects = {nullptr};Without this filter we'd be re-requesting txs from each of our peers, increasing bandwidth consumption considerably. For instance, with 100 peers, half of which relay a tx we don't accept, that might be a 50x bandwidth increase. A flooding attacker attempting to roll-over the filter using minimum-sized, 60byte, transactions might manage to send 1000/sec if we have fast peers, so we pick 120,000 to give our peers a two minute window to send invs to us.
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.
We typically only add wtxids to this filter. For non-segwit transactions, the txid == wtxid, so this only prevents us from re-downloading non-segwit transactions when communicating with non-wtxidrelay peers -- which is important for avoiding malleation attacks that could otherwise interfere with transaction relay from non-wtxidrelay peers. For communicating with wtxidrelay peers, having the reject filter store wtxids is exactly what we want to avoid redownload of a rejected transaction.
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. This can be helpful when communicating with txid-relay peers or if we were to otherwise fetch a transaction via txid (eg in our orphan handling).
Memory used: 1.3 MB