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.