Cool: non-source rendez-vous routing. Getting closer to 2013 Amiko Pay, with the added experience of 2019 Lightning with Sphinx routing and AMP.
https://cornwarecjp.github.io/amiko-pay/doc/amiko_draft_2.pdf (esp. section 2.1.3) Please forgive the use of the term "Ripple". 2013 was a different time. CJP On 22-10-19 14:01, Bastien TEINTURIER wrote: > Good morning everyone, > > Since I'm a one-trick pony, I'd like to talk to you about...guess > what? Trampoline! > If you watched my talk at LNConf2019, I mentioned at the end that > Trampoline enables high AMP very easily. > Every Trampoline node in the route may aggregate an incoming > multi-part payment and then decide on how > to split the outgoing aggregated payment. It looks like this: > > .-------- 1mBTC --------. .------- 2mBTC -------. > / \ / > \ > Alice ----- 3mBTC ------> Ted ------ 4mBTC ----> Terry ----- 6mBTC > ----> Bob > \ / > `------- 2mBTC ----------' > > In this example, Alice only has small-ish channels to Ted so she has > to split in 3 parts. Ted has good outgoing > capacity to Terry so he's able to split in only two parts. And Terry > has a big channel to Bob so he doesn't need > to split at all. > This is interesting because each intermediate Trampoline node has > knowledge of his local channels balances, > thus can make more informed decisions than Alice on how to efficiently > split to reach the next node. > > But it doesn't stop there. Trampoline also enables a better > rendez-vous routing than normal payments. > Christian has done most of the hard work to figure out how we could do > rendez-vous on top of Sphinx [1] > (thanks Christian!), so I won't detail that here (but I do plan on > submitting a detailed spec proposal with all > the crypto equations and nice diagrams someday, unless Christian does > it first). > > One of the issues with rendez-vous routing is that once Alice (the > recipient) has created her part of the onion, > she needs to communicate that to Bob (the sender). If we use a Bolt 11 > invoice for that, it means we need to > put 1366 additional bytes to the invoice (plus some additional > information for the ephemeral key switch). > If the amount Alice wants to receive is big and may require > multi-part, Alice has to decide upfront on how to split > and provide multiple pre-encrypted onions (so we need 1366 bytes /per > partial payment/, which kinda sucks). > > But guess what? Bitcoin Trampoline fixes that*™*. Instead of doing the > pre-encryption on a normal onion, Alice > would do the pre-encryption on a Trampoline onion (which is much > smaller, in my prototype it's 466 bytes). > And that allows rendez-vous routing to benefit from > Trampoline's ability to do multi-part at each hop. > Obviously since the onion is smaller, that limits the number of > trampoline hops that can be used, but don't > forget that there are additional "normal" hops between each Trampoline > node (and the final Trampoline spec > can choose the size of the Trampoline onion to enable a good enough > rendez-vous). > > Here is what it would look like. Alice chooses to rendez-vous at > Terry. Alice wants the payment to go through Terry > and Teddy so she pre-encrypts a Trampoline onion with that route: > > Alice <--- Teddy <--- Terry > > She creates a Bolt 11 invoice containing that pre-encrypted onion. Bob > picks up that invoice and can either reach > Terry directly (via a normal payment route) or via another Trampoline > node (Toad?). Bob finalizes the encryption of > the Trampoline onion and sends it onward. Bob can use multi-part and > split the payment however he wishes, > because every Trampoline node in the route will be free to aggregate > and re-split differently. > Terry is the only intermediate node to know that rendez-vous routing > was used. Terry doesn't learn anything about > Alice because the payment still needs to go through Teddy. Teddy only > learns that this is a Trampoline payment, so > he doesn't know his position in the Trampoline route (especially since > he doesn't know that rendez-vous was used). > > I believe this makes rendez-vous routing reasonable to implement: the > trade-offs aren't as strong as in the normal > payment case. If I missed something (maybe other issues related to the > current rendez-vous proposal) please let me know. > > Of course Trampoline itself also has trade-offs that in some cases may > impact privacy (e.g. when paying to legacy nodes > that don't understand the Trampoline onion). This is why Eclair is > currently implementing it to identify all the places where > it falls short, so that we can then leverage the community's amazing > brain power to converge on a spec that everyone is > happy with and that minimizes the trade-offs we need to make. Stay > tuned for more information and updates to the spec PR > once we make progress on our Trampoline experiments. > > Thank you for reading this, don't hesitate to throw ideas and/or > criticize this proposal. > Note that all the cryptographic details are left as an exercise to the > reader. > > Bastien > > [1] > https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx > > > _______________________________________________ > Lightning-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
