{ "number": 36429, "input_hash": "f605b8069c471997", "model": "ledger", "prompt_hash": null, "created": "2026-10-22T01:16:17+00:00", "result": { "summary": "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.", "card": "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.", "evidence": [ "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_notes": "Pending delayed transactions are held only in memory and are lost on node restarts or crashes.", "changed_since_previous": "No substantial design changes; rebased with minor refactors and tests retained.", "thread": { "last_event_at": "2026-10-21T12:09:53Z", "events": 9, "head_sha": "f692a4860b992005dc505e7c5f730dbbd143c9b1", "schema_floor": 2, "schema": 2 }, "waiting_on": [ { "at": "2026-10-21", "id": "c:6315408546", "on": "author", "url": "https://github.com/bitcoin/bitcoin/pull/36429#issuecomment-6315408546", "what": "reworking the PR to use nLockTime for scheduling and dropping random delay computation" } ], "risk": { "level": "medium", "touches": [ "rpc_api", "p2p" ], "why": "Bugs in release scheduling or delayed mempool validation could prevent transactions from broadcasting or unexpectedly drop user payments." }, "discussion": { "author_status": "last statement processed 2026-10-21", "open_concerns": [], "resolved_concerns": [ "vasild: Wallet transactions setting nLockTime to current block height defeat the privacy benefit of delayed broadcast (answered by optout21 2026-10-21)", "vasild: Delayed broadcast does not prevent transactions from being linked to the same node if send-to-all broadcast is used (answered by optout21 2026-10-06)", "vasild: Unbroadcast delayed transactions are lost if the node restarts (answered by optout21 2026-10-06)", "vasild: Questioned the description text regarding undo/cancel support (answered by optout21 2026-10-06)", "ismaelsadeeq: Consider having clients perform the broadcast delay themselves rather than adding delayed broadcast logic to the node (answered by optout21 2026-10-09)", "ismaelsadeeq: What is the concrete privacy gain and the harm in an attacker knowing the transaction creation time? (answered by optout21 2026-10-09)" ] }, "reviewability": { "state": "Ready", "label": "Ready", "reason": "Nothing known that would invalidate a review now." }, "agreement": { "state": "Neutral", "summary": "Neutral: objections settled, nobody has spoken for the PR", "reason": "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.", "evidence": [], "objections": [ { "reviewer": "vasild", "association": "MEMBER", "type": "objection", "kind": "safety", "harm": "Wallet transactions setting nLockTime to current block height defeat the privacy benefit of delayed broadcast", "request": "", "question": "", "text": "Wallet transactions setting nLockTime to current block height defeat the privacy benefit of delayed broadcast", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author agreed and plans to rework the feature to use nLockTime for scheduling", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6018323325", "c:6315555722" ], "evidence": "2026-10-06: 'Putting the current block height in `nLockTime` when the transaction is created defeats delaying its broadcast'", "url": "https://github.com/bitcoin/bitcoin/pull/36429#issuecomment-6017308339", "id": "c:6017308339", "at": "2026-10-06", "status_at": "2026-10-21", "status_by": "optout21", "resolution_evidence": "2026-10-21: optout21: '@vasild , thanks for this and previous feedback! I also arrived at the same conclusion, see the previous comment.'", "pin": null, "from_schema": 2 }, { "reviewer": "vasild", "association": "MEMBER", "type": "objection", "kind": "safety", "harm": "Delayed broadcast does not prevent transactions from being linked to the same node if send-to-all broadcast is used", "request": "", "question": "", "text": "Delayed broadcast does not prevent transactions from being linked to the same node if send-to-all broadcast is used", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author clarified delayed broadcast is only supported with private broadcast", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6018323325" ], "evidence": "2026-10-06: 'If send-to-all broadcast is used, then the otherwise unrelated transactions can be linked as coming from the same node.'", "url": "https://github.com/bitcoin/bitcoin/pull/36429#issuecomment-6017308339", "id": "c:6017308339#2", "at": "2026-10-06", "status_at": "2026-10-06", "status_by": "optout21", "resolution_evidence": "2026-10-06: optout21: 'delayed broadcast is available only in conjunction with private broadcast.'", "pin": null, "from_schema": 2 }, { "reviewer": "vasild", "association": "MEMBER", "type": "objection", "kind": "safety", "harm": "Unbroadcast delayed transactions are lost if the node restarts", "request": "", "question": "", "text": "Unbroadcast delayed transactions are lost if the node restarts", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author agreed queue persistence is important but suggested it for a followup", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6018323325" ], "evidence": "2026-10-06: 'The delay does not play nice with node restart (unbroadcast transactions would be lost).'", "url": "https://github.com/bitcoin/bitcoin/pull/36429#issuecomment-6017308339", "id": "c:6017308339#3", "at": "2026-10-06", "status_at": "2026-10-06", "status_by": "optout21", "resolution_evidence": "2026-10-06: optout21: 'Persisting the queue is an important feature, should be added (but I thing a followup is fine).'", "pin": null, "from_schema": 2 }, { "reviewer": "vasild", "association": "MEMBER", "type": "question", "kind": "interface", "harm": "", "request": "", "question": "Questioned the description text regarding undo/cancel support", "text": "Questioned the description text regarding undo/cancel support", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author explained it was an error in description and removed it", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6018323325" ], "evidence": "2026-10-06: 'Hmm?'", "url": "https://github.com/bitcoin/bitcoin/pull/36429#issuecomment-6017308339", "id": "c:6017308339#4", "at": "2026-10-06", "status_at": "2026-10-06", "status_by": "optout21", "resolution_evidence": "2026-10-06: optout21: 'Undo/Cancel support: that's a mistake in the description, removed'", "pin": null, "from_schema": 2 }, { "reviewer": "ismaelsadeeq", "association": "MEMBER", "type": "suggestion", "kind": "approach", "harm": "", "request": "Consider having clients perform the broadcast delay themselves rather than adding delayed broadcast logic to the node", "question": "", "text": "Consider having clients perform the broadcast delay themselves rather than adding delayed broadcast logic to the node", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author explained that client wallets are rarely always-on, making core a better place to handle delayed broadcasts", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6084992932" ], "evidence": "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.'", "url": "https://github.com/bitcoin/bitcoin/pull/36429#issuecomment-6032279563", "id": "c:6032279563", "at": "2026-10-07", "status_at": "2026-10-09", "status_by": "optout21", "resolution_evidence": "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 '", "pin": null, "from_schema": 2 }, { "reviewer": "ismaelsadeeq", "association": "MEMBER", "type": "question", "kind": "usefulness", "harm": "", "request": "", "question": "What is the concrete privacy gain and the harm in an attacker knowing the transaction creation time?", "text": "What is the concrete privacy gain and the harm in an attacker knowing the transaction creation time?", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author provided concrete scenarios including breaking timing correlation with external events and scheduling transfers", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6084992932" ], "evidence": "2026-10-07: 'What is the concrete privacy gain? What's the actual harm in an attacker knowing the creation time?'", "url": "https://github.com/bitcoin/bitcoin/pull/36429#issuecomment-6032279563", "id": "c:6032279563#2", "at": "2026-10-07", "status_at": "2026-10-09", "status_by": "optout21", "resolution_evidence": "2026-10-09: optout21: 'Transactions related to specific events could be probabilistically matched based on timing analysis. To avoid that, the '", "pin": null, "from_schema": 2 } ], "support": [], "participants": [ { "login": "vasild", "stance": "objection", "note": "objected that nLockTime defeats privacy, restart loses delayed transactions, and transactions can be linked without private broadcast; supported using nLockTime for broadcast timing", "association": "MEMBER", "comments": 2, "first": "2026-10-06", "last": "2026-10-21" }, { "login": "ismaelsadeeq", "stance": "question", "note": "questioned whether clients should handle delays instead and asked for concrete privacy gains", "association": "MEMBER", "comments": 1, "first": "2026-10-07", "last": "2026-10-07" } ], "derivation": "objections settled, nobody has spoken for the PR", "model_state": null, "corrections": [], "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." }, "dependencies": { "depends_on": [], "enables": [] }, "categories": [ { "name": "docs", "member": false, "evidence": "Only updates release notes (`doc/release-notes-delayed-private-broadcast.md`) following the code change.", "band": "Unranked", "reason_tag": "cleanup", "score": 0.0, "factors": { "bug_severity": 0, "leverage": 0, "performance": 0, "security_stability": 1, "user_value": 1 }, "rationale": "Release note updates that merely follow from a feature change do not make the PR a documentation PR." }, { "name": "p2p", "member": true, "evidence": "Modifies `src/private_broadcast.*` and `src/net_processing.*` to queue and add randomized jitter to private transaction broadcast.", "band": "P3", "reason_tag": "new feature", "score": 0.4, "factors": { "bug_severity": 0, "leverage": 0, "performance": 0, "security_stability": 1, "user_value": 1 }, "rationale": "Mitigating timing correlation on transaction broadcast provides useful origin privacy, but the author-proposed delay mechanism is an uncorroborated RFC that is reasonably deferrable." }, { "name": "rpc", "member": true, "evidence": "Adds the optional `delay_for` parameter and argument handling to `sendrawtransaction` in `src/rpc/mempool.cpp`.", "band": "P4", "reason_tag": "new feature", "score": 0.2, "factors": { "bug_severity": 0, "leverage": 0, "performance": 0, "security_stability": 1, "user_value": 1 }, "rationale": "New RPC parameters without documented external consumer demand rank low in the RPC category." }, { "name": "tests", "member": false, "evidence": "Changes unit, functional, and fuzz test files specifically for delayed private broadcast rather than test framework machinery.", "band": "Unranked", "reason_tag": "test coverage", "score": 0.0, "factors": { "bug_severity": 0, "leverage": 0, "performance": 0, "security_stability": 1, "user_value": 1 }, "rationale": "Tests that pin the behavior of a specific subsystem belong to that subsystem rather than test infrastructure." }, { "name": "utils", "member": false, "evidence": "Does not modify shared utilities, logging, or cryptographic primitives; the randomized jitter merely consumes existing randomness utilities.", "band": "Unranked", "reason_tag": "cleanup", "score": 0.0, "factors": { "bug_severity": 0, "leverage": 0, "performance": 0, "security_stability": 1, "user_value": 1 }, "rationale": "Not a member of utils because the PR does not change shared utility libraries or node-wide infrastructure." } ], "confidence": "high", "uncertainties": [], "needs": [] }, "cost_usd": 0.0, "source": { "record": "2026-10-22T01:16:17+00:00", "code": "2026-10-07T01:16:02+00:00", "judgments": 5 } }