Skip to content

Commit dbca00e

Browse files
author
MarcoFalke
committed
Merge bitcoin/bitcoin#26838: doc: I2P documentation updates
3e1d294 doc: remove recommended I2P router versions (jonatack) 295849a doc: update/clarify/de-emphasize I2P transient address section (jonatack) dffa319 doc: update bandwidth section of I2P documentation (jonatack) 0ed9cc5 doc: clarify -i2pacceptincoming help documentation (jonatack) Pull request description: Address the documentation updates requested in issue #26754, clarify/simplify the -i2pacceptincoming help, and a few other fixups. ACKs for top commit: willcl-ark: ACK 3e1d294 1440000bytes: ACK bitcoin/bitcoin@3e1d294 w0xlt: ACK bitcoin/bitcoin@3e1d294 vasild: ACK 3e1d294 Tree-SHA512: e647221884af34646b99150617f4d4cc8d5fce325a769294f49047b9d8c9c8ab2b365cfdd9f56b3bd0303da706233f03d24cececf6e161c53f04ed947751052a
2 parents 4586ae2 + 3e1d294 commit dbca00e

File tree

3 files changed

+57
-47
lines changed

3 files changed

+57
-47
lines changed

doc/i2p.md

Lines changed: 50 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -16,8 +16,7 @@ enabled is required. Options include:
1616
Java
1717
- [i2pd (I2P Daemon)](https://github.com/PurpleI2P/i2pd)
1818
([documentation](https://i2pd.readthedocs.io/en/latest)), a lighter
19-
alternative in C++ (successfully tested with version 2.23 and up; version 2.36
20-
or later recommended)
19+
alternative in C++
2120
- [i2p-zero](https://github.com/i2p-zero/i2p-zero)
2221
- [other alternatives](https://en.wikipedia.org/wiki/I2P#Routers)
2322

@@ -33,12 +32,10 @@ Core configuration options:
3332
none)
3433
3534
-i2pacceptincoming
36-
If set and -i2psam is also set then incoming I2P connections are
37-
accepted via the SAM proxy. If this is not set but -i2psam is set
38-
then only outgoing connections will be made to the I2P network.
39-
Ignored if -i2psam is not set. Listening for incoming I2P
40-
connections is done through the SAM proxy, not by binding to a
41-
local address and port (default: 1)
35+
Whether to accept inbound I2P connections (default: 1). Ignored if
36+
-i2psam is not set. Listening for inbound I2P connections is
37+
done through the SAM proxy, not by binding to a local address and
38+
port.
4239
```
4340

4441
In a typical situation, this suffices:
@@ -47,27 +44,6 @@ In a typical situation, this suffices:
4744
bitcoind -i2psam=127.0.0.1:7656
4845
```
4946

50-
The first time Bitcoin Core connects to the I2P router, if
51-
`-i2pacceptincoming=1`, then it will automatically generate a persistent I2P
52-
address and its corresponding private key. The private key will be saved in a
53-
file named `i2p_private_key` in the Bitcoin Core data directory. The persistent
54-
I2P address is used for accepting incoming connections and for making outgoing
55-
connections if `-i2pacceptincoming=1`. If `-i2pacceptincoming=0` then only
56-
outbound I2P connections are made and a different transient I2P address is used
57-
for each connection to improve privacy.
58-
59-
## Persistent vs transient I2P addresses
60-
61-
In I2P connections, the connection receiver sees the I2P address of the
62-
connection initiator. This is unlike the Tor network where the recipient does
63-
not know who is connecting to them and can't tell if two connections are from
64-
the same peer or not.
65-
66-
If an I2P node is not accepting incoming connections, then Bitcoin Core uses
67-
random, one-time, transient I2P addresses for itself for outbound connections
68-
to make it harder to discriminate, fingerprint or analyze it based on its I2P
69-
address.
70-
7147
## Additional configuration options related to I2P
7248

7349
```
@@ -100,7 +76,29 @@ In general, a node can be run with both onion and I2P hidden services (or
10076
any/all of IPv4/IPv6/onion/I2P/CJDNS), which can provide a potential fallback if
10177
one of the networks has issues.
10278

103-
## I2P-related information in Bitcoin Core
79+
## Persistent vs transient I2P addresses
80+
81+
The first time Bitcoin Core connects to the I2P router, it automatically
82+
generates a persistent I2P address and its corresponding private key by default
83+
or if `-i2pacceptincoming=1` 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+
88+
In the I2P network, the receiver of an inbound connection sees the address of
89+
the initiator. This is unlike the Tor network, where the recipient does not
90+
know who is connecting to it.
91+
92+
If your node is configured by setting `-i2pacceptincoming=0` to not accept
93+
inbound I2P connections, then it will use a random transient I2P address for
94+
itself on each outbound connection to make it harder to discriminate,
95+
fingerprint or analyze it based on its I2P address.
96+
97+
I2P addresses are designed to be long-lived. Waiting for tunnels to be built
98+
for every peer connection adds delay to connection setup time. Therefore, I2P
99+
listening should only be turned off if really needed.
100+
101+
## Fetching I2P-related information from Bitcoin Core
104102

105103
There are several ways to see your I2P address in Bitcoin Core if accepting
106104
incoming I2P connections (`-i2pacceptincoming`):
@@ -136,14 +134,19 @@ port (`TO_PORT`) is always set to 0 and is not in the control of Bitcoin Core.
136134

137135
## Bandwidth
138136

139-
I2P routers may route a large amount of general network traffic with their
140-
default settings. Check your router's configuration to limit the amount of this
141-
traffic relayed, if desired.
137+
By default, your node shares bandwidth and transit tunnels with the I2P network
138+
in order to increase your anonymity with cover traffic, help the I2P router used
139+
by your node integrate optimally with the network, and give back to the network.
140+
It's important that the nodes of a popular application like Bitcoin contribute
141+
as much to the I2P network as they consume.
142142

143-
With `i2pd`, the amount of bandwidth being shared with the wider network can be
144-
adjusted with the `bandwidth`, `share` and `transittunnels` options in your
145-
`i2pd.conf` file. For example, to limit total I2P traffic to 256KB/s and share
146-
50% of this limit for a maximum of 20 transit tunnels:
143+
It is possible, though strongly discouraged, to change your I2P router
144+
configuration to limit the amount of I2P traffic relayed by your node.
145+
146+
With `i2pd`, this can be done by adjusting the `bandwidth`, `share` and
147+
`transittunnels` options in your `i2pd.conf` file. For example, to limit total
148+
I2P traffic to 256KB/s and share 50% of this limit for a maximum of 20 transit
149+
tunnels:
147150

148151
```
149152
bandwidth = 256
@@ -153,9 +156,15 @@ share = 50
153156
transittunnels = 20
154157
```
155158

156-
If you prefer not to relay any public I2P traffic and only permit I2P traffic
157-
from programs which are connecting via the SAM proxy, e.g. Bitcoin Core, you
158-
can set the `notransit` option to `true`.
159-
160159
Similar bandwidth configuration options for the Java I2P router can be found in
161160
`http://127.0.0.1:7657/config` under the "Bandwidth" tab.
161+
162+
Before doing this, please see the "Participating Traffic Considerations" section
163+
in [Embedding I2P in your Application](https://geti2p.net/en/docs/applications/embedding).
164+
165+
In most cases, the default router settings should work fine.
166+
167+
## Bundling I2P in a Bitcoin application
168+
169+
Please see the "General Guidance for Developers" section in https://geti2p.net/en/docs/api/samv3
170+
if you are developing a downstream application that may be bundling I2P with Bitcoin.

src/init.cpp

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -126,8 +126,9 @@ using node::fPruneMode;
126126
using node::fReindex;
127127
using node::nPruneTarget;
128128

129-
static const bool DEFAULT_PROXYRANDOMIZE = true;
130-
static const bool DEFAULT_REST_ENABLE = false;
129+
static constexpr bool DEFAULT_PROXYRANDOMIZE{true};
130+
static constexpr bool DEFAULT_REST_ENABLE{false};
131+
static constexpr bool DEFAULT_I2P_ACCEPT_INCOMING{true};
131132

132133
#ifdef WIN32
133134
// Win32 LevelDB doesn't use filedescriptors, and the ones used for
@@ -473,7 +474,7 @@ void SetupServerArgs(ArgsManager& argsman)
473474
argsman.AddArg("-maxuploadtarget=<n>", strprintf("Tries to keep outbound traffic under the given target per 24h. Limit does not apply to peers with 'download' permission or blocks created within past week. 0 = no limit (default: %s). Optional suffix units [k|K|m|M|g|G|t|T] (default: M). Lowercase is 1000 base while uppercase is 1024 base", DEFAULT_MAX_UPLOAD_TARGET), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
474475
argsman.AddArg("-onion=<ip:port>", "Use separate SOCKS5 proxy to reach peers via Tor onion services, set -noonion to disable (default: -proxy)", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
475476
argsman.AddArg("-i2psam=<ip:port>", "I2P SAM proxy to reach I2P peers and accept I2P connections (default: none)", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
476-
argsman.AddArg("-i2pacceptincoming", "If set and -i2psam is also set then incoming I2P connections are accepted via the SAM proxy. If this is not set but -i2psam is set then only outgoing connections will be made to the I2P network. Ignored if -i2psam is not set. Listening for incoming I2P connections is done through the SAM proxy, not by binding to a local address and port (default: 1)", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
477+
argsman.AddArg("-i2pacceptincoming", strprintf("Whether to accept inbound I2P connections (default: %i). Ignored if -i2psam is not set. Listening for inbound I2P connections is done through the SAM proxy, not by binding to a local address and port.", DEFAULT_I2P_ACCEPT_INCOMING), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
477478
argsman.AddArg("-onlynet=<net>", "Make automatic outbound connections only to network <net> (" + Join(GetNetworkNames(), ", ") + "). Inbound and manual connections are not affected by this option. It can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
478479
argsman.AddArg("-peerbloomfilters", strprintf("Support filtering of blocks and transaction with bloom filters (default: %u)", DEFAULT_PEERBLOOMFILTERS), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
479480
argsman.AddArg("-peerblockfilters", strprintf("Serve compact block filters to peers per BIP 157 (default: %u)", DEFAULT_PEERBLOCKFILTERS), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
@@ -1829,7 +1830,7 @@ bool AppInitMain(NodeContext& node, interfaces::BlockAndHeaderTipInfo* tip_info)
18291830
SetReachable(NET_I2P, false);
18301831
}
18311832

1832-
connOptions.m_i2p_accept_incoming = args.GetBoolArg("-i2pacceptincoming", true);
1833+
connOptions.m_i2p_accept_incoming = args.GetBoolArg("-i2pacceptincoming", DEFAULT_I2P_ACCEPT_INCOMING);
18331834

18341835
if (!node.connman->Start(*node.scheduler, connOptions)) {
18351836
return false;

test/functional/p2p_i2p_sessions.py

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -23,12 +23,12 @@ def run_test(self):
2323

2424
self.log.info("Ensure we create a persistent session when -i2pacceptincoming=1")
2525
node0 = self.nodes[0]
26-
with node0.assert_debug_log(expected_msgs=[f"Creating persistent SAM session"]):
26+
with node0.assert_debug_log(expected_msgs=["Creating persistent SAM session"]):
2727
node0.addnode(node=addr, command="onetry")
2828

2929
self.log.info("Ensure we create a transient session when -i2pacceptincoming=0")
3030
node1 = self.nodes[1]
31-
with node1.assert_debug_log(expected_msgs=[f"Creating transient SAM session"]):
31+
with node1.assert_debug_log(expected_msgs=["Creating transient SAM session"]):
3232
node1.addnode(node=addr, command="onetry")
3333

3434

0 commit comments

Comments
 (0)