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

pull l0rinc wants to merge 4 commits into bitcoin:master from l0rinc:l0rinc/bip35-relay-capacity changing 3 files +59 −27

l0rinc commented at 11:55 PM on August 3, 2026: contributor

Problem: An inbound peer that advertises fRelay=false can request BIP35 mempool inventory and fetch the advertised transactions while remaining outside the inbound transaction-relay capacity introduced in #28463. The path is available when the node offers NODE_BLOOM, usually through non-default -peerbloomfilters.

Fix: Count the peer against the relay limit before queuing its first BIP35 response, so later requests do not rescan all connections. fRelay=false continues to disable ongoing announcements, and the node skips the response if capacity eviction selects the requester.
DrahtBot added the label P2P on Aug 3, 2026
DrahtBot commented at 11:55 PM on August 3, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35874.



Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.
l0rinc marked this as ready for review on Aug 4, 2026
l0rinc force-pushed on Aug 4, 2026
l0rinc renamed this:
~~p2p: account BIP35 requests against relay capacity~~
p2p: enforce relay limit for BIP35 requesters
on Aug 4, 2026
l0rinc force-pushed on Aug 4, 2026
DrahtBot added the label CI failed on Aug 4, 2026
DrahtBot commented at 5:25 AM on August 4, 2026: contributor


🚧 At least one of the CI tasks failed. <sub>Task riscv32 bare metal, static libbitcoin_consensus: https://github.com/bitcoin/bitcoin/actions/runs/30880088557/job/91899376958</sub> <sub>LLM reason (✨ experimental): CI failed because cloning the binutils-gdb submodule (sourceware.org/git/binutils-gdb.git) errored with “fatal: the remote end hung up unexpectedly” (exit code 2).</sub>

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:
- Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
- A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
- An intermittent issue.
Leave a comment here, if you need help tracking down a confusing failure.

</details>
DrahtBot closed this on Aug 4, 2026
DrahtBot reopened this on Aug 4, 2026
DrahtBot removed the label CI failed on Aug 4, 2026
in src/net_processing.cpp:5180 in dd1af38900 outdated
```
5174 | @@ -5191,6 +5175,11 @@ void PeerManagerImpl::ProcessMessage(Peer& peer, CNode& pfrom, const std::string
5175 |          }
5176 |  
5177 |          if (auto tx_relay = peer.GetTxRelay(); tx_relay != nullptr) {
5178 | +            if (pfrom.IsInboundConn() && !pfrom.m_relays_txs) {
5179 | +                // BIP35 consumes tx-relay capacity while fRelay=false still disables ongoing announcements.
5180 | +                pfrom.m_relays_txs = true;
```
darosior commented at 5:25 PM on August 4, 2026:

I think that's a protocol change? 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.

l0rinc commented at 8:15 PM on August 4, 2026:

Valid question. If I understood your objection correctly, it applies to TxRelay::m_relay_txs, while we're changing CNode::m_relays_txs. 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. Could you please check whether it satisfies your criterion? Thanks for the hint.
l0rinc force-pushed on Aug 4, 2026

test: clarify relay-disabled peer setup

`add_relay_disabled_peers()` centralizes the custom `VERSION` handshake for inbound peers that disable ongoing transaction announcements without becoming block-relay-only.

ab25ac3fad

test: verify BIP35 respects `fRelay=false`

When the node offers `NODE_BLOOM`, a peer that advertises `fRelay=false` may request a BIP35 mempool snapshot while later transaction announcements remain disabled.

c61b952d0c

test: characterize BIP35 relay capacity 384c985d60

p2p: enforce relay limit for BIP35 requesters

A node that offers `NODE_BLOOM` lets an inbound peer advertising `fRelay=false` request BIP35 mempool inventory while remaining outside inbound transaction-relay capacity.

The first BIP35 request counts the peer against the limit, so later requests do not rescan all connections.
`fRelay=false` continues to disable ongoing transaction announcements, and the node skips the response if capacity eviction selects the requester.

760da863d9

l0rinc force-pushed on Aug 5, 2026
l0rinc renamed this:
~~p2p: enforce relay limit for BIP35 requesters~~
p2p: prevent BIP35 requesters from bypassing inbound tx-relay capacity
on Aug 5, 2026
DrahtBot added the label CI failed on Aug 5, 2026

Contributors

Labels

Linked (view graph)

#28463 p2p: Increase inbound capacity for block-relay only connections

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

Code Coverage & Benchmarks

Reviews