This pull addresses #22634 (comment) and various user feedback/questions, updates the -onlynet documentation in doc/i2p.md and doc/tor.md per #22651 (src/init.cpp is already fine) and fills in some missing I2P unit test coverage.
Note: this PR depends in part on whether #22651 is merged in order to propose the correct -onlynet documentation (it is currently aligned with the change in #22651), so that PR should be decided or merged first.
26+
27+Note the IP address and port the SAM proxy is listening to; usually, it is
28+`127.0.0.1:7656`.
29+
30+Once it is up and running with SAM enabled, use the following Bitcoin Core
31+configuration options:
0-Once it is up and running with SAM enabled, use the following Bitcoin Core
1-configuration options:
2+Once an I2P router with SAM enabled is up and running, use the following Bitcoin
3+Core configuration options:
55@@ -47,10 +56,13 @@ information in the debug log about your I2P configuration and connections. Run
56 `bitcoin-cli help logging` for more information.
57
58 It is possible to restrict outgoing connections in the usual way with
59-`onlynet=i2p`. I2P support was added to Bitcoin Core in version 22.0 (mid-2021)
60-and there may be fewer I2P peers than Tor or IP ones. Therefore, using
61-`onlynet=i2p` alone (without other `onlynet=`) may make a node more susceptible
62-to [Sybil attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack). Use
63+`onlynet=i2p`, combined with `-onion=0` if disabling outbound onion connections
64+is desired, see [doc/tor.md](/tor.md).
0is desired, see [doc/tor.md](doc/tor.md).
17-Bitcoin Core options:
18+enabled is required. Options include:
19+
20+- [i2p-router](https://geti2p.net), the official implementation in Java
21+- [i2pd (I2P Daemon)](https://i2pd.readthedocs.io/en/latest), a lighter
22+ alternative in C++ (version 2.23 in Debian stable will not work; version 2.35
I’ve tested 2.23 with both 22.0rc2 and master and it still manages to work, albeit with a few more warnings, some of which seemed to be false negatives before managing to connect, and the warnings when a peer isn’t online are verbose and a bit less helpful:
02021-08-06T15:37:05Z I2P: Error connecting to zsxwyo6qcn3chqzwxnseusqgsnuw3maqnztkiypyfxtya4snkoka.b32.i2p:0:
1Unexpected reply to "NAMING LOOKUP NAME=zsxwyo6qcn3chqzwxnseusqgsnuw3maqnztkiypyfxtya4snkoka.b32.i2p":
2"NAMING REPLY RESULT=INVALID_KEY NAME=zsxwyo6qcn3chqzwxnseusqgsnuw3maqnztkiypyfxtya4snkoka.b32.i2p"
Still testing but may just warn here instead.
61-`onlynet=i2p` alone (without other `onlynet=`) may make a node more susceptible
62-to [Sybil attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack). Use
63+`onlynet=i2p` (combined with `-onion=0` if disabling outbound onion connections
64+is desired; see [doc/tor.md](tor.md)).
65+
66+I2P support was added to Bitcoin Core in version 22.0 (mid-2021) and there may
doc/i2p.md will be in.
(mid-2021)
65+
66+Make outgoing connections only to I2P addresses. Incoming connections are not
67+affected by this option. It can be specified multiple times to allow multiple
68+network types, e.g. onlynet=ipv4, onlynet=ipv6, onlynet=onion, onlynet=i2p.
69+
70+Warning: if you use -onlynet with values other than onion, and the -onion or
16-`127.0.0.1:7656`. Once it is up and running with SAM enabled, use the following
17-Bitcoin Core options:
18+
19+enabled is required. Options include:
20+
21+- [i2p-router](https://geti2p.net), the official implementation in Java
i2prouter start in terminal.
Looks like we need all ports open for outbound: https://www.reddit.com/r/i2p/comments/fzwwd0/confused_on_what_ports_to_open/fn76ly9
And for inbound users can follow everything mentioned here: https://geti2p.net/en/faq#ports
23+ ([documentation](https://i2pd.readthedocs.io/en/latest)), a lighter
24+ alternative in C++ (successfully tested with version 2.23 and up; version 2.36
25+ or later recommended)
26+- [i2p-zero](https://github.com/i2p-zero/i2p-zero)
27+- [other alternatives](https://en.wikipedia.org/wiki/I2P#Routers)
28+
For the official i2prouter implementation in Java, visit their download page and follow the instructions for your Operating System.
Once installed, open a terminal window and type i2prouter start. Then visit http://127.0.0.1:7657/configclients in your browser to enable SAM. On the left side of the page, there should be a green light next to “Shared Clients”.
Edit: Fixed with @RandyMcMillan suggestions
If the user has successfully config’d to this point - a link will take the user to the correct page.
Maybe add a link for convenience?
Then visit 127.0.0.1:7657/configclients
Thanks. I agree it might be helpful, but I don’t know if those instructions are platform agnostic. We would also need to maintain it / keep it up to date. Most people I talk to are using i2pd (admittedly perhaps because it is very easy to install), so if we explain how to install i2p-router, we should probably also do it for i2pd. Sounds like a dedicated “How to Install an I2P Router” section.
In any case, feel free to propose this separately. I would rather not make this pull larger.
@prayank23 I don’t believe that is correct. I am behind a router/firewall I don’t control right now (haven’t forwarded any ports) and I am able to successfully create an i2p address (ugmw4zuyhmrm7anfctjamcjgi32daor4ulqdrxtn66owgn2oyebq.b32.i2p:0) and connect out to other i2p nodes (although they are not very long lasting connections, and I have no inbound connections despite setting i2pacceptincoming=1).
That being said, I also have no incoming tor connections to my HS (kwn76yxlsaucsbywm5sy4q5ebo6atao5escejchwjkzu2l5lwkkkzdqd.onion:8333) which I know doesn’t require any port forwarding, so I’m not sure what’s going on. I have been running my node for many hours.
bitcoin.conf:
listen=1 assumevalid=0 dbcache=1000 addresstype=bech32 avoidpartialspends=1 changetype=bech32 maxapsfee=0.01 i2psam=127.0.0.1:7656 debug=tor debug=i2p i2pacceptincoming=1
In my debug file, I see that my node is trying to connect to lots of i2p nodes, but I have tons of connection timeout errors.
Edit: Maybe you could try to connect to me?
Edit: Maybe you could try to connect to me?
Sure. Will experiment tomorrow. Will ping you in IRC. It’s 4 AM here right now 😴
I see your inbound for both i2p and tor, so I think we should be good, unless other users start reporting high ping times for these networks with v22.0.
Thanks for helping!
I see your inbound for both i2p and tor, so I think we should be good, unless other users start reporting high ping times for these networks with v22.0.
Things that you should try:
sudo ufw status verbosess nlt and nmapACK https://github.com/bitcoin/bitcoin/pull/22648/commits/e3a58140dc8fe20b76d5ef38074e37bca7111b79
nit:
Would be great if we can add things suggested by @Rspigler in https://github.com/bitcoin/bitcoin/pull/22648/#discussion_r684835687
And information about ports or at least this link: https://geti2p.net/en/faq#ports
I have added both things in https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/pull/408
For ports I tried experimenting with allow/deny in ufw and see if it affects outgoing and incoming connections in Bitcoin Core.
TL;DR:
0Ports required by i2p:
1
21. Outbound (Internet facing): a random port between 9000 and 31000 is selected however its better if all ports are open and it doesn't affect your security. You can check firewall status using `sudo ufw status verbose` which shouldn't deny outgoing by default.
3
42. Inbound (Internet facing): Optional
5
6Local ports: https://geti2p.net/en/faq#ports
If something looks incorrect feel free to comment :)
a random port between 9000 and 31000
I can confirm this
784+ SetReachable(NET_I2P, true);
785
786 BOOST_CHECK_EQUAL(IsReachable(NET_IPV4), true);
787 BOOST_CHECK_EQUAL(IsReachable(NET_IPV6), true);
788 BOOST_CHECK_EQUAL(IsReachable(NET_ONION), true);
789+ BOOST_CHECK_EQUAL(IsReachable(NET_I2P), true);
nit:
0BOOST_CHECK_EQUAL(foo, true);
1BOOST_CHECK_EQUAL(bar, false);
2// vs
3BOOST_CHECK(foo);
4BOOST_CHECK(!bar);
but the surrounding code is already using the former, so it is ok to leave it as it is.
and simplify similar neighboring assertions.
9@@ -10,11 +10,22 @@ started with I2P terminology.
10 ## Run Bitcoin Core with an I2P router (proxy)
11
12 A running I2P router (proxy) with [SAM](https://geti2p.net/en/docs/api/samv3)
13-enabled is required (there is an [official one](https://geti2p.net) and
14-[a few alternatives](https://en.wikipedia.org/wiki/I2P#Routers)). Notice the IP
15-address and port the SAM proxy is listening to; usually, it is
16-`127.0.0.1:7656`. Once it is up and running with SAM enabled, use the following
17-Bitcoin Core options:
18+
git diff e3a5814 0175977 per review feedback (thanks!) and corrected the name of the first I2P router from i2p-router to i2prouter (I2P Router), which is also more similar to the second router i2pd (I2P Daemon).
reACK https://github.com/bitcoin/bitcoin/commit/017597767b977bb8fe11be8e2012130df1dffd30
Changes since last review: #22648 (comment)
-onlynet edge-case behavior is not personally clear to me and it wasn’t clear to me that the documentation here depends on code that isn’t merged yet. The other documentation changes looked sane to me and all the ACKs here were kind of confusing me that it was ready for merge.
64- onion connections over the default proxy or your defined -proxy.
65+ onlynet=ipv4, onlynet=ipv6, onlynet=onion, onlynet=i2p.
66+ Warning: if you use -onlynet with values other than onion, and
67+ the -onion or -proxy option is set, then outgoing onion
68+ connections will still be made; use -noonion or -onion=0 to
69+ disable outbound onion connections in this case.
-onlynet=ipv4 (or any onlynet not involving -onlynet=onion) do as one would expect, ignore onions, even if there happens to be a proxy for them? I think this is the most expected behavior, to have proxy setting be orthogonal to what networks to connect out on.
-onlynet=onion (with the intent of only connecting to onions), I’d be bummed if it still connected to ipv4 and ipv6 nodes because a proxy is specified for them indirectly through -proxy=127.0.0.1:9050.
I think I would personally prefer #22651 to fix this behavior
It can be done in a follow up PR. Will be great if we can do it in the same PR.
Would also need to fix port used for Windows by default: #22651 (review)
Can’t we make -onlynet=ipv4 (or any onlynet not involving -onlynet=onion) do as one would expect, ignore onions, even if there happens to be a proxy for them?
Yes. According to my understanding this is how things would work: Consider Alice wants to use Tor proxy for outbound connections, however connect only with ipv4 nodes. Bob wants to use Tor proxy for outbound connections, he is okay with connecting to any nodes (onion, ipv4 etc.)
So Alice can use onlynet=ipv4 and proxy=127.0.0.1:9050. Bob will use proxy=127.0.0.1:9050