Main motivation of this PR is to enable #32379 without creating a censorship problem where the attacker sends a witness-stripped version of a transaction to cause us to reject its child. It does this by removing all queries to the rejection caches by txid.
TLDR, this PR removes the logic that stops us from attempting orphan resolution when parents are found in the rejection filter. It removes the rejection cache filtering part of all txid-based tx requests. In practice, this seems to only be used for orphan resolution because everybody supports wtxidrelay.
Background:
We have 2 bloom filters for remembering transactions that we’ve rejected so we don’t redownload them, RecentRejectsFilter and RecentRejectsReconsiderableFilter. This lets us save a little bit of bandwidth on rejected transactions, particularly if we have policy differences. It’s not designed to stop attackers from wasting our download bandwidth, as they can create as many policy-invalid transactions with different witnesses as they want. We generally only put wtxids and not txids in them (see #18044), except for these cases:
(A) When we specifically know that the rejection reason is not due to the witness
(B) When the transaction has no witness, so its txid == wtxid
(C) (With #32379) When the transaction’s witness has been stripped, so txid == wtxid
“Will this increase bandwidth usage?” We check the filters to decide whether to send a getdata for an inv, whether we should validate a tx we just downloaded, and whether we should keep an orphan: we look the missing parents up by (prevout) txid and throw the orphan away if its parents were already rejected. That means there are very few cases where we save bandwidth by finding a txid in the filter. I collected some stats over a couple of weeks:
- When we receive an announcement by txid (i.e. the peer does not support BIP339 wtxidrelay) and somehow the txid is already in the filter (see cases ABC)
- On my node, I’m seeing 100% of peers support wtxidrelay. Bitcoin Core has been doing this since ~5 years ago. I’m sure there are some nodes that don’t do it, but it’ll probably be rare that we are surrounded by txidrelay peers and that we have a policy difference causing us to reject the transaction that they all send us.
- When an orphan parent has been placed in the rejection cache (see cases ABC)
- On my node, orphan parent fetching is only 3.64% of my transaction requests. I also set mempoolexpiry to 1 hour to try to artificially increase orphan rates, though I don’t know whether the effect is significant.
- 93.77% of all transactions I receive have witnesses (includes accepted and rejected ones). 96.20% of the orphan parents I fetched had witnesses.
- I actually haven’t found any cases of already-rejected parent txids in the past week, but the number of nonsegwit orphan parents is just so tiny - a few dozen requests per day.
