#36429 [RFC] Delayed transaction broadcast, minimal
| Reviewability | Reviews | Agreement | Size | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| #36429 [RFC] Delayed transaction broadcast, minimal | Ready | 0 | Neutral | 229 + 259 tests | ||||||
|
|
|
|
| ||||||
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
Adds an optional `delay_for` parameter to the `sendrawtransaction` RPC to postpone broadcasting transactions submitted via private broadcast. Delayed transactions are queued in memory with added randomized jitter (between 5 minutes and 50% of the requested delay, up to a 12-hour cap) and released by a periodic scheduler task after re-validating against the mempool.
Problem: Immediate broadcast allows network observers to correlate transaction submission timing with off-chain user activity or specific events. Users currently have no built-in way to schedule or jitter private transaction announcements without using external cron jobs or custom scripts.
Evidence of importance:
- PR description: 'The aim is increased privacy, by making time-correlation-based tracking more difficult. This fits together with private broadcast: private connection broadcast tries to hide the originator node; randomized delay tries to hide the creation time.' (author claim, uncorroborated by linked issues)
Scope: Pending delayed transactions are held only in memory and are lost on node restarts or crashes.
Risk of a mistake: medium (rpc_api, p2p). Bugs in release scheduling or delayed mempool validation could prevent transactions from broadcasting or unexpectedly drop user payments.
Changed since the previous assessment: No substantial design changes; rebased with minor refactors and tests retained.
Reviewability
Ready
Nothing known that would invalidate a review now.
Waiting on (from the thread read):
- author: reworking the PR to use nLockTime for scheduling and dropping random delay computation 2026-10-21
Agreement
Neutral
objections settled, nobody has spoken for the PR
Thread notes: vasild reiterated that nLockTime defeats delayed broadcast privacy and supported using nLockTime to decide when to send. optout21 concurred and announced plans to rework the PR to base scheduling on nLockTime and drop random delay.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| vasild (member) | objection, safety | Wallet transactions setting nLockTime to current block height defeat the privacy benefit of delayed broadcast | answered · author agreed and plans to rework the feature to use nLockTime for scheduling | answered | yes | 2026-10-06: 'Putting the current block height in `nLockTime` when the transaction is created defeats delaying its broadcast' Status from: 2026-10-21: optout21: '@vasild , thanks for this and previous feedback! I also arrived at the same conclusion, see the previous comment.' |
| vasild (member) | objection, safety | Delayed broadcast does not prevent transactions from being linked to the same node if send-to-all broadcast is used | answered · author clarified delayed broadcast is only supported with private broadcast | answered | yes | 2026-10-06: 'If send-to-all broadcast is used, then the otherwise unrelated transactions can be linked as coming from the same node.' Status from: 2026-10-06: optout21: 'delayed broadcast is available only in conjunction with private broadcast.' |
| vasild (member) | objection, safety | Unbroadcast delayed transactions are lost if the node restarts | answered · author agreed queue persistence is important but suggested it for a followup | answered | yes | 2026-10-06: 'The delay does not play nice with node restart (unbroadcast transactions would be lost).' Status from: 2026-10-06: optout21: 'Persisting the queue is an important feature, should be added (but I thing a followup is fine).' |
| vasild (member) | question, interface | Questioned the description text regarding undo/cancel support | answered · author explained it was an error in description and removed it | answered | yes | 2026-10-06: 'Hmm?' Status from: 2026-10-06: optout21: 'Undo/Cancel support: that's a mistake in the description, removed' |
| ismaelsadeeq (member) | suggestion, approach | Consider having clients perform the broadcast delay themselves rather than adding delayed broadcast logic to the node | answered · author explained that client wallets are rarely always-on, making core a better place to handle delayed broadcasts | answered | yes | 2026-10-07: 'the delay itself seems like something a client can already do: sleep for a random time, then call sendrawtransaction on a node running with -privatebroadcast.' Status from: 2026-10-09: optout21: 'That's true, most client could do the delay themselves ... However, many clients can not do this easily, as wallets are ' |
| ismaelsadeeq (member) | question, usefulness | What is the concrete privacy gain and the harm in an attacker knowing the transaction creation time? | answered · author provided concrete scenarios including breaking timing correlation with external events and scheduling transfers | answered | yes | 2026-10-07: 'What is the concrete privacy gain? What's the actual harm in an attacker knowing the creation time?' Status from: 2026-10-09: optout21: 'Transactions related to specific events could be probabilistically matched based on timing analysis. To avoid that, the ' |
Participants:
- vasild (member, objection, 2 statements 2026-10-06 to 2026-10-21): objected that nLockTime defeats privacy, restart loses delayed transactions, and transactions can be linked without private broadcast; supported using nLockTime for broadcast timing
- ismaelsadeeq (member, question, 1 statements 2026-10-07 to 2026-10-07): questioned whether clients should handle delays instead and asked for concrete privacy gains
Files
261 lines under test/bench/ci.
- src/test/private_broadcast_tests.cpp +145/-0
- test/functional/p2p_private_broadcast.py +111/-0
- src/private_broadcast.h +62/-10
- src/private_broadcast.cpp +52/-8
- src/net_processing.cpp +56/-3
- src/rpc/mempool.cpp +29/-1
- doc/release-notes-delayed-private-broadcast.md +14/-0
- src/node/transaction.cpp +5/-2
- src/node/transaction.h +6/-1
- src/net_processing.h +4/-1
- src/test/fuzz/p2p_private_broadcast.cpp +3/-2
- src/rpc/client.cpp +1/-0
Card
The short text the ranking pass compares across PRs.
This PR adds an optional delay_for parameter to sendrawtransaction to delay private broadcast by a requested duration plus randomized jitter. Delayed transactions are stored in-memory and re-evaluated with test-accept validation against the mempool before outbound Tor or I2P connections are opened. All motivation comes from author claims regarding time-correlation privacy without linked issues. Pending transactions are not persisted across node restarts.
Data
thread read through 2026-10-21 (9 statements), head f692a4860b
labels: none · draft
Categories
P2P
P4 · new feature (assessed alone as P3; Demoted to P4: speculative RFC with author-only motivation that overlaps the randomized scheduling already part of the private broadcast rework.)
Mitigating timing correlation on transaction broadcast provides useful origin privacy, but the author-proposed delay mechanism is an uncorroborated RFC that is reasonably deferrable.
Membership: Modifies `src/private_broadcast.*` and `src/net_processing.*` to queue and add randomized jitter to private transaction broadcast.
Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 0
RPC / REST / ZMQ
P4 · new feature
New RPC parameters without documented external consumer demand rank low in the RPC category.
Membership: Adds the optional `delay_for` parameter and argument handling to `sendrawtransaction` in `src/rpc/mempool.cpp`.
Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 0