# TCP hole punching for Bitcoin nodes behind home NATs? **URL:** \ **Category:** Protocol Design\ **Created:** [May 11, 2026, 7:55am UTC](https://delvingbitcoin.org/t/tcp-hole-punching-for-bitcoin-nodes-behind-home-nats/2497 "2026-05-11T07:55:30Z")\ **Posts on this page:** 1\ **Showing post:** 18
**Author:** ![0xB10C](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/0xb10c/32/15_2.png) [@0xB10C](https://delvingbitcoin.org/u/0xB10C)\ **Post date:** [October 13, 2026, 9:33am UTC](https://delvingbitcoin.org/t/tcp-hole-punching-for-bitcoin-nodes-behind-home-nats/2497/18 "2026-10-13T09:33:44Z")
We’ve picked up work on this again a bit to come up with an LLM spec/BIP and an implementation in Bitcoin Core to experiment with it a bit more. Will share more on this later. First, I wanted to recap the (four?) approaches that were discussed here and share some thoughts: All four approaches share can share the same `rendezvous` (you can find me here) and `punch` (start the hole punching now) messages. 1. Third-node coordinator: A announces “find me through C” to the network. B picks that announcement, asks C for a rendezvous with A, and C sends `punch` to both. B chose A, and A opted in to being found through C. C sees a pairing happened but nothing else. The network learns that A and C are/were connected, which might leak network topology (which is not great). 2. The advertiser’s own Tor service: A runs a second, unadvertised onion service whose only job is this, and announces “find me through this onion”. B reaches it over Tor, asks, and A answers with `punch` itself. No third party C. Tor only carries the request, the punched connection is clearnet. Needs Tor on both ends, and the onion identity has to be replaced whenever A’s address changes so it can’t be used to follow A across ISP-assigned addresses. Does not leak network topology. 3. Matchmaking pool: Nodes tell a coordinator “put me in your pool”, and the coordinator pairs up two members on its own. Here, nodes don’t choose who they connect to, and both sides of the connections are essentially “inbound”, which is weird and not ideal. 4. Handoff instead of eviction: When a full node has to drop an inbound peer, it first introduces that peer to another of its inbound peers so the two connect directly, then drops it. In 1 and 2 every punch is the answer to something the receiving node asked for, so a node only ever dials a peer it chose (B picked A) or agreed to be found by (A opted in through C). In 3 and 4 the node doesn’t choose. The coordinator decides who it connects to, and the punch arrives unasked. A question I’ve been thinking about more generally: While this feature sounds and looks very cool, what problem does it actually solve? And do the different approaches solve different problems? Which one of them is actually worth the work that would need to go into this? --- _[View the full topic](https://delvingbitcoin.org/t/tcp-hole-punching-for-bitcoin-nodes-behind-home-nats/2497)._