From antoine.riard at gmail.com Mon Oct 28 02:01:31 2019 From: antoine.riard at gmail.com (Antoine Riard) Date: Sun, 27 Oct 2019 22:01:31 -0400 Subject: [Lightning-dev] Rendez-vous on a Trampoline In-Reply-To: References: Message-ID: Hi, Design reason of trampoline routing was to avoid lite nodes having to store the whole network graph and compute long-hop route. Trick lays in getting away from source-base routing, which has the nice property to hide hop position along the payment route (if we forget payment hash correleation), by enabling a mechanism for route computation delegation. This delegation trades hardware requirements against privacy leaks and higher fees. And we also have now to re-design privacy mechanism to constitue an anonymous network on top of the network one. Rendez-vous is one of them, multipe-trampoline hops another one. We may want also to be inspired by I2P and its concept of outbound/inbound tunnels, like payer concatenating a second trampoline onion to the rendez-vous onion acquired from the payee. Trick are known but hard and complex to get right in practice. That's said, current trampoline proposal which enables legacy payee doxing without any opt-in from its side is a bit gross. Yes rendez-vous routing by receiver solves it (beyond being cool in itself)! but stucks on the same requirement to update payee nodes. If so, implementing trampoline routing on receiver could be easier and let it hide behind the feature flag. If Eclair go forward with trampoline, are you going to enforce that trampoline routing is only done with payee flagging support ? That's a slowdown but if not people are going to be upset learning that a chunk of their incoming payment is potentially logged by some intermediate node. Also, I'm a bit worried too on how AMP is going to interact with trampoline routing. Depend on topology, but a naive implementation only using public channels and one-hop trampoline node would let the trampoline learn who is the payer by doing intersection of the multiple payment paths. Long-term we may be pleased to have this flexible tools to enable wide-scale networking without assessing huge routing tables for everyone but I think we should be really careful on how we design and deploy this stuff to avoid another false promise of privacy like we have known on the base layer, e.g bloom-filters. Antoine Le ven. 25 oct. 2019 ? 03:20, Corn? Plooy via Lightning-dev < lightning-dev at lists.linuxfoundation.org> a ?crit : > 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 > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: