TCP hole punching for Bitcoin nodes behind home NATs?

The discussion centers on the design and trade-offs between short-lived and long-lived network connections for nodes interacting with a message board system, particularly in peer-to-peer networks relying on techniques like hole punching. Short-lived connections involve periodic reconnections where a home node registers itself, exchanges addresses, and then disconnects, repeating this process at intervals. While this approach can allow boards to support more candidates due to lower resource requirements per connection, it introduces latency and potential staleness in information, as new endpoints take longer to propagate and can expire before being updated. Moreover, repeated handshakes and maintenance of NAT/firewall mappings slightly increase bandwidth consumption and operational complexity.

In contrast, long-lived connections remain open as long as the home node is interested in participating. This allows the message board to proactively push updates about newly registered home nodes to all connected participants, improving the speed and reliability of endpoint discovery and making hole punching more efficient. However, supporting many long-lived connections increases the resource burden on the board, potentially limiting the number of simultaneous participants. Long-lived connections also enhance security by raising the cost for attackers, since maintaining persistent access requires a greater investment in IP addresses and network resources.

Addressing the issue of Sybil attacks, where adversaries create numerous fake identities to gain disproportionate influence, several mitigations are proposed. Nodes and boards should implement deduplication based on IP address and apply limits by network group or autonomous system (AS). This strategy compels attackers to distribute their efforts across diverse networks, increasing the cost and complexity of mounting successful attacks. Nonetheless, these measures can inadvertently penalize legitimate users clustered within the same network segment.

The transition from centralized hub-based topologies, where data center-hosted nodes act as critical connectivity points, to more decentralized mesh-like structures enabled by hole punching is explored. If cloud service providers restrict or prohibit running such nodes, direct connections between home nodes become vital for network resilience and censorship resistance. Message boards serve as facilitators for sharing addresses rather than as permanent intermediaries for transaction or block relay, minimizing their bandwidth and CPU demands while expanding the network’s capacity for direct inter-node communication.

Concerns are raised about misuse of home nodes’ resources, especially if incoming traffic resulting from hole punching overloads typical residential internet connections. There is an emphasis on ensuring that participation does not inadvertently disrupt essential household activities.

A proposal suggests integrating board functionality directly into Bitcoin Core, allowing any standard listening node to function as a message board. This democratizes the availability of message boards and reduces reliance on specialized infrastructure. However, there remains a need to safeguard against non-network-specific abuse, ensuring that such boards do not become general-purpose storage for unrelated data. Even minimal requirements—such as maintaining an open connection to store an address and small payload—should be managed carefully to prevent exploitation.

For further insight into these technical discussions, reference can be made to the ongoing community conversations and development notes available through relevant channels.