Merge bitcoin/bitcoin#22112: Force port 0 in I2P

4101ec9d2e05a35c35f587a28f1feee6cebcc61b doc: mention that we enforce port=0 in I2P (Vasil Dimov)
e0a2b390c144e123e2fc8a289fdff36815476964 addrman: reset I2P ports to 0 when loading from disk (Vasil Dimov)
41cda9d075ebcab1dbb950160ebe9d0ba7b5745e test: ensure I2P ports are handled as expected (Vasil Dimov)
4f432bd738c420512a86a51ab3e00323f396b89e net: do not connect to I2P hosts on port!=0 (Vasil Dimov)
1f096f091ebd88efb18154b8894a38122c39624f net: distinguish default port per network (Vasil Dimov)
aeac3bce3ead1f24ca782079ef0defa86fd8cb98 net: change I2P seeds' ports to 0 (Vasil Dimov)
38f900290cc3a839e99bef13474d35e1c02e6b0d net: change assumed I2P port to 0 (Vasil Dimov)

Pull request description:

  _This is an alternative to https://github.com/bitcoin/bitcoin/pull/21514, inspired by https://github.com/bitcoin/bitcoin/pull/21514#issuecomment-815049933. They are mutually exclusive. Just one of them should be merged._

  Change assumed ports for I2P to 0 (instead of the default 8333) as this is closer to what actually happens underneath with SAM 3.1 (https://github.com/bitcoin/bitcoin/pull/21514#issuecomment-812632520, https://github.com/bitcoin/bitcoin/pull/21514#issuecomment-816564719).

  Don't connect to I2P peers with advertised port != 0 (we don't specify a port to our SAM 3.1 proxy and it always connects to port = 0).

  Note, this change:
  * Keeps I2P addresses with port != 0 in addrman and relays them to others via P2P gossip. There may be non-bitcoin-core-22.0 peers using SAM 3.2 and for them such addresses may be useful.
  * Silently refuses to connect to I2P hosts with port != 0. This is ok for automatically chosen peers from addrman. Not so ok for peers provided via `-addnode` or `-connect` - a user who specifies `foo.b32.i2p:1234` (non zero port) may wonder why "nothing is happening".

  Fixes #21389

ACKs for top commit:
  laanwj:
    Code review ACK 4101ec9d2e05a35c35f587a28f1feee6cebcc61b
  jonatack:
    re-ACK 4101ec9d2e05a35c35f587a28f1feee6cebcc61b per `git range-diff efff9c3 0b0ee03 4101ec9`, built with DDEBUG_ADDRMAN, did fairly extensive testing on mainnet both with and without a peers.dat / -dnsseeds=0 to test boostrapping.

Tree-SHA512: 0e3c019e1dc05e54f559275859d3450e0c735596d179e30b66811aad9d5b5fabe3dcc44571e8f7b99f9fe16453eee393d6e153454dd873b9ff14907d4e6354fe

1 files changed, 15 insertions, 0 deletions

diff --git a/doc/i2p.md b/doc/i2p.md
index 8b4607208a..27ef4d9d9f 100644
--- a/doc/i2p.md
+++ b/doc/i2p.md
@@ -70,3 +70,18 @@ RPC.
 
 Bitcoin Core uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3) protocol
 to connect to the I2P network. Any I2P router that supports it can be used.
+
+## Ports in I2P and Bitcoin Core
+
+Bitcoin Core uses the [SAM v3.1](https://geti2p.net/en/docs/api/samv3)
+protocol. One particularity of SAM v3.1 is that it does not support ports,
+unlike newer versions of SAM (v3.2 and up) that do support them and default the
+port numbers to 0. From the point of view of peers that use newer versions of
+SAM or other protocols that support ports, a SAM v3.1 peer is connecting to them
+on port 0, from source port 0.
+
+To allow future upgrades to newer versions of SAM, Bitcoin Core sets its
+listening port to 0 when listening for incoming I2P connections and advertises
+its own I2P address with port 0. Furthermore, it will not attempt to connect to
+I2P addresses with a non-zero port number because with SAM v3.1 the destination
+port (`TO_PORT`) is always set to 0 and is not in the control of Bitcoin Core.