#35874 p2p: prevent BIP35 requesters from bypassing inbound tx-relay capacity

• Prevent inbound peers from bypassing transaction-relay limits by requesting full mempools via BIP35
• Keep SPV bloom filter clients working properly while blocking evasion of peer eviction accounting

This pull request ignores BIP35 mempool messages from inbound peers that have disabled transaction relay (fRelay=false), unless the peer has explicit mempool permissions. Inbound peers loading a BIP37 bloom filter enable transaction relay at that time, subjecting them to standard inbound relay limits while maintaining SPV client compatibility.

Problem: When a node serves bloom filters (NODE_BLOOM), an inbound peer setting fRelay=false can request full mempool inventory via BIP35 while staying accounted as a block-relay-only peer, bypassing the inbound transaction-relay connection limits introduced in #28463.

P3 · DoS protection

• P3 because it closes a loophole where inbound peers evade tx-relay connection limits while fetching mempools
• Impact is limited because BIP35 mempool queries require bloom filter support, which is off by default

P3 because it patches an inbound connection-accounting loophole where peers avoid tx-relay eviction while still retrieving mempool dumps. Impact is limited because BIP35 requires NODE_BLOOM, which is disabled by default.

Membership: Modifies P2P message handling in src/net_processing.cpp for BIP35 mempool messages.

Factors: security/stability 1, bug 1, performance 0, user value 0, leverage 0

• Ready for review
• The rework addressed previous feedback and CI is passing

The code is compact, CI is passing, and previous reviewer feedback has been addressed in the current push.

Author status: active; addressed review feedback with a rebased rework

Resolved concerns:

• darosior questioned whether earlier revisions altered inv relay behavior for fRelay=false peers; author added regression tests and subsequently simplified the approach.
• gmaxwell questioned whether fRelay=false peers should be permitted to request mempool inventory at all, prompting a check with bitcoinj maintainer schildbach on SPV filterload sequencing.

• Positive consensus with no standing objections after design rework
• Suggested that peers with relay disabled should not receive mempool inventory (gmaxwell)
• Verified SPV client compatibility and filterload message sequencing (schildbach)
• Raised concerns on earlier inventory relay changes that led to regression tests and simplification (darosior)

Positive; guided by feedback from gmaxwell and schildbach with no standing objections.

Reviewers discussed whether mempool requests should be allowed at all for fRelay=false peers and confirmed compatibility requirements, which the author incorporated into the final approach.

• gmaxwell suggested fRelay=false peers should probably not be allowed to request mempool inventory.
• schildbach confirmed that bitcoinj sends filterload prior to mempool in SPV mode.
• l0rinc reworked the patch to ignore mempool requests when transaction relay is disabled.

Review verdicts (DrahtBot): 0

25 lines under test/bench/ci.

• test/functional/p2p_connection_limits.py +17/-1
• test/functional/p2p_filter.py +6/-1
• src/net_processing.cpp +3/-0

Ignores BIP35 mempool requests from inbound peers that have disabled transaction relay (fRelay=false), unless explicitly granted mempool permissions. This closes a loophole introduced in #28463 where peers could bypass inbound transaction-relay connection capacity limits on nodes with NODE_BLOOM enabled. Input from gmaxwell and bitcoinj maintainer schildbach shaped the fix to preserve legitimate SPV filterload flows. The change is small, tests pass, and it is ready for code review.