Published on: 2020-03-02T11:39:49+00:00
Christian and Bastien are discussing privacy concerns with partial onion routing as a solution to the issues with full onion routing. They discuss the tradeoff between the size of the onion and the number of hops it can have. Christian plans to expose the size to be prefilled so that smaller partial onions can be used, allowing the chaining of multiple partial onions. The shared secret used for the prefill stream is derived from both the ephemeral key and RV's private key, ensuring security and preventing leakage of information.Christian mentions that payment errors won't be readable by RV since the recipient generates the onion and RV doesn't have the shared secrets. Any error beyond RV should be treated as a "rendezvous failed, discard partial onion" situation. However, Bastien points out that each hop's amount/cltv is fixed at invoice generation time by the recipient, which means MPP cannot be used. Additionally, if any channel along the path updates their fee, the partial onion becomes invalid unless the fees are overpaid. Bastien suggests that Trampoline could address this issue by providing more freedom for each trampoline node to find an efficient way to forward to the next trampoline. However, it is not clear how to combine these two proposals effectively.The proposal for rendezvous routing in the Lightning Network involves dropping the partial onion to fit into an outer onion, creating space for other features without increasing the QR code's size. The receiver generates an onion with the route specifying the trimmed partial onion as a payload, and the rendezvous node verifies the parameters, extracts the partial onion, and reconstitutes the original routing packet. However, there are challenges with each hop's amount/cltv being fixed at invoice generation time and integrating rendezvous on normal onions into invoices due to their size. Rendezvous on the trampoline onion could be a more practical option.Bastien seeks advice and feedback on implementing rendezvous routing and reconciling it with HMACs used to protect payments. He suggests that rendezvous on normal onions would be costly to integrate into invoices, while doing rendezvous on the trampoline onion could have better properties. He encourages others to share their ideas on implementing rendezvous routing correctly. He also mentions that while Hornet offers useful features for the future of Lightning, having a custom rendezvous scheme available soon could still make sense.The Lightning-dev mailing list serves as a platform for developers working on the Lightning Network to discuss technical issues. It aims to improve Bitcoin's scalability and transaction speed through layer-2 payment channels. The discussion in the email thread focuses on technical details related to rendezvous routing and the challenges involved. Developers are sharing ideas and seeking feedback to enhance the functionality and efficiency of the Lightning Network.
Updated on: 2023-07-31T22:41:59.711155+00:00