From corne at bitonic.nl Fri Oct 25 07:14:22 2019 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Fri, 25 Oct 2019 09:14:22 +0200 Subject: [Lightning-dev] Rendez-vous on a Trampoline In-Reply-To: References: Message-ID: 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 > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev