Reimagining Onion Messages as an Overlay Layer

Reimagining the deployment of onion messaging within the Lightning Network (LN) offers a promising alternative to the current model, which is tightly integrated with the channel graph. This integration introduces several limitations, such as a slow adoption path, an unnecessarily large messaging graph diameter, mixed networking concerns, and misses out on supporting native key management. By proposing an overlay layer for onion messaging, bootstrapped using the LN gossip layer, we can address these issues effectively.

The current deployment of onion messaging requires a complete or near-complete adoption across the network due to its reliance on established channel links for message transmission. This all-or-nothing approach not only hampers the deployment timeline but also affects user experience (UX) negatively by forcing clients to frequently connect directly to message recipients, compromising privacy and increasing latency in payment attempts. The proposed overlay layer concept facilitates rapid, incremental deployment, segregates various operational concerns, and potentially enhances reliability and reachability through a dynamic overlay topology.

By decoupling onion messaging from the channel graph and establishing it as an overlay layer, we can significantly reduce the graph diameter necessary for message traversal. This reduction in node hops for a BOLT 12 payment request, for instance, would decrease the overall latency, improving the payment experience compared to the existing BOLT 11 flow. Furthermore, the current use of static keys for onion messages, due to the lack of a global node identity rotation protocol, impairs message privacy over time. An overlay layer could facilitate key rotation, preserving the forward secrecy of messages.

The technical aspects of implementing this overlay layer involve utilizing the existing LN gossip network for bootstrapping and establishing new onion messaging links through a series of TLV-based handshake messages. These include onion_link_req, onion_link_resp, onion_link_sign, and onion_link_proof messages, which collectively authenticate the establishment of an onion messaging link between two nodes. This process ensures that only verifiable connections are utilized for onion messaging, mitigating spoofing risks.

Moreover, the overlay architecture supports rapid experimentation and development of new features without impacting the broader payment network. Examples of potential innovations include payment-level acknowledgments and retryable payments, which could improve pathfinding efficiency and payment reliability. The proposal for connection establishment outlines a detailed sequence involving mutual authentication and verification between initiating and responding nodes, leveraging Musig2 signatures for secure link establishment.

In summary, adopting an overlay layer for onion messaging within the Lightning Network presents a strategic opportunity to overcome existing limitations by enabling faster deployment, improved privacy through key rotation, and a more efficient messaging graph. This approach not only enhances the scalability and flexibility of onion messaging but also maintains interoperability with the current deployment, allowing for coexistence and seamless transition towards a more refined infrastructure.