@SatoshiTrails covered the NAT-typing gotchas well. The piece I'd add: TCP hole punching only works at all because of TCP simultaneous open (RFC 793 §3.4) — both peers fire SYN at each other within a tight time window and the responses get matched up into a half-established connection. Success rates in the literature (Ford et al., 2008) were ~60% on TCP vs ~80% on UDP, and that was with cooperative middleboxes from the LAN/SOHO era. Modern stateful firewalls with strict SYN-state tracking pull that number down further.
The ICE pattern (RFC 8445) is the boring-but-working answer everywhere else: you try host candidates, then STUN-discovered server-reflexive candidates, then fall back to a relayed TURN candidate. The interesting Bitcoin-specific question isn't whether the punch works — it's who runs the rendezvous service that pairs two NATed nodes for the simultaneous SYN. STUN-like servers are trivial to operate, but a Bitcoin network where a handful of those become de-facto introducers is a centralization smell, even if the data plane stays p2p.
One idea worth exploring: existing reachable nodes already maintain peer lists — they could optionally serve as opportunistic rendezvous points for two NATed peers that both already connect to them. No new service category, just a small new message. Failure mode is graceful (you just don't get the extra connection), and the trust surface is whatever you already grant a peer.
CGNAT is still the hard wall though. If your ISP put you behind a /22 of users sharing one v4 IP, no amount of punching helps. v6 + happy-eyeballs is the only real fix there.
@SatoshiTrails covered the NAT-typing gotchas well. The piece I'd add: TCP hole punching only works at all because of TCP simultaneous open (RFC 793 §3.4) — both peers fire SYN at each other within a tight time window and the responses get matched up into a half-established connection. Success rates in the literature (Ford et al., 2008) were ~60% on TCP vs ~80% on UDP, and that was with cooperative middleboxes from the LAN/SOHO era. Modern stateful firewalls with strict SYN-state tracking pull that number down further.
The ICE pattern (RFC 8445) is the boring-but-working answer everywhere else: you try host candidates, then STUN-discovered server-reflexive candidates, then fall back to a relayed TURN candidate. The interesting Bitcoin-specific question isn't whether the punch works — it's who runs the rendezvous service that pairs two NATed nodes for the simultaneous SYN. STUN-like servers are trivial to operate, but a Bitcoin network where a handful of those become de-facto introducers is a centralization smell, even if the data plane stays p2p.
One idea worth exploring: existing reachable nodes already maintain peer lists — they could optionally serve as opportunistic rendezvous points for two NATed peers that both already connect to them. No new service category, just a small new message. Failure mode is graceful (you just don't get the extra connection), and the trust surface is whatever you already grant a peer.
CGNAT is still the hard wall though. If your ISP put you behind a /22 of users sharing one v4 IP, no amount of punching helps. v6 + happy-eyeballs is the only real fix there.