TCP hole punching for Bitcoin nodes behind home NATs?

The design for the Bitcoin P2P rendezvous protocol involves a novel approach to enabling inbound connections for nodes like Alice's that are situated behind NAT. The process initiates when Alice identifies Charlie as a node providing RENDEZVOUS services through her ADDRMAN. Alice then establishes a RENDEZVOUS-only connection with Charlie and uses ADDRv2 network type to advertise her accessibility via Charlie. Bob, who seeks nodes for establishing outbound connections, opts to connect with Alice by coordinating through Charlie. This trio attempts a TCP-hole-punched connection following the method detailed in this document. If Alice has available inbound slots after this interaction, she reconnects with Charlie, ready for new connections.

Despite the operational mechanics, there remains an underlying concern about the trust and authority assigned to Charlie within this setup. Since Charlie manages the decision on whether Bob can successfully connect to Alice, he inherently influences the outcome of these connection attempts. This situation raises questions about the potential for Charlie to manipulate these outcomes similar to how misleading address advertisements could be abused. To mitigate such risks, it could be considered prudent to treat all addresses associated or routable via Charlie as a singular entity. This would mean Bob randomly choosing "Charlie" for the initial connection followed by another random selection from the collective pool of addresses linked to Charlie. This strategy not only diversifies the connection points but also maintains a uniform assumption about trust across multiple parties (n) involved in the network's foundation, which is analogous to the number of independent parties one must rely on during initial network interactions.

Furthermore, comparing this mechanism to Tor/I2P networks, where each node can independently serve as a RENDEZVOUS point, highlights additional vulnerabilities. Specifically, in environments like Tor/I2P, the reliance shifts towards the rendezvous points rather than the actual destination addresses, due to potential threats from malicious actors flooding the network with deceptive or non-functional relays targeting legitimate addresses. This comparison underscores the complexity and potential security concerns inherent in managing decentralized, anonymous connections across such networks.