Reimagining Onion Messages as an Overlay Layer

In the realm of Lightning Network (LN) development, there's a nuanced approach to how nodes manage and store node_announcement messages. Nodes currently only retain a node_announcement if the node in question maintains active channels. This storage policy is further refined by the behavior of lnd (Lightning Network Daemon), which actively prunes any node_announcement that no longer has associated channels following the evaluation of closed channels within a block. This pruning process ensures the network remains efficient by discarding unnecessary data.

An important aspect of this system involves the handling of onion_link_proof, a form of public verification. For an onion_link_proof to be deemed valid and accepted by the network, it is required that both nodes involved have active channels. This criterion can be further tightened by clients who may choose to only recognize onion_link_proof from nodes meeting specific criteria, such as having a minimum number of channels or a certain amount of BTC across these channels.

These mechanisms are part of the broader strategy for integrating onion routing into the LN without directly embedding it within the LN channel graph. Instead, the onion overlay is anchored to the existing channel graph, leveraging its structure for routing while maintaining a separate layer for enhanced privacy and security. This approach reflects a balance between leveraging the existing infrastructure of the LN and introducing new features that enhance its functionality and user experience.