TCP hole punching for Bitcoin nodes behind home NATs?

The issue of whether most nodes should accept random inbound connections poses significant security implications and practical considerations within peer-to-peer networks. The default setting, which allows for these connections, is intended to enhance connectivity across the network as noted in a recent GitHub pull request (see PR). This configuration aims to maintain a robust and uniform peer-to-peer graph by facilitating direct connections to nodes, including those with dynamic IP addresses or behind NAT setups.

However, the benefits of a more interconnected network might be overshadowed by the risks associated with increased exposure to potential attackers who could exploit multiple inbound connections to target specific nodes. For individuals without a publicly routable IP address, the lack of reachability could paradoxically serve as a protective barrier, thereby reducing susceptibility to certain types of network attacks.

In scenarios where direct node connectivity is essential, such as connecting to one's own node or that of a known associate, additional security measures are advisable. Using authentication mechanisms and potentially employing VPN solutions could mitigate some of the inherent risks. Moreover, an alternative method for establishing secure connections involves implementing a remote procedure call (RPC) specifically designed for interaction between verified parties. This could be coordinated through secure communication channels like phone, Signal, or other encrypted messaging services, offering a tailored solution that prioritizes both connectivity and security within the network infrastructure.