#34707 net: keep finished private broadcast txs in memory

full analysis

https://github.com/bitcoin/bitcoin/pull/34707 · andrewtoth · +275/-68 in 8 files, 4 commits · labels: P2P, Private Broadcast

Goal

  • Allow node operators and callers to confirm successful private broadcast roundtrips via RPC
  • Prevent private broadcast status from disappearing immediately once received back from peers

This PR retains privately broadcast transactions in memory after they have been received back from network peers instead of removing them immediately. It records the receiving peer address and timestamp, exposes this data through getprivatebroadcastinfo RPC, marks transactions non-pending so they are not rebroadcast, and evicts the oldest finished entries when the queue reaches the 10,000 transaction cap.

Problem: Previously, privately broadcast transactions were removed from memory as soon as they were received back from the network. Downstream callers and node operators querying getprivatebroadcastinfo could not distinguish between a successful broadcast, an unqueued transaction, or an interrupted broadcast.

Category: P2P (#37 of 65)

P3 · new feature

  • P3 because telemetry and status reporting benefits are limited to optional private broadcast
  • Operators and wallet software can verify roundtrip relay without relying on debug logs
  • It does not directly improve core network reliability or DoS resistance

P3 because it adds useful telemetry and status reporting to the private broadcast subsystem, allowing node operators and wallet software to confirm roundtrip relay without relying on debug logs. It does not address network reliability or DoS resistance directly, and its scope remains limited to the optional private broadcast feature.

Membership: Modifies private transaction broadcast queue management and peer relay tracking in src/private_broadcast.cpp and src/net_processing.cpp.

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

Reviewability: Ready

  • Ready for review with passing CI and clean merge status

The PR has passing CI, clean merge status, and is ready for reviewer feedback.

Author status: Active; responded to reviews and solicited re-reviews in mid-September 2026.

Open concerns:

  • instagibbs concept NACKed, arguing the change adds complexity and memory retention for a narrow set of users, and that private broadcast should not expand into an omni-broadcast or rebroadcast queue.
  • optout21 noted a minor edge case where the queue cap eviction logic uses an if rather than a while loop.

Resolved concerns:

  • Queue memory growth risk was addressed by evicting the oldest non-pending transactions when the queue is full at 10,000 transactions.
  • Fixed an issue where attempts_remaining was not set to 0 once a transaction was received back.
  • Addressed test coverage and fuzz harness updates to reflect the new non-pending eviction mechanics.

Agreement: Disputed

  • Concept objection: adds complexity and memory retention for a narrow set of users (instagibbs)
  • Warns that private broadcast should not expand into general rebroadcast logic (instagibbs)
  • Strong support because retaining roundtrip stats fixes missing RPC diagnostics (vasild)
  • Support because received peer info is useful for client applications (optout21)

Concept NACK from instagibbs over scope and memory retention; ACKs from vasild and optout21.

instagibbs logged a concept NACK questioning whether holding transactions in memory for diagnostics is worth the complexity and expanded role of private broadcast. vasild strongly supports retaining roundtrip stats for RPC callers and operators, and optout21 supports the change.

  • instagibbs: 'concept NACK for now. I'm not persuaded this change is net positive. An average user simply will not need this feature... I do not think private broadcast should become some omni broadcast logic'
  • vasild: 'ACK 9217011129... IMO it "falls flat" because the stats disappear once the transaction comes back and the best way to improve that is to not remove them from the RPC output like this PR does'
  • optout21: 'ACK 9217011129... The received info can be useful for some clients... Overall, I'm for it.'

Review verdicts (DrahtBot): 2 (+1) -1

Files

219 lines under test/bench/ci.

  • src/test/private_broadcast_tests.cpp +132/-18
  • src/test/fuzz/private_broadcast.cpp +37/-23
  • src/private_broadcast.h +43/-15
  • src/private_broadcast.cpp +31/-5
  • src/rpc/mempool.cpp +15/-3
  • doc/release-notes-34707.md +10/-0
  • test/functional/p2p_private_broadcast.py +6/-3
  • src/net_processing.cpp +1/-1

Card

This PR retains privately broadcast transactions in memory after they are received back from peers instead of removing them, recording the receiving peer address and reception time for inspection via getprivatebroadcastinfo. This gives node operators and external wallets visibility into whether private broadcast succeeded and what roundtrip latency looked like. The change is disputed, with a concept NACK from instagibbs over memory state and expanding private broadcast scope, balanced by ACKs from vasild and optout21. The branch is clean, has active reviewer interest, and is ready for review.

Data

dossier JSON · extract JSON · model openrouter/google/gemini-3.8-flash, generated 2026-09-17T16:17, confidence high, input hash 2bf19eff57cf20f6