Proposals to use TCP hole punching to make bitcoin node running behind router.

[hmbdofficial]

One interesting discussion from this weeks Optech Newsletter is the proposal to use TCP hole punching to make bitcoin node running behind home routers more reachable. It’s said that currently many home nodes can establish outgoing connection but cannot easily accept incoming connections because of NAT restrictions. Thats where the whole idea of the hole punching came from and it is to allow two node to open connections to each other at nearly the same time making direct communication possible without traditional port forwarding.

What’s you guys honest view about this proposal? And what challenge do you think this may pose.
You can read the full proposal on the link provided below.
https://bitcoinops.org/en/newsletters/2026/11/06/

[Antidote47k]

It’s an interesting proposal. I understand the need to make home nodes more reachable, the network will benefit tremendously from a having a more diverse network of independent nodes, homes nodes generally does not accept incoming connections due to NAT which makes the network more dependent on a smaller group of publicly reachable nodes, but I’m afraid this introduces another concern, attackers are smart these days, they could make establishing direct connections to honest nodes much easier which will give them the opportunity to surveil, deny service or potentially exploit vulnerabilities.

Improving connectivity doesn’t automatically improve security. The real question is how do they improve connectivity of honest nodes to diverse peers without making it easier for attackers to reach targeted nodes? I think the implementation should account for this, aside from that, a really good proposal I would say. 

[eternalgloom]

IDK, if everything will be that smooth.
Considering TCP level bugs, wouldn't keeping inbound connection closed be safer default for home users?

Being behind any firewall means having an extra layer of security. If any new attack vector is opened while doing hole punching, you're back in risky territory.

Again, peer to peer timing and shared secret or block based derivation working properly without any central server or coordinator is very difficult. I'm 100% sure attackers will exploit those loophole to manipulate system and confuse firewalls.

If you think about Tor or other alternative routes there will be latency or other complexity.

[ABCbits]

First of all, is there any developer or contributor willing to develop and maintain this feature? I'm not familiar with this technology. But on article that explain how NAT translation (hole punching) works, they claim TCP based one is more complex and i expect TCP based one is less popular.

We’ll be discussing these techniques generically, using Tailscale and others for examples where appropriate. Let’s say you’re making your own protocol and that you want NAT traversal. You need two things.

First, the protocol should be based on UDP. You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go. We’re going to focus on UDP for the rest of this article.

[Stefen003]

A few technical points that might help frame it:

1. It only helps some NATs. Hole punching works well behind full-cone and (port-)restricted-cone NAT, but mostly fails behind symmetric NAT and carrier-grade NAT, which is very common on mobile and many ISP connections now. So the gain is real but partial; it won't make every home node reachable.

2. It needs a rendezvous step. Both sides must learn each other's external ip:port and dial at nearly the same moment (TCP simultaneous open). No central server is required though: an existing outbound peer that both nodes are already connected to can relay the "connect to me now" message, similar to how libp2p's DCUtR works. That raises the real design questions: the coordinating peer learns both IPs and that they want to connect (privacy), and coordination messages need strict rate-limiting so they can't be abused to make nodes spray connection attempts (DoS).

3. On the "keep inbound closed is safer" concern: a punched hole isn't the same as opening a listening port to the whole internet. On restricted/port-restricted NAT the mapping only accepts packets from the specific remote ip:port your node itself dialed, and it expires when idle. The attack surface is basically the same as any outbound connection your node already makes. The bigger risk is in the coordination logic itself, not the punched socket.

4. It complements what already exists. Since v29 Bitcoin Core supports PCP/NAT-PMP (-natpmp) for automatic port mapping (replacing the old UPnP code), plus IPv6 and Tor/I2P for inbound. Hole punching would mainly matter for users none of those reach.

And as ABCbits hints, TCP hole punching is less reliable than UDP in practice, so whoever implements it should expect a lot of real-world NAT testing before it's useful.