net_processing: bump last_inv_sequence for bip35 messages explicitly
What the developer wrote
Authored by Anthony Towns
net_processing: bump last_inv_sequence for bip35 messages explicitly
This avoids relying on the bump that occurs through the normal INV
process, which is confusing.
What changed, and why it matters
This change makes a Bitcoin node's mempool announcement logic more explicit and reliable. When a node announces the contents of its memory pool to a peer (a BIP35 'mempool' request), it now directly records the latest mempool version. Previously it relied on a side effect of the normal inventory announcement path. The fix reduces the risk that a peer's follow-up requests for those announced transactions would be ignored or mishandled, which could cause a peer to receive inconsistent or incomplete mempool data.
Treat as a low-to-moderate reliability fix. Backport to maintained branches if the implicit sequence bump behavior exists there, since inconsistent P2P state can be leveraged for denial-of-service or information-leak attacks. No immediate emergency response is warranted absent a demonstrated exploit.
Security signals we found
P2P protocol state inconsistency between mempool announcement and inventory sequence tracking
Reliance on implicit side effect for security-relevant state update
Potential for follow-up GETDATA requests to be mishandled after BIP35 mempool response
Evidence from the diff
In PeerManagerImpl::SendMessages(), when handling a BIP35 mempool request (tx_relay->m_send_mempool), the code now explicitly sets tx_relay->m_last_inv_sequence to the current mempool sequence number before building the mempool inventory. This decouples the sequence bump from the normal INV broadcast path. The change is described as a clarity improvement, but it also closes a window where the sequence counter might not reflect the mempool announcement, potentially affecting how GETDATA responses are generated for the announced transactions.
Changed components
src/net_processing.cppBIP35 mempool message handlingtx_relay inventory sequence trackingInspect captured patch +4 / −0
diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index 27f0a63c..3397b388 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -6109,6 +6109,10 @@ bool PeerManagerImpl::SendMessages(CNode& node)
// Respond to BIP35 mempool requests
if (fSendTrickle && tx_relay->m_send_mempool) {
auto vtxinfo = m_mempool.infoAll();
+
+ // Ensure we'll respond to GETDATA requests for anything we're about to announce
+ tx_relay->m_last_inv_sequence = WITH_LOCK(m_mempool.cs, return m_mempool.GetSequence());
+
tx_relay->m_send_mempool = false;
const CFeeRate filterrate{tx_relay->m_fee_filter_received.load()};
Why this scored 35/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.