|
|
|
@ -47,13 +47,21 @@ information in the debug log about your I2P configuration and connections. Run
|
|
|
|
|
`bitcoin-cli help logging` for more information.
|
|
|
|
|
|
|
|
|
|
It is possible to restrict outgoing connections in the usual way with
|
|
|
|
|
`onlynet=i2p`. I2P support was added to Bitcoin Core in version 22.0 (mid 2021)
|
|
|
|
|
`onlynet=i2p`. I2P support was added to Bitcoin Core in version 22.0 (mid-2021)
|
|
|
|
|
and there may be fewer I2P peers than Tor or IP ones. Therefore, using
|
|
|
|
|
`onlynet=i2p` alone (without other `onlynet=`) may make a node more susceptible
|
|
|
|
|
to [Sybil attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack). Use
|
|
|
|
|
`bitcoin-cli -addrinfo` to see the number of I2P addresses known to your node.
|
|
|
|
|
|
|
|
|
|
## I2P related information in Bitcoin Core
|
|
|
|
|
Another consideration with `onlynet=i2p` is that the initial blocks download
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
## 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`)
|
|
|
|
|