diff options
| author | Jon Atack <jon@atack.com> | 2022-03-14 10:44:54 +0100 |
|---|---|---|
| committer | Jon Atack <jon@atack.com> | 2022-03-31 10:30:02 +0200 |
| commit | 7a553d4e657d52e2d15b53a4b54b4ca5ecde2f04 (patch) | |
| tree | adfffc0246070b4bf35573235780cdaca71b035a | |
| parent | 4148396229db008419f895161b6c7310a44d563b (diff) | |
doc: update i2p.md with cjdns, improve local addresses section
Github-Pull: bitcoin#24555
Rebased-From: f44efc3
| -rw-r--r-- | doc/i2p.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/i2p.md b/doc/i2p.md index e45b5efb9b..39f65c4e5f 100644 --- a/doc/i2p.md +++ b/doc/i2p.md @@ -80,15 +80,15 @@ phase when syncing up a new node can be very slow. This phase can be sped up by using other networks, for instance `onlynet=onion`, at the same time. In general, a node can be run with both onion and I2P hidden services (or -any/all of IPv4/IPv6/onion/I2P), which can provide a potential fallback if one -of the networks has issues. +any/all of IPv4/IPv6/onion/I2P/CJDNS), which can provide a potential fallback if +one of the networks has issues. ## I2P-related information in Bitcoin Core There are several ways to see your I2P address in Bitcoin Core: -- in the debug log (grep for `AddLocal`, the I2P address ends in `.b32.i2p`) -- in the output of the `getnetworkinfo` RPC in the "localaddresses" section -- in the output of `bitcoin-cli -netinfo` peer connections dashboard +- in the "Local addresses" output of CLI `-netinfo` +- in the "localaddresses" output of RPC `getnetworkinfo` +- in the debug log (grep for `AddLocal`; the I2P address ends in `.b32.i2p`) To see which I2P peers your node is connected to, use `bitcoin-cli -netinfo 4` or the `getpeerinfo` RPC (e.g. `bitcoin-cli getpeerinfo`). |