doc/i2p: mention -privatebroadcast bypasses persistent address #36348

jpk68 commented at 7:58 PM on September 26, 2026: contributor

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.

DrahtBot commented at 7:58 PM on September 26, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

External sites

Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36348
Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36348.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36348#author-ralph

Reviews

See the guideline and AI policy for information on the review process.

Type	Reviewers
ACK	davidgumberg
Concept ACK	jonatack
Stale ACK	andrewtoth

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

fanquake commented at 8:03 PM on September 26, 2026: member

cc @andrewtoth @vasild

andrewtoth approved

andrewtoth commented at 3:22 PM on September 27, 2026: contributor

lgtm ACK 06e38491077ccb49eb1aee118af5259c905b9a9b

jonatack commented at 9:00 PM on September 27, 2026: member

Concept ACK

Private broadcast opens several short-lived peers per transaction, over Tor or I2P, and only for sendrawtransaction. Perhaps the proposed text could mention that to be more precise. WDYT of the following?

@@ -83,7 +83,7 @@ generates a persistent I2P address and its corresponding private key by default,
 unless `-i2pacceptincoming=0` is set.  The private key is saved in a file named
 `i2p_private_key` in the Bitcoin Core data directory.  The persistent I2P
-address is used for making outbound connections and accepting inbound
-connections.
+address is used for making outbound connections and accepting inbound
+connections, except that I2P connections opened for `-privatebroadcast`
+use a transient destination instead (see below).

 In the I2P network, the receiver of an inbound connection sees the address of
 the initiator. This is unlike the Tor network, where the recipient does not
@@ -98,6 +98,12 @@ I2P addresses are designed to be long-lived.  Waiting for tunnels to be built
 for every peer connection adds delay to connection setup time.  Therefore, I2P
 listening should only be turned off if really needed.

+Independently of `-i2pacceptincoming`, I2P connections opened for
+`-privatebroadcast` do not use the persistent destination from
+`i2p_private_key`. Instead, they use a transient destination so the
+receiver does not see the node's long-lived I2P identity.
+
+The `-privatebroadcast` option applies only to transactions submitted
+with `sendrawtransaction`, not to wallet-created transactions. Private
+broadcast also runs over Tor; this section only describes the I2P case.
+
## Fetching I2P-related information from Bitcoin Core

jpk68 commented at 2:38 PM on September 28, 2026: contributor

Ah, fair point. Do you think the Tor docs should be updated for this as well?

davidgumberg commented at 11:01 PM on September 30, 2026: contributor

ACK https://github.com/bitcoin/bitcoin/commit/06e38491077ccb49eb1aee118af5259c905b9a9b

Could be updated for tor as well, but although pedantically more correct I'm not sure I get why this would be valuable for a user to know.

DrahtBot requested review from jonatack on Sep 30, 2026

jonatack commented at 12:25 AM on October 1, 2026: member

Updating the tor docs was not the feedback I gave.

sedited commented at 8:04 AM on October 6, 2026: contributor

@jpk68 do you want to take jonatack's suggestion #36348#pullrequestreview-5332086908?

jpk68 commented at 12:47 PM on October 6, 2026: contributor

@sedited Sure, that sounds fine to me. Apologies, but I'm a bit confused about the part with the Tor docs - should those be updated as well, or no?

sedited commented at 1:09 PM on October 6, 2026: contributor

From reading through the thread here, the changes I'd imagine to the tor docs would be less interesting / probably just noise in explaining a user how to get set up. It is more interesting in this document, because of this paragraph https://github.com/bitcoin/bitcoin/pull/36348/changes#diff-629b3acb5e1cd9ad21f4f55bc95822e79f22f15da47f5de82284c15cbe8bb47bL88-L90 , so I'd keep the changes to the i2p docs, and expand it to i2pacceptincoming, as jonatack suggested.

jpk68 force-pushed on Oct 6, 2026

in doc/i2p.md:87 in 8928c36f24

  82 | @@ -83,7 +83,8 @@ generates a persistent I2P address and its corresponding private key by default,
  83 |  unless `-i2pacceptincoming=0` is set.  The private key is saved in a file named
  84 |  `i2p_private_key` in the Bitcoin Core data directory.  The persistent I2P
  85 |  address is used for making outbound connections and accepting inbound
  86 | -connections.
  87 | +connections, except that I2P connections opened for `-privatebroadcast`
  88 | +use a transient destination instead (see below).

andrewtoth commented at 1:08 AM on October 7, 2026:

Might be clearer to use address here instead of destination.

always use a transient address instead (see below).

in doc/i2p.md:102 in 8928c36f24

  98 | @@ -98,6 +99,15 @@ I2P addresses are designed to be long-lived.  Waiting for tunnels to be built
  99 |  for every peer connection adds delay to connection setup time.  Therefore, I2P
 100 |  listening should only be turned off if really needed.
 101 |  
 102 | +Independently of `-i2pacceptincoming`, I2P connections opened for

andrewtoth commented at 1:11 AM on October 7, 2026:

Similarly

Regardless of `-i2pacceptincoming`, I2P connections opened for
`-privatebroadcast` do not use the persistent address from
`i2p_private_key`. Instead, they use a transient address so the
receiver does not see the node's long-lived I2P identity.

jpk68 force-pushed on Oct 11, 2026

doc/i2p: mention -privatebroadcast bypasses persistent address

Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Andrew Toth <andrewstoth@gmail.com>

4307c2e0b0

jpk68 force-pushed on Oct 11, 2026

DrahtBot added the label CI failed on Oct 11, 2026

DrahtBot removed the label CI failed on Oct 11, 2026

davidgumberg commented at 2:33 AM on October 14, 2026: contributor

text ACK https://github.com/bitcoin/bitcoin/commit/4307c2e0b01765932ad9518c63b764ef8dd16927

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.

DrahtBot requested review from andrewtoth on Oct 14, 2026