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

ReviewabilityReviewsAgreementSize
#35874 l0rinc p2p: prevent BIP35 requesters from bypassing inbound tx-relay capacityNeeds rebase0Neutral12 + 28 tests
  • Prevent inbound peers from bypassing transaction-relay capacity limits by requesting mempool inventory
  • Keep nodes from serving full mempool inventory to connections not counted toward relay limits
  • Ready for review
  • No review verdicts recorded
  • Neutral sentiment with previous objections resolved and no explicit support yet
  • Concern that peers would receive unintended unfiltered announcements resolved with a test (darosior)
  • Objection to allowing mempool requests when relay is disabled resolved by ignoring them (gmaxwell)
  • Verified SPV sequencing compatibility with existing client implementations (schildbach)
  • 12 lines added or modified outside tests
  • 28 lines added or modified in tests
  • 3 lines removed in total
  • 5 files, 3 commits
P2P#16 of 71
P2 · DoS protection
  • P2 because it fixes an evasion of inbound transaction-relay capacity limits
  • Prevents uncounted peers from requesting full mempool inventory and undermining DoS defenses
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Ignore BIP35 mempool messages from peers that have transaction relay disabled (fRelay=false), unless the connection has the mempool net permission. Peers can still obtain mempool inventory after enabling transaction relay, such as by sending a BIP37 filterload message, which subjects them to existing inbound transaction-relay connection limits.

Problem: When a node runs with bloom filtering enabled, an inbound peer can connect with fRelay=false to evade the inbound transaction-relay connection capacity limits introduced in PR 28463, while still requesting and receiving full mempool inventory via BIP35 mempool messages.

Evidence of importance:

  • PR description: 'When a node offers NODE_BLOOM, an inbound peer can advertise fRelay=false and request BIP35 mempool inventory while remaining outside the inbound transaction-relay capacity introduced in #28463.'
  • Commit 3e64b65359: 'An inbound peer with fRelay=false stays outside transaction-relay capacity accounting, yet BIP35 requests give it full mempool inventory. Ignore these requests until transaction relay is enabled, except when the operator grants the mempool permission.'

Risk of a mistake: high (p2p). A flaw in P2P message processing could inadvertently disconnect or drop valid inventory requests from legitimate SPV clients or peers with custom permissions.

Changed since the previous assessment: The implementation remains the same; release notes and an entry in doc/bips.md documenting the behavior for v33.0 were added.

Reviewability

Ready · Needs rebase

Conflicts with master; review the logic now, the rebase is mechanical.

Agreement

Neutral

objections settled, nobody has spoken for the PR

Thread notes: Initial record. darosior raised a concern about unintended inv flooding which l0rinc addressed with test verification, and gmaxwell suggested disallowing mempool requests from fRelay=false peers, prompting l0rinc to rebase and rework the implementation after checking SPV sequencing with bitcoinj maintainer schildbach.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
darosior (member)objection, correctnessFloods fRelay=false peers with unfiltered transaction invs after a mempool request, constituting an unintended protocol change.fixed · fix pushed · v1, not yet re-checkedansweredyes2026-08-04: 'Prior to this we would not flood a peer that set BIP 37 `fRelay` to `false` with INV's until they set a filter. After this change, we would flood them with non-filtered INV's provided they previously sent a MEMPOOL message.'
Status from: 2026-08-04: l0rinc: 'To make sure, I added a test that requests a BIP35 snapshot and verifies that a transaction added afterward is announced to a regular relay peer but not to the requester. It passes before and after the production change.'
gmaxwell (contributor)objection, approachAllowing fRelay=false peers to request mempool inventory moots bandwidth reduction and surveillance privacy assumptions.fixed · fix pushed · v1, not yet re-checkedansweredyes2026-08-12: 'Should fRelay=false be able to request inventory at all? ... I think it probably shouldn't be allowed.'
Status from: 2026-08-15: l0rinc: 'The PR now ignores non-permissioned `mempool` requests while tx relay is disabled, preserving existing BIP37 and targeted `getdata` behavior.'

Participants:

  • darosior (member, objection, 1 statements 2026-08-04 to 2026-08-04): worried earlier revision altered protocol behavior by flooding fRelay=false peers with non-filtered invs
  • gmaxwell (contributor, objection, 1 statements 2026-08-12 to 2026-08-12): argued fRelay=false peers should not be allowed to request mempool inventory
  • schildbach (contributor, neutral, 1 statements 2026-08-13 to 2026-08-13): confirmed bitcoinj SPV behavior sends filterload before mempool

Files

30 lines under test/bench/ci.

  • test/functional/p2p_connection_limits.py +22/-1
  • doc/release-notes-35874.md +8/-0
  • test/functional/p2p_filter.py +6/-1
  • src/net_processing.cpp +3/-0
  • doc/bips.md +1/-1

Card

The short text the ranking pass compares across PRs.

Bitcoin Core now ignores BIP35 mempool requests from peers that have transaction relay disabled, unless they are granted the mempool network permission. Currently, inbound peers can connect with fRelay=false to avoid counting toward the inbound transaction-relay capacity limit added in PR 28463, yet still consume bandwidth by requesting full mempool inventory. Requiring active transaction relay closes this loophole while preserving SPV clients like bitcoinj that send a BIP37 filterload message before requesting the mempool.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-03T01:18, confidence high, input hash ebb13f37a0d582c7
thread read through 2026-08-15 (6 statements), head 14eee1fc57
Discussion read under schema 1 rules: suggestions and questions may be missing, and an objection may combine several harms (schema history).
labels: P2P, Needs rebase

Categories

P2P

P2 · DoS protection

Fixes an evasion of inbound transaction-relay capacity limits where inbound peers could bypass resource limits via BIP35 mempool messages. Inbound peers with fRelay=false can bypass inbound tx-relay connection accounting while still receiving full mempool inventory, undermining DoS protections introduced in #28463.

Membership: Labeled P2P and changes net_processing.cpp to enforce connection limits during BIP35 mempool message handling.

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