{ "number": 36628, "input_hash": "e69d3be7e29591ff", "model": "ledger", "prompt_hash": null, "created": "2026-11-02T01:12:08+00:00", "result": { "summary": "Replaces the `-privatebroadcast` implementation with isolated, stateless background jobs managed under a new `src/privbcast` module. Submitted transactions bypass the local mempool and connection manager, running on dedicated threads that resolve DNS seeds via Tor and announce transactions over BIP324 on a fixed schedule using isolated proxy credentials for every connection. Completely removes legacy `ConnectionType::PRIVATE_BROADCAST` connections, retry tasks, and special-case handling from `CConnman` and `PeerManager`.", "problem": "The existing private broadcast mechanism was intertwined with the node's main connection manager and peer logic, introducing special cases across addrman, peer discouragement, and connection tracking. This coupling risked deanonymization and IP linkage through shared node state while complicating maintainability of core P2P networking.", "card": "Replaces the existing private broadcast subsystem with isolated, stateless background jobs managed under a new src/privbcast module. When -privatebroadcast is enabled, transactions bypass the local mempool and connection manager, executing on dedicated threads that discover peers via DNS seeds and announce over BIP324 strictly through Tor using isolated proxy credentials and a fixed schedule. This eliminates IP linkage and node-state correlation vectors while removing invasive private-broadcast special-case logic from CConnman and PeerManager. It unblocks follow-up package relay support for private broadcast in #36608.", "evidence": [ "PR description: 'test profile focusing on protecting aginst IP address linkage and not crashing the node on adversarial inputs (which is a leak in itself)'", "Commit 03435a45ef: 'The plan is drawn when the job is made, before any socket exists... slots share only the loop, so a stalled stream holds up no other slot'", "PR description: 'Split out of #36608, the overall private broadcast rework to support ease of review for like-for-like feature.'" ], "scope_notes": "Very large diff (+6341/-3046 across 78 files) that adds a standalone byte-driven SOCKS5 and BIP324 network engine in src/privbcast/, introduces a formal invariant specification in doc/design/private-broadcast.md, and removes hundreds of lines of legacy private broadcast plumbing from net.cpp and net_processing.cpp.", "changed_since_previous": "Rebased onto newer master commits; the core architecture, specification, and module structure remain identical.", "thread": { "last_event_at": "2026-11-01T15:58:23Z", "events": 28, "head_sha": "8e34f760586c927883bdefae6eac1dce4aea6e3d", "schema_floor": 2, "schema": 2 }, "waiting_on": [ { "at": "2026-11-01", "id": "c:6560319962", "on": "author", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6560319962", "what": "push promised comment fix and address design direction / external hook proposal" } ], "risk": { "level": "medium", "touches": [ "p2p", "rpc_api" ], "why": "Flaws in the isolated proxy or P2P state machine could deanonymize user transactions or exhaust system file descriptors." }, "discussion": { "author_status": "last statement processed 2026-11-01", "open_concerns": [ "vasild: Relying permanently on centralized DNS seeds for each private broadcast creates a single point of failure and makes the feature vulnerable to outages or censorship.", "vasild: Broadcasting exclusively to IP peers via Tor makes private broadcast fragile to Tor outages and exit node failures, lacking an I2P fallback.", "vasild: Restricting broadcast recipients to IP peers degrades network-wide privacy by preventing Tor and I2P nodes from acting as indistinguishable recipients.", "ajtowns: Correct or remove misleading comment regarding protocol version tracking across releases", "ajtowns: Abandon in-node private broadcast, deprecate the existing feature, and provide hooks for external broadcast tools instead" ], "resolved_concerns": [ "fametrano: Tests do not verify that attempts use unique nonces and BIP324 keys, allowing regressions that let recipients link broadcasts to pass undetected. (answered by instagibbs 2026-10-26)", "andrewtoth: How peers can be influenced into dialing fingerprinting peers, and whether that can be fixed upstream in addrman (answered by instagibbs 2026-10-27)", "andrewtoth: How an I2P sybil attack leaks a clearnet IP address, and how sybiling affects sending transactions through ephemeral I2P tunnels (answered by instagibbs 2026-10-27)", "andrewtoth: What specific attacks the current private broadcast implementation cannot resist (answered by instagibbs 2026-10-27)", "ajtowns: Publish the design as a BIP or post to the mailing list for broader discussion on design tradeoffs (answered by instagibbs 2026-10-27)", "ajtowns: Implement private broadcast as a separate binary interacting lightly with the node rather than in-process jobs (answered by instagibbs 2026-10-27)", "ajtowns: Rewrite design doc to provide a high-level summary and avoid unnecessary jargon (answered by instagibbs 2026-10-28)", "ajtowns: Consider adding only a hook and letting the private broadcast implementation live out of tree given low transaction usage (answered by instagibbs 2026-10-28)", "andrewtoth: Do not use built-in DNS seeds to source addresses for private broadcast, and do not drop I2P or direct Tor onion connections (answered by instagibbs 2026-10-29)", "ajtowns: Use MSG_TX and do not send wtxidrelay to maintain a larger anonymity set matching current code (answered by instagibbs 2026-10-28)" ] }, "reviewability": { "state": "Ready", "label": "Needs rebase", "reason": "Conflicts with master; review the logic now, the rebase is mechanical." }, "agreement": { "state": "Mild", "summary": "Mild: objection that needs a change was answered, no reply from the objector (vasild: Relying permanently on centralized DNS seeds for each private broadcast creates a single point of failure and makes the ; vasild: Broadcasting exclusively to IP peers via Tor makes private broadcast fragile to Tor outages and exit node failures, lack; vasild: Restricting broadcast recipients to IP peers degrades network-wide privacy by preventing Tor and I2P nodes from acting a)", "reason": "ajtowns reiterated their suggestion to deprecate the existing in-node feature and provide hooks for external tools rather than reviewing a large PR with competing design approaches.", "evidence": [ "vasild (objection, approach, must be changed, answered): Relying permanently on centralized DNS seeds for each private broadcast creates a single point of failure and makes the feature vulnerable to outages or censorship.", "vasild (objection, safety, must be changed, answered): Broadcasting exclusively to IP peers via Tor makes private broadcast fragile to Tor outages and exit node failures, lacking an I2P fallback.", "vasild (objection, safety, must be changed, answered): Restricting broadcast recipients to IP peers degrades network-wide privacy by preventing Tor and I2P nodes from acting as indistinguishable recipients.", "ajtowns (suggestion, correctness, must be changed, answered): Correct or remove misleading comment regarding protocol version tracking across releases", "ajtowns (suggestion, approach, must be answered, contested): Abandon in-node private broadcast, deprecate the existing feature, and provide hooks for external broadcast tools instead", "darosior: Concept ACK", "darosior: support \u2014 Isolating private broadcast connections from node state is the only way to avoid correlation leaks with clearnet connections; master's implementation is an active footgun that worsens privacy once adversaries correlate recipient slots", "darosior: support \u2014 Favored salvaging private broadcast in-tree rather than deprecating it, so node distributions can enable it to produce false positives against transaction origin analysis" ], "objections": [ { "reviewer": "fametrano", "association": "NONE", "type": "objection", "kind": "safety", "harm": "Tests do not verify that attempts use unique nonces and BIP324 keys, allowing regressions that let recipients link broadcasts to pass undetected.", "request": "", "question": "", "text": "Tests do not verify that attempts use unique nonces and BIP324 keys, allowing regressions that let recipients link broadcasts to pass undetected.", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author initially deferred but edited reply stating they changed their mind and brought it forward", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6405247174" ], "evidence": "2026-10-25: 'This PR's tests do not check that each attempt gets its own VERSION nonce, PING nonce and BIP324 key (A4 in `doc/design/private-broadcast.md`), so a regression there would pass.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6397196009", "id": "c:6397196009", "at": "2026-10-25", "status_at": "2026-10-26", "status_by": "instagibbs", "resolution_evidence": "2026-10-26: instagibbs: 'changed my mind and brought it forward'", "pin": null, "from_schema": 2 }, { "reviewer": "vasild", "association": "MEMBER", "type": "objection", "kind": "approach", "harm": "Relying permanently on centralized DNS seeds for each private broadcast creates a single point of failure and makes the feature vulnerable to outages or censorship.", "request": "", "question": "", "text": "Relying permanently on centralized DNS seeds for each private broadcast creates a single point of failure and makes the feature vulnerable to outages or censorship.", "clears_with": "change", "blocking": true, "status": "answered", "status_note": "author replied explaining seed downtime only stops broadcasts without leaking identity, whereas addrman introduces sybil leaks", "cleared": false, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6424580079" ], "evidence": "2026-10-26: 'I do not think that it is reasonable to start relying on a few servers permanently (not just once in a lifetime, but every time a node wants to privately broadcast a transaction).'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6413061893", "id": "c:6413061893", "at": "2026-10-26", "status_at": "2026-10-26", "status_by": "instagibbs", "resolution_evidence": "2026-10-26: instagibbs: 'If the seeds go offline, private broadcast stops; it doesn't leak.'", "pin": null, "from_schema": 2 }, { "reviewer": "vasild", "association": "MEMBER", "type": "objection", "kind": "safety", "harm": "Broadcasting exclusively to IP peers via Tor makes private broadcast fragile to Tor outages and exit node failures, lacking an I2P fallback.", "request": "", "question": "", "text": "Broadcasting exclusively to IP peers via Tor makes private broadcast fragile to Tor outages and exit node failures, lacking an I2P fallback.", "clears_with": "change", "blocking": true, "status": "answered", "status_note": "author replied that Tor privacy outweighs its centralization and gathering addresses without seeder nodes reintroduces leaks", "cleared": false, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6424580079" ], "evidence": "2026-10-26: 'Only broadcasting to IP peers via the Tor network would make the feature too fragile - it would rely on the Tor network and the Tor exit nodes working properly.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6413061893", "id": "c:6413061893#2", "at": "2026-10-26", "status_at": "2026-10-26", "status_by": "instagibbs", "resolution_evidence": "2026-10-26: instagibbs: 'Tor isn't decentralized either, but we accept utility in terms of privacy.'", "pin": null, "from_schema": 2 }, { "reviewer": "vasild", "association": "MEMBER", "type": "objection", "kind": "safety", "harm": "Restricting broadcast recipients to IP peers degrades network-wide privacy by preventing Tor and I2P nodes from acting as indistinguishable recipients.", "request": "", "question": "", "text": "Restricting broadcast recipients to IP peers degrades network-wide privacy by preventing Tor and I2P nodes from acting as indistinguishable recipients.", "clears_with": "change", "blocking": true, "status": "answered", "status_note": "author replied that master's recipient model allows easy sybiling leading to IP leaks and offers limited attack resistance", "cleared": false, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6424580079" ], "evidence": "2026-10-26: 'Even moderate adoption of private broadcast in its current form improves the privacy of everybody because everybody could be a recipient. ... That would be spoiled if we only send to IP peers.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6413061893", "id": "c:6413061893#3", "at": "2026-10-26", "status_at": "2026-10-26", "status_by": "instagibbs", "resolution_evidence": "2026-10-26: instagibbs: 'The attacks it resists are quite limited today, and therefore it's sort of in purgatory where we can't make any promises'", "pin": null, "from_schema": 2 }, { "reviewer": "andrewtoth", "association": "MEMBER", "type": "question", "kind": "approach", "harm": "", "request": "", "question": "How peers can be influenced into dialing fingerprinting peers, and whether that can be fixed upstream in addrman", "text": "How peers can be influenced into dialing fingerprinting peers, and whether that can be fixed upstream in addrman", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author explained addrman design goals differ and allowing peers to write to it enables fingerprinting", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6449752844" ], "evidence": "2026-10-27: 'Can this design be expanded on about how they can be influenced, and why that is by design? Would this mean the problem is with the design that allows peers to be influenced into dialing to peers that'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6446074543", "id": "c:6446074543", "at": "2026-10-27", "status_at": "2026-10-27", "status_by": "instagibbs", "resolution_evidence": "2026-10-27: instagibbs: 'Addrman is built for partition resistance... private broadcast loses privacy to one dishonest peer that can \"read\" these'", "pin": null, "from_schema": 2 }, { "reviewer": "andrewtoth", "association": "MEMBER", "type": "question", "kind": "safety", "harm": "", "request": "", "question": "How an I2P sybil attack leaks a clearnet IP address, and how sybiling affects sending transactions through ephemeral I2P tunnels", "text": "How an I2P sybil attack leaks a clearnet IP address, and how sybiling affects sending transactions through ephemeral I2P tunnels", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author explained small I2P population facilitates sybiling recipient slots and correlating clearnet probes", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6449752844" ], "evidence": "2026-10-27: 'Would that be a problem with i2p in general, and not private broadcast? I'm not sure I understand how a sybil attack in i2p could leak a clearnet IP address.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6446074543", "id": "c:6446074543#2", "at": "2026-10-27", "status_at": "2026-10-27", "status_by": "instagibbs", "resolution_evidence": "2026-10-27: instagibbs: 'The population of i2p is small, ... Once the attacker is a recipient, it can act on a suspect over clearnet before, duri'", "pin": null, "from_schema": 2 }, { "reviewer": "andrewtoth", "association": "MEMBER", "type": "question", "kind": "safety", "harm": "", "request": "", "question": "What specific attacks the current private broadcast implementation cannot resist", "text": "What specific attacks the current private broadcast implementation cannot resist", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author enumerated past CVE-like fixes and detailed the active adversary model that correlates recipient slots to clearnet probes", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6449752844" ], "evidence": "2026-10-27: 'Since we no longer make any promises, and this is marked experimental, can we elaborate on the attacks it cannot resist?'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6446074543", "id": "c:6446074543#3", "at": "2026-10-27", "status_at": "2026-10-27", "status_by": "instagibbs", "resolution_evidence": "2026-10-27: instagibbs: 'The fixes so far: #35032 (addrman updated from private connections), #35410 (v1 retry went over clearnet), #36277 (what '", "pin": null, "from_schema": 2 }, { "reviewer": "ajtowns", "association": "MEMBER", "type": "suggestion", "kind": "approach", "harm": "", "request": "Publish the design as a BIP or post to the mailing list for broader discussion on design tradeoffs", "question": "", "text": "Publish the design as a BIP or post to the mailing list for broader discussion on design tradeoffs", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author agreed on value in wider discussion and noted the current implementation also bypassed the BIP process", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6442248434" ], "evidence": "2026-10-27: 'Shouldn't it be a BIP, or at least posted to the mailing list for broader discussion on exactly the sort of tradeoffs vasild raises above?'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#pullrequestreview-5662068682", "id": "r:5662068682", "at": "2026-10-27", "status_at": "2026-10-27", "status_by": "instagibbs", "resolution_evidence": "2026-10-27: instagibbs: 'I think there's definitely value increasing anonymity set if nothing else. By the same token, the current implementation'", "pin": null, "from_schema": 2 }, { "reviewer": "ajtowns", "association": "MEMBER", "type": "suggestion", "kind": "approach", "harm": "", "request": "Implement private broadcast as a separate binary interacting lightly with the node rather than in-process jobs", "question": "", "text": "Implement private broadcast as a separate binary interacting lightly with the node rather than in-process jobs", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author replied that they originally designed it as a separate tool but aimed for a like-for-like replacement in bitcoind, while noting the code structure supports separation", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6442248434" ], "evidence": "2026-10-27: 'If the idea is to separate this from the node, it seems like having a separate binary interacting lightly with the node might be a better structure.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#pullrequestreview-5662068682", "id": "r:5662068682#2", "at": "2026-10-27", "status_at": "2026-10-27", "status_by": "instagibbs", "resolution_evidence": "2026-10-27: instagibbs: 'Originally I designed it as a separate tool, but I was hoping for a like-for-like replacement. However the architecture '", "pin": null, "from_schema": 2 }, { "reviewer": "ajtowns", "association": "MEMBER", "type": "suggestion", "kind": "correctness", "harm": "", "request": "Correct or remove misleading comment regarding protocol version tracking across releases", "question": "", "text": "Correct or remove misleading comment regarding protocol version tracking across releases", "clears_with": "change", "blocking": true, "status": "answered", "status_note": "author agreed the comment was bad and unnecessary and promised to change it", "cleared": false, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "rc:4392392587" ], "evidence": "2026-10-27: '70016 is what current private broadcast versions track, and avoiding varying these things across releases is exactly why we have a special profile.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#discussion_r4384957876", "id": "rc:4384957876", "at": "2026-10-27", "status_at": "2026-10-27", "status_by": "instagibbs", "resolution_evidence": "2026-10-27: instagibbs: 'yeah this is a bad comment and probably not needed, it should *not* update as a profile break which is what the static a'", "pin": null, "from_schema": 2 }, { "reviewer": "ajtowns", "association": "MEMBER", "type": "suggestion", "kind": "maintenance", "harm": "", "request": "Rewrite design doc to provide a high-level summary and avoid unnecessary jargon", "question": "", "text": "Rewrite design doc to provide a high-level summary and avoid unnecessary jargon", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author agreed a hand-written design doc not targeting reimplementation is worth writing", "cleared": true, "author_replied": true, "others_replied": true, "fix_pushed": false, "replies": [ "c:6476284152", "c:6474536731" ], "evidence": "2026-10-28: 'FWIW, it feels overly long, and poorly focused to me; same as most AI spec work. It doesn't really give you a TLDR high-level summary, mixes high level and low level stuff in the same sentence, and ma'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6459225489", "id": "c:6459225489", "at": "2026-10-28", "status_at": "2026-10-28", "status_by": "instagibbs", "resolution_evidence": "2026-10-28: instagibbs: 'Definitely worth putting in a hand-written design doc that's not targeting reimplementation'", "pin": null, "from_schema": 2 }, { "reviewer": "ajtowns", "association": "MEMBER", "type": "suggestion", "kind": "usefulness", "harm": "", "request": "Consider adding only a hook and letting the private broadcast implementation live out of tree given low transaction usage", "question": "", "text": "Consider adding only a hook and letting the private broadcast implementation live out of tree given low transaction usage", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author argued the reimplementation is far easier to reason about than master, or else private broadcast should be removed entirely", "cleared": true, "author_replied": true, "others_replied": true, "fix_pushed": false, "replies": [ "c:6469961979", "c:6474536731" ], "evidence": "2026-10-28: 'That usage level doesn't feel like it warrants huge PRs to me. Could also plausibly just add the hook, and let the implementation live entirely out of tree, with any privacy issues dealt with external'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6459225489", "id": "c:6459225489#2", "at": "2026-10-28", "status_at": "2026-10-28", "status_by": "instagibbs", "resolution_evidence": "2026-10-28: instagibbs: 'If that's \"too much work\", we should remove it entirely, replaced with maybe a hook like you say.'", "pin": null, "from_schema": 2 }, { "reviewer": "andrewtoth", "association": "MEMBER", "type": "suggestion", "kind": "approach", "harm": "", "request": "Do not use built-in DNS seeds to source addresses for private broadcast, and do not drop I2P or direct Tor onion connections", "question": "", "text": "Do not use built-in DNS seeds to source addresses for private broadcast, and do not drop I2P or direct Tor onion connections", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author defended using DNS seeds as a liveness requirement to fit a definable, auditable security model", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "c:6504882857" ], "evidence": "2026-10-28: 'I don't think using the built-in DNS seeds to source addresses for private broadcast is the right approach, and I don't think we should drop i2p or direct tor onion connections.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6476783810", "id": "c:6476783810", "at": "2026-10-28", "status_at": "2026-10-29", "status_by": "instagibbs", "resolution_evidence": "2026-10-29: instagibbs: 'I'm currently putting DNS seeds as a liveness requirement for a privacy tool.'", "pin": null, "from_schema": 2 }, { "reviewer": "ajtowns", "association": "MEMBER", "type": "suggestion", "kind": "approach", "harm": "", "request": "Use MSG_TX and do not send wtxidrelay to maintain a larger anonymity set matching current code", "question": "", "text": "Use MSG_TX and do not send wtxidrelay to maintain a larger anonymity set matching current code", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author explained wtxidrelay is intentional to support package relay and avoid future profile breaks", "cleared": true, "author_replied": true, "others_replied": false, "fix_pushed": false, "replies": [ "rc:4400855928" ], "evidence": "2026-10-28: 'Using `MSG_TX` and not sending wtxidrelay (matching the current code) seems likely to have a larger anonymity set, without losing any meaningful performance afaics.'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#discussion_r4397140258", "id": "rc:4397140258", "at": "2026-10-28", "status_at": "2026-10-28", "status_by": "instagibbs", "resolution_evidence": "2026-10-28: instagibbs: 'There's massive profile breaks everywhere in this PR. If we're going to break it, now is the time'", "pin": null, "from_schema": 2 }, { "reviewer": "ajtowns", "association": "MEMBER", "type": "suggestion", "kind": "approach", "harm": "", "request": "Abandon in-node private broadcast, deprecate the existing feature, and provide hooks for external broadcast tools instead", "question": "", "text": "Abandon in-node private broadcast, deprecate the existing feature, and provide hooks for external broadcast tools instead", "clears_with": "answer", "blocking": false, "status": "contested", "status_note": "ajtowns pushed back against in-node reimplementation, arguing for deprecation and external hooks", "cleared": false, "author_replied": false, "others_replied": true, "fix_pushed": false, "replies": [ "c:6503707596" ], "evidence": "2026-10-29: 'abandon the approach of in-node support for private broadcast -- there's too much risk of state contamination that defeats the entire purpose of the feature for realistic adversarial scenarios'", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6488628925", "id": "c:6488628925", "at": "2026-10-29", "status_at": "2026-10-30", "status_by": "ajtowns", "resolution_evidence": "2026-10-30: ajtowns: 'You should be able to conceive of the possibility of a theoretical attack being made both more more impactful and more p'", "pin": null, "from_schema": 2 } ], "support": [ { "reviewer": "darosior", "reason": "", "substantive": false, "verdict": "Concept ACK", "id": "c:6445520943", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6445520943", "at": "2026-10-27", "association": "MEMBER", "evidence": "none", "areas": [] }, { "reviewer": "darosior", "reason": "Isolating private broadcast connections from node state is the only way to avoid correlation leaks with clearnet connections; master's implementation is an active footgun that worsens privacy once adversaries correlate recipient slots", "substantive": true, "verdict": "", "id": "c:6474536731", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6474536731", "at": "2026-10-28", "association": "MEMBER", "evidence": "read", "areas": [ "private broadcast" ] }, { "reviewer": "darosior", "reason": "Favored salvaging private broadcast in-tree rather than deprecating it, so node distributions can enable it to produce false positives against transaction origin analysis", "substantive": true, "verdict": "", "id": "c:6503707596", "url": "https://github.com/bitcoin/bitcoin/pull/36628#issuecomment-6503707596", "at": "2026-10-29", "association": "MEMBER", "evidence": "read", "areas": [ "private broadcast" ] } ], "participants": [ { "login": "fametrano", "stance": "objection", "note": "concerned tests lack nonce and BIP324 key isolation checks", "association": "NONE", "comments": 1, "first": "2026-10-25", "last": "2026-10-25" }, { "login": "vasild", "stance": "objection", "note": "finds reliance on DNS seeds and excluding Tor/I2P peers unacceptable", "association": "MEMBER", "comments": 2, "first": "2026-10-26", "last": "2026-10-29" }, { "login": "ajtowns", "stance": "neutral", "note": "suggested abandoning in-node broadcast for external hooks, questioned PR size, and argued for deprecating existing implementation", "association": "MEMBER", "comments": 8, "first": "2026-10-27", "last": "2026-11-01" }, { "login": "andrewtoth", "stance": "question", "note": "asked about addrman attacks, and suggested avoiding DNS seeds and retaining I2P/Tor connections", "association": "MEMBER", "comments": 3, "first": "2026-10-27", "last": "2026-10-29" }, { "login": "darosior", "stance": "support", "note": "Concept ACK; argued state isolation prevents correlation leaks and supported keeping/fixing the feature in-tree", "association": "MEMBER", "comments": 3, "first": "2026-10-27", "last": "2026-10-29" }, { "login": "spacexm406-web", "stance": "neutral", "note": "posted an AI summary of review comments and an unelaborated review note", "association": "NONE", "comments": 2, "first": "2026-10-29", "last": "2026-10-29" } ], "derivation": "objection that needs a change was answered, no reply from the objector (vasild: Relying permanently on centralized DNS seeds for each private broadcast creates a single point of failure and makes the ; vasild: Broadcasting exclusively to IP peers via Tor makes private broadcast fragile to Tor outages and exit node failures, lack; vasild: Restricting broadcast recipients to IP peers degrades network-wide privacy by preventing Tor and I2P nodes from acting a)", "model_state": null, "corrections": [], "notes": "ajtowns reiterated their suggestion to deprecate the existing in-node feature and provide hooks for external tools rather than reviewing a large PR with competing design approaches." }, "dependencies": { "depends_on": [], "enables": [ "#36608" ] }, "categories": [ { "name": "docs", "member": false, "evidence": "Documentation updates in doc/design/private-broadcast.md and doc/private-broadcast.md support the code rewrite rather than forming the primary change.", "band": "Unranked", "reason_tag": "cleanup", "score": 0.0, "factors": { "bug_severity": 2, "leverage": 1, "performance": 0, "security_stability": 2, "user_value": 2 }, "rationale": "Not documentation primary; the docs merely describe the new private broadcast architecture." }, { "name": "kernel", "member": false, "evidence": "Minor peripheral edits in kernel paths without touching the libbitcoinkernel API or validation boundaries.", "band": "Unranked", "reason_tag": "cleanup", "score": 0.0, "factors": { "bug_severity": 2, "leverage": 1, "performance": 0, "security_stability": 2, "user_value": 2 }, "rationale": "Not kernel work; does not alter libbitcoinkernel interfaces or boundary logic." }, { "name": "p2p", "member": true, "evidence": "P2P label, extensive changes across net.cpp and net_processing.cpp to isolate transaction relay and connection management into dedicated Tor/BIP324 jobs.", "band": "P1", "reason_tag": "bug fix", "score": 0.8, "factors": { "bug_severity": 2, "leverage": 1, "performance": 0, "security_stability": 2, "user_value": 2 }, "rationale": "The rewrite addresses severe deanonymization risks in master's private broadcast implementation. As reviewers noted, coupling broadcast connections to shared node state represents an 'active footgun that worsens privacy once adversaries adapt', making origin privacy protection a category-critical issue." }, { "name": "rpc", "member": false, "evidence": "Edits to src/rpc/mempool.cpp only hook the private broadcast subsystem into transaction submission rather than changing the RPC interface.", "band": "Unranked", "reason_tag": "cleanup", "score": 0.0, "factors": { "bug_severity": 2, "leverage": 1, "performance": 0, "security_stability": 2, "user_value": 2 }, "rationale": "Not RPC; exposing private broadcast behavior via RPC calls belongs to the P2P area rather than RPC infrastructure." }, { "name": "tests", "member": false, "evidence": "Adds functional tests and fuzzers in src/test/fuzz/privbcast_attempt.cpp dedicated specifically to validating private broadcast logic.", "band": "Unranked", "reason_tag": "test coverage", "score": 0.0, "factors": { "bug_severity": 2, "leverage": 1, "performance": 0, "security_stability": 2, "user_value": 2 }, "rationale": "Test files pin the behavior of the private broadcast subsystem rather than modifying general test infrastructure." }, { "name": "utils", "member": false, "evidence": "Edits to src/init.cpp handle initialization of the private broadcast subsystem.", "band": "Unranked", "reason_tag": "cleanup", "score": 0.0, "factors": { "bug_severity": 2, "leverage": 1, "performance": 0, "security_stability": 2, "user_value": 2 }, "rationale": "Init changes only serve the private broadcast feature's startup lifecycle rather than general utility primitives." }, { "name": "validation", "member": false, "evidence": "Touches transaction primitive definitions without modifying validation rules or chainstate logic.", "band": "Unranked", "reason_tag": "cleanup", "score": 0.0, "factors": { "bug_severity": 2, "leverage": 1, "performance": 0, "security_stability": 2, "user_value": 2 }, "rationale": "Not validation; bypasses local mempool validation and does not change consensus or chainstate rules." } ], "confidence": "high", "uncertainties": [], "needs": [] }, "cost_usd": 0.0, "source": { "record": "2026-11-02T01:12:08+00:00", "code": "2026-10-30T01:17:30+00:00", "judgments": 7 } }