Default IP and onion P2P ports conflict with each other, and with Bitcoin Core default onion P2P port

[JeremyRand]

Upstream Bitcoin Core listens on two P2P ports: port 8333 (for IP connections) and port 8334 (for Tor onion service connections), as per this log from Bitcoin Core:

2024-08-14T19:52:08Z Bound to 127.0.0.1:8334
2024-08-14T19:52:08Z Bound to [::]:8333
2024-08-14T19:52:08Z Bound to 0.0.0.0:8333

Meanwhile, Namecoin Core listens on port 8334 for both IP and onion P2P connections, as per this log (tested with b3b7c95):

2024-08-14T19:57:15Z Bound to 127.0.0.1:8334
2024-08-14T19:57:15Z Bound to [::]:8334
2024-08-14T19:57:15Z [net:error] Unable to bind to 0.0.0.0:8334 on this computer. Namecoin Core is probably already running.

This results in three problems:

1. Namecoin Core cannot accept any incoming IPv4 or onion connections if Bitcoin Core is also running (unless either Bitcoin Core or Namecoin Core has been manually configured to use different ports).
2. Namecoin Core cannot accept any incoming IPv4 connections because it conflicts with itself (unless Namecoin Core has been manually configured to use different ports).
3. Latest Bitcoin Core master (and Namecoin Core with it) makes both of the above problems a fatal error that prevents launching at all.

Open questions on how to fix it:

1. What ports should we switch to for IP and onion?
2. Does our RPC port conflict with anything in Bitcoin Core?
3. How should we do the transition so that we don't accidentally partition the network?

I have ideas on fix strategy which I will post in a bit, but curious what Daniel thinks.

(Thanks to @tfreedman from Cyphrs for reporting the launch failure.)

[JeremyRand]

We should presumably check the P2P IP, P2P onion, and RPC ports for testnet and regtest for conflicts as well.

[JeremyRand]

Latest Bitcoin Core master (and Namecoin Core with it) makes both of the above problems a fatal error that prevents launching at all.

This symptom is probably a blocker for the 28.0 release.

[JeremyRand]

Suggested mitigation strategy:

1. v28.0: Switch the incoming onion port. This resolves the immediate v28.0 blocker. It shouldn't cause a partition since virtually no one is exclusively connecting to onion peers.
2. v28.1: Make outgoing IPv6 connections based on DNS seed results try both a new port and the existing port.
3. v28.2: Add a new default incoming IPv6 port (leave the old one there too).
4. v28.3: Add a DNS seed that returns IPv6 peers with the new port.
5. v28.4: Make outgoing IPv4 connections based on DNS seed results try both a new port and the existing port.
6. v28.5: Add a new default incoming IPv4 port (leave the old one there too).
7. v28.6: Add a DNS seed that returns IPv4 peers with the new port.
8. v28.7: Disable old default incoming IPv6 port.
9. v28.8: Disable old IPv6 DNS seed.
10. v28.9: Disable old outgoing IPv6 port.
11. v28.10: Disable old default incoming IPv4 port.
12. v28.11: Disable old IPv4 DNS seed.
13. v28.12: Disable old outgoing IPv4 port.

The intent of doing this gradually is to minimize the amount of network disruption at any given time (this will cause some network disruption). Each change will not be committed to Git until DNS seed metrics show that the previous change is reasonably widespread on the P2P network. If v29.0 is tagged prior to some of the above being committed, then we will apply them to the 29.x series rather than 28.x, etc.

[domob1812]

Plan sounds good to me. Changing the onion port is most likely not an issue at all, and something we can do immediately. Changing the other ports based on how the network upgrades seems like a good idea. My guess is that it will update very slowly, though.

[JeremyRand]

OK, so my suggestion is that we use port 8534 as the new RPC port, port 8535 as the new P2P port, and 8536 as the new onion port. Rationale:

• It's a contiguous port range, like what Bitcoin does.
• It's in the same order as Bitcoin's range.
• None of these ports are widely used by existing applications. The only mention of any of these ports I can find in any of the port databases is that port 8536 is used by an obscure malware program that I doubt has been active for quite a while. (And if we cause a user-visible conflict with a malware program, that doesn't seem like a bad thing. Poor-man's antivirus?)
• The two ports below this range, and the five ports above this range, also seem to be unused by common applications, which reduces the risk that future conflicts will arise.

Does this plan sound good? Should I submit a PR for changing the onion port?