Author: Bastien TEINTURIER 2019-11-12 13:49:00
Published on: 2019-11-12T13:49:00+00:00
In a recent thread, HORNET and other onion sessions were discussed, but a paper shared on the tor-dev mailing list suggests they may be less secure than previously believed. The current rendezvous proposals are one-shot only, lacking smart retries or useful routing failure data. However, this issue could potentially be addressed off-protocol through intermediary interaction between users and websites. Trampoline enables high AMP easily, and Trampoline nodes in the route can aggregate an incoming multi-part payment and decide how to split the outgoing aggregated payment. This allows each intermediate Trampoline node to make more informed decisions than the sender on how to efficiently split payments. Additionally, Trampoline allows for better rendezvous routing than normal payments. One of the issues with rendezvous routing is that once the recipient has created their part of the onion, they need to communicate that to the sender. If a Bolt 11 invoice is used for this purpose, it adds an additional 1366 bytes per partial payment. Bitcoin Trampoline fixes this by doing the pre-encryption on a Trampoline onion, which is much smaller at 466 bytes, allowing rendezvous routing to benefit from Trampoline's ability to do multi-part at each hop. Trampoline itself has trade-offs that may impact privacy, particularly when paying to legacy nodes that don't understand the Trampoline onion. Eclair is currently implementing Trampoline to identify all the places where it falls short, so that the community can converge on a spec that minimizes trade-offs.
Updated on: 2023-06-02T21:00:49.242061+00:00