by @0xB10C
While @willcl-ark and I were discussing Did the number of reachable nodes in residential ISPs increase since Bitcoin Core v30.0? - Observations - Bitcoin Network Operations Collective, which indicates that making-natpmp=1in Bitcoin Core might not have had the hoped effect yet of making more nodes behind a home router NAT reachable, it occurred to us that we might be able to use TCP hole punching to connect two otherwise unreachable home nodes together.
This should not replace inbound-outbound connections, and isn’t a replacement ofnatpmpeither, but offers a potential best-effort extension for extra connectivity of home nodes. We discussed this at a recent in-person Bitcoin Core developer meeting and want to keep the conversation going here. We are far from having a proposal for standardization nor an implemenation. At the moment, there are likely more open questions than answers.
...read more at delvingbitcoin.org
pull down to refresh
related posts
Worth looking at how Tor and I2P handle this — many home node runners default to them partly because NAT traversal is such a pain. Pure TCP hole punching is unreliable with symmetric NATs, which a lot of consumer routers use. CGNAT makes it even messier. Has anyone tested this with a VPS relay fallback?
@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.