From bastien at acinq.fr Tue Nov 12 13:42:12 2019 From: bastien at acinq.fr (Bastien TEINTURIER) Date: Tue, 12 Nov 2019 14:42:12 +0100 Subject: [Lightning-dev] Rendez-vous on a Trampoline In-Reply-To: References: Message-ID: Hi Antoine, 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. > I'm not sure I understand this correctly. The goal of trampoline is to do multi-trampoline hops right from the beginning (when we include it in the spec). In that case I believe we can make sure we offer the same privacy as we have today. That's said, current trampoline proposal which enables legacy payee doxing > without > any opt-in from its side is a bit gross. > I totally agree and I think that's something that we will fix once we start brainstorming for spec inclusion, with more eyes on the proposal. Overall I agree with your concerns and this is why we want more feedback on the proposal. We think that providing a first implementation is a good step towards getting people onboard and improving it. I also think that we're over-estimating the privacy currently offered by the network (against powerful adversaries). You mention doing MPP path intersection to expose senders, but while the network has low usage, people can be de-anonymized much more easily with simple statistical analysis (via cltv and amounts). But I'm confident that privacy features can be added incrementally, such as the random_scid work and rendezvous. Cheers, Bastien Le lun. 28 oct. 2019 ? 03:02, Antoine Riard a ?crit : > 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 >> > _______________________________________________ > 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: