Published on: 2015-12-09T10:19:25+00:00
In a discussion on the Lightning-dev mailing list, Mats Jerratsch and Rusty Russell addressed the issue of using onion routing for sending messages over the Lightning network. The conversation focused on determining what should be sent through onion routing and what shouldn't. The goal was to separate messaging from payments by having the vendor negotiate with a node to forward a payment and then have the buyer route to that node. However, concerns were raised about spam and payment disputes. If lightning is used for messaging, the recipient could claim the route failed and not pay for the message. Trusting nodes also raises questions about security and reliability.Mats Jerratsch proposed implementing an interactive wallet-to-wallet protocol to address these concerns. This protocol would occur while both sides are busy communicating with the onion routing network for actual payment route negotiation. Once a path is found, the recipient would then communicate over the wallet-to-wallet channel to pass over the fully-constructed onion routing information. However, defining the wallet-to-wallet channel and maintaining privacy could be challenging. Jerratsch suggested a simplified message-delivery system where each hop costs 1 satoshi, but acknowledged that increasing the load for nodes could be problematic. If necessary, they might explore using HTLCs, although this could lead to impracticality and bloated commit transactions.In a previous email conversation in 2015, Mats Jerratsch had raised the question of whether onion-routing should be one-time and one-directional. The preferences regarding what data should be sent through onion routing were unclear. There was a suggestion that an interactive wallet-to-wallet protocol could take place while both parties communicated with the onion routing network for payment route negotiation. Once a path was found, the recipient would communicate over the wallet-to-wallet channel to pass fully-constructed onion routing information back. While this would reduce message passing in the onion land, it would increase the complexity of the payment side.The proposed system for privacy in payment transactions involved using Onion Routing, which routes payments over a rendezvous point and encrypts them using an onion scheme. The sender and receiver would not learn any additional information about each other by default. However, there was a question about whether the onion-routing should be one-time and one-directional or not. In the previous design, the onion objects were filled with zeros, making it impossible for the receiver to send a message back to the sender. The author proposed integrating a message system where each node could encrypt and append the pubkey of the node it received the object from, along with the ephemeral key used initially. This would allow the receiver to send a message back by encrypting it using the designated ephemeral key included by the sender and using the onion object to send it back. The author acknowledged potential security risks if someone obtained the onion object and targeted the nodes one by one to 'hunt down' the sender. Additionally, providing reasonable DoS protection against unnecessary messages spamming the network posed a challenge. One suggestion was to assign super tiny payments to the process of sending a message to counter spam, but implementation difficulties were acknowledged.
Updated on: 2023-07-31T18:42:31.920509+00:00