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.
Synopsis
Declared in <node/txdownloadman_impl.h>
std::unique_ptr<CRollingBloomFilter> m_lazy_recent_rejects = {nullptr};Description
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
Created with MrDocs