This is a really great deep dive into how nodes connect to each other and what the network part of Bitcoin looks like. Reading this article is a massive step forward in learning about how Bitcoin nodes actually work. Take half and hour and really check it out.

Here are some highlights:

@deadmanoz made this great graphic showing the different kinds of connections your node makes:

It's full of great details about how nodes connect to other nodes. For instance, there's this bit about feeler connections:

Feeler connections are short-lived outbound connections opened approximately every 2 minutes to test whether addresses in the node's peer database are reachable, promoting them from the new table (learned via gossip, untested) to the tried table (successfully connected to at least once) on success. These tables are part of the node's address manager (AddrMan), which tracks known peer addresses and is complex enough that it will be covered in a future post.

Or this about how changes in ISP ip address provisioning affect people who want to run a node that accepts inbound connections behind a consumer router:

However, a growing share of connections never receive a public IP at all. Carrier-Grade NAT (CGNAT) places multiple customers behind a shared public IP at the ISP level, so port forwarding on the home router is useless. Mobile networks use CGNAT almost universally, and fixed-line adoption is growing as all five Regional Internet Registries have exhausted their IPv4 free pools. For node operators behind CGNAT, the main workarounds are overlay networks: Tor hidden services (.onion), I2P (supported since Bitcoin Core v22.0 with PR #20685), or CJDNS (since v23.0 with PR #23077), all of which bypass NAT entirely.

And this very nice list of the hardcoded DNS seeds in Bitcoin Core v31 which your node will rely on if it is brand new or has no connection to other bitcoin nodes:

As of v31, Bitcoin Core's mainnet configuration includes eight hardcoded DNS seeds in src/kernel/chainparams.cpp:

The x prefixed service bit filters (e.g. x9 = NODE_NETWORK | NODE_WITNESS) allow seeds to return only nodes advertising specific service flags.

And how to use the new privatebroadcast feature in Bitcoin v31 (#1410542)

PRIVATE_BROADCAST is new in v31, enabled via the opt-in -privatebroadcast flag (off by default). These connections use a dedicated 64-slot budget, completely separate from the regular outbound pool. They open short-lived connections exclusively over privacy networks (Tor, I2P) to relay transactions submitted locally via RPC, then close (such that transaction broadcast over privacy networks never competes with regular outbound connection slots).

I really dug this bit on the importance of bridge nodes (nodes that have connections on more than one network - ie. tor and ipv6 or i2p and ipv4):

The Bitcoin network spans multiple overlay networks: IPv4, IPv6, Tor, I2P, and CJDNS (Figure 4). Most nodes are only reachable on one or two of these, meaning peers within one overlay can become isolated from peers on another if there aren't enough nodes straddling both. Nodes that maintain connections across multiple network types act as bridge nodes, forwarding blocks and transactions between overlay networks that would otherwise have limited or no connectivity to each other.

Bridge nodes are critical for preventing network partitioning along transport boundaries. If, for example, the Tor-only segment of the network lost all connections to IPv4 peers, those Tor nodes would effectively be on a separate network, unable to see new blocks or transactions from the IPv4 majority, and vulnerable to eclipse attacks within their isolated segment. Bridge nodes prevent this by ensuring that block and transaction propagation can cross network boundaries.

The whole article is very much worth the read. Great work!