Skip to content

Latest commit

 

History

History
51 lines (31 loc) · 6.32 KB

2022-02-16-#23542.md

File metadata and controls

51 lines (31 loc) · 6.32 KB
Raw

PR#23542 - Open p2p connections to nodes that listen on non-default ports 👀

A PR by Vasil Dimov to remove the preferential treatment of port 8333 in the selection of outbound peers. Participants discussed Bitcoin Core’s automatic connection behavior, the benefits of a network with no default port, and rationale for avoiding certain ports.

Questions

What were the historical reasons for the preferential treatment of the default port? 🔗

  • Common folklore suggests that is to prevent malicious peers from leveraging the P2P network to perform a DoS attack on other services by spamming addr messages with their IP/port.

    • Vasil Dimov calculated that the impact of this is actually very low.

  • The historical reason, based on some (alleged) leaked Satoshi emails, was the concern about eclipse attacking. Someone being able to listen on 1000s of ports on the same machine, rumouring all of those as separate addrs, and thereby sort of cheaply eclipse attacking the network.

  • In a discussion on issue #5150 it is stated that this discrimination on port number

     if (addr.GetPort() != Params().GetDefaultPort(addr.GetNetwork()) && nTries < 50) {
 	continue;
 }

    was added by Pieter Wuille in PR#787 - CAddrMan: stochastic address manager but with no explanation of why that limit exists. He later responded with the aforementioned folklore reason.

What are the benefits of removing this preferential treatment with this PR? 🔗

  • The historical reasons are not an issue anymore since addrman doesn't treat multiple ports on the same IP any different from multiple IPs in the same range. Given these changes to the address manager (‘addrman’) and address relay, the preferential treatment has little impact on the prevention of eclipse and DoS attacks.
  • Today using port 8333 is yelling "bitcoin node here!!" (privacy leak) and it's practically impossible to use any other port due to the discouragement rule.
  • Even with the change, incoming Bitcoin connection traffic would still be identifiable without too much effort but blocking it is not as easy as just blocking a single port.
    • ISPs aren't free from government intervention/regulation. So theoretically an ISP or local network admin could drops stuff that's going to a 8333 port. It's much easier for a gov to say "block port 8333" than the vague "block all bitcoin traffic".

Before this change, automatic connections to peers listening on non-default ports were discouraged, but not impossible. Under what circumstances would a node still connect to such a peer? 🔗

  • In the automatic connection logic, the node attempts to connect to addresses randomly selected from its address manager. If no connection has been successful after 50 attempts, it will start considering non-default addresses.
  • This behavior is now kept the same for the "bad port" list, so if nothing else works for 50 tries, we'll also try a "bad port". So our treatment of "bad ports" is how we used to treat non-8333, and the non-bad ports (non-bad & non-8333 and 8333) are treated the same as how we used to treat 8333.
  • It's not that functionality to connect to custom ports doesn't exist (it has always existed), and for manual connections (used by nodes in the functional tests) you can do whatever you like. The change is that this PR stops the automatic outgoing connection selection mechanism from disfavoring non-8333
    • ThreadOpenConnections which comes before this non-default port logic, allows you to specificy manual addresses to connect to.

After this PR, the default port still plays a role in bitcoin core. Where is it still used? Should it be a long-term goal to abandon the notion of a default port entirely? 🔗

  • If no port is provided it is used as our default listen port. The default port is also added to the DNS seeder results we get, to be able to connect to theses addresses and save them to addrman.
    • The DNS system isn't designed for resolving ports, only IPs. But there are alternatives to using DNS in the first place.

The PR introduces a list of “bad ports” that was taken from internet browsers. Do you agree with having a list like this in general? Are there any reasons to deviate from the list used by browsers? 🔗

  • There is issue #24284 with a suggestion to also include ports used by browsers (which are obviously not on the browser's lists) but Pieter Wuille said that because 80 and 443 (http and https) are very commonly "public services", that always get connections from everywhere, may be particularly good choices to run a bitcoin node because everyone uses them, thus traffic isn't looked into deeply. So we want to keep the possibility, after BIP-324, of disguising Bitcoin P2P traffic as https traffic in the future.

What is the reason for allowing callers to pass salts to CServiceHash and then initializing it with CServiceHash(0, 0) in commit d0abce9? 🔗

  • We always use the same salt so that, if we get the same address again (within the 24hr time slot), we relay it to the same "random" peers, so there's no advantage to sending us the same address twice. We achieve that by using deterministic randomness using integer division which causes the hashed message to change only every 24h thus the same IP:port leads to the same hash consistently within that 24h time slot.