#36348 doc/i2p: mention -privatebroadcast bypasses persistent address
| Reviewability | Reviews | Agreement | Size | ||||
|---|---|---|---|---|---|---|---|
| #36348 doc/i2p: mention -privatebroadcast bypasses persistent address | Waiting on author | 1 (+1) | Strong | 11 | |||
|
|
|
|
| |||
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
Clarifies in doc/i2p.md that outbound I2P connections opened under -privatebroadcast use transient addresses instead of the node's persistent I2P identity. It also notes that -privatebroadcast only covers transactions broadcast via sendrawtransaction, and mentions that private broadcast runs over Tor as well.
Problem: Bitcoin Core's I2P documentation stated that persistent I2P addresses are always used for outbound and inbound connections, obscuring the privacy mechanism used by -privatebroadcast and leaving operators misinformed about when their long-lived I2P address is exposed.
Evidence of importance:
- PR description: 'It is not entirely accurate that persistent I2P addresses are used for making outbound connections and accepting incoming ones, as the -privatebroadcast option forces the use of a new transient destination for each transaction it relays.'
Risk of a mistake: low (docs). This is a documentation-only update to doc/i2p.md with no executable code changes.
Changed since the previous assessment: Refined the explanation to note that private broadcast also operates over Tor and added co-author attributions.
Reviewability
Paused · Waiting on author
Open objections from andrewtoth with no author reply for 18 days; review would repeat what has been asked.
Waiting on (from the thread read):
- author: address suggestions from andrewtoth on address vs destination and transient address clarification 2026-10-07
Agreement
Strong
substantive support, no open objection (jonatack, davidgumberg)
Thread notes: Added davidgumberg's commit ACK (c:6159596565). His reservation regarding user relevance is recorded as review rationale rather than a claim since he concluded it is fine to him.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| jonatack (member) | suggestion, scope | expand the documentation to explain that private broadcast opens several short-lived peers per transaction over Tor or I2P and applies only to sendrawtransaction | answered · author agreed to incorporate jonatack's suggestion; fix not yet pushed | answered | yes | 2026-09-27: 'Perhaps the proposed text could mention that to be more precise. WDYT of the following?' Status from: 2026-10-06: jpk68: 'Sure, that sounds fine to me.' |
| andrewtoth (member) | suggestion, style | use 'address' instead of 'destination' | open | answered | no | 2026-10-07: 'Might be clearer to use address here instead of destination.' |
| andrewtoth (member) | suggestion, style | use 'transient address' and clarify that connections opened for -privatebroadcast do not use the persistent address from i2p_private_key | open | answered | no | 2026-10-07: 'Regardless of `-i2pacceptincoming`, I2P connections opened for `-privatebroadcast` do not use the persistent address from `i2p_private_key`.' |
Support:
- andrewtoth (member) (ACK, 2026-09-27): (no reason given) [not substantive]
- jonatack (member) (Concept ACK, 2026-09-27) [read]: Private broadcast opens several short-lived peers per transaction, over Tor or I2P, and only for sendrawtransaction
- davidgumberg (member) (ACK, 2026-09-30): (no reason given) [not substantive]
- davidgumberg (member) (ACK, 2026-10-14) [read]: The change here seems pedantically correct, but I'm still not sure I understand why I2P users would care or why this information would be relevant to them, so it seems a bit noisy to me, but fine to me.
Participants:
- fanquake (member, neutral, 1 statements 2026-09-26 to 2026-09-26): tagged relevant reviewers
- andrewtoth (member, support, 3 statements 2026-09-27 to 2026-10-07): ACKed; suggested using 'address' instead of 'destination' and clarifying transient address usage
- jonatack (member, support, 2 statements 2026-09-27 to 2026-10-01): Concept ACK and suggested expanded documentation wording
- davidgumberg (member, support, 2 statements 2026-09-30 to 2026-10-14): ACKed; questioned relevance to I2P users but concluded it is fine
- sedited (member, neutral, 2 statements 2026-10-06 to 2026-10-06): prompted author on jonatack's suggestion and recommended keeping changes focused on i2p docs
Files
0 lines under test/bench/ci.
- doc/i2p.md +11/-1
Card
The short text the ranking pass compares across PRs.
Updates doc/i2p.md to document that -privatebroadcast creates transient I2P addresses instead of reusing the persistent address in i2p_private_key. It also clarifies that -privatebroadcast applies only to transactions submitted through sendrawtransaction rather than wallet transactions. The change is documentation-only with no functional code changes.
Data
thread read through 2026-10-14 (12 statements), head 4307c2e0b0
labels: none
Categories
Documentation
P2 · bug fix (assessed alone as P3; Raised to P2: corrects privacy-relevant documentation (persistent I2P identity exposure, wallet txs not covered) that could otherwise lead operators to a wrong conclusion; same consequence class as #35858.)
Corrects inaccurate documentation regarding persistent versus transient address usage when `-privatebroadcast` is enabled. As noted in the description, the existing docs stated persistent addresses were always used, leaving operators misinformed about when their persistent I2P identity is exposed.
Membership: Modifies doc/i2p.md to clarify address handling under -privatebroadcast.
Factors: security/stability 0, bug 0, performance 0, user value 1, leverage 0