Published on: 2019-11-12T13:49:00+00:00
In a recent discussion on the tor-dev mailing list, concerns have been raised about the security of HORNET and other onion sessions. A paper shared in the thread suggests that the current rendezvous proposals lack smart retries and useful routing failure data, making them potentially less secure than previously believed. However, the paper proposes addressing this issue off-protocol through intermediary interaction between users and websites.To improve the efficiency of payments on the Lightning Network, the possibility of Trampoline routing is being explored. Trampoline nodes along the payment route can aggregate incoming multi-part payments and decide how to split outgoing aggregated payments based on their knowledge of local channel balances. This would enable high AMP payments and better rendezvous routing than normal payments.One of the issues with rendezvous routing is the need for the recipient to communicate their part of the onion to the sender. Using a Bolt 11 invoice for this purpose adds additional bytes per partial payment. Bitcoin Trampoline addresses this by doing the pre-encryption on a smaller Trampoline onion, reducing the size to 466 bytes compared to 1366 bytes with a Bolt 11 invoice. This allows rendezvous routing to benefit from Trampoline's ability to do multi-part at each hop, improving efficiency.While Trampoline routing offers these benefits, it also has trade-offs that may impact privacy. Paying to legacy nodes that don't understand the Trampoline onion could compromise privacy. The Eclair team is currently implementing Trampoline to identify areas where it falls short and develop a spec that minimizes these trade-offs.Bastien Teinturier, a member of the Eclair team, has proposed using Bitcoin Trampoline to improve rendezvous routing in Lightning Network payments. Rendezvous routing allows the recipient to create their part of the onion and communicate it to the sender via a Bolt 11 invoice. However, this method requires additional bytes and upfront decisions on splitting multi-part payments. Trampoline onions offer pre-encryption on a smaller onion, enabling multi-part payments at each hop and improving efficiency. The proposal also addresses payment failures by providing a communication channel between the sender and receiver to exchange further payment information and decrypt opaque errors. Trampoline routing acknowledges privacy trade-offs when paying to legacy nodes but aims to minimize these through ongoing experiments and spec development.Trampoline routing avoids the need for lite nodes to store the entire network graph and compute long-hop routes. Instead, it enables route computation delegation, which trades hardware requirements against privacy leaks and higher fees. However, the current trampoline proposal exposes legacy payees without their opt-in. To address this, the receiver could implement trampoline routing and hide behind the feature flag.The implementation of Trampoline routing requires careful design and deployment to avoid false promises of privacy. Privacy features are being added incrementally, such as random_scid work and rendezvous, to ensure that privacy concerns are appropriately addressed. The cryptographic details of the proposal are not provided, but feedback and ideas are welcomed.In summary, the Lightning Network is exploring the possibility of Trampoline routing to improve payment efficiency. Trampoline nodes can aggregate and split payments based on local channel balances, enabling high AMP and better rendezvous routing. However, privacy trade-offs exist, particularly when paying to legacy nodes. The Eclair team is working on implementing Trampoline and developing a spec to minimize these trade-offs. Careful consideration is required to ensure the design and deployment of Trampoline routing provide the desired privacy and performance benefits.
Updated on: 2023-07-31T22:12:10.711292+00:00