From subhra.mazumdar1993 at gmail.com Wed Apr 1 15:42:18 2020 From: subhra.mazumdar1993 at gmail.com (Subhra Mazumdar) Date: Wed, 1 Apr 2020 21:12:18 +0530 Subject: [Lightning-dev] Blind paths revisited In-Reply-To: References: <87k13txds8.fsf@rustcorp.com.au> <87a74nyfmy.fsf@rustcorp.com.au> Message-ID: Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the same kind of issue. The secrets we establish with anonymous multi-hops locks are between the *sender* and each of the hops. In the route blinding case, what we're adding are secrets between the *recipient* and the hops, and we don't want the sender to be able to influence those." Is it a good idea to rely entirely on the sender for sampling the secrets as well as generating the PTLC? As happens in anonymous multi-hops locks, for example. Or as it has been discussed later in the thread, both receiver and sender must be involved in creation of PTLC? What happens if sender/receiver is/(or both are) corrupted? Can it leak secrets to other parties? On Wed, Mar 11, 2020 at 9:57 PM Bastien TEINTURIER via Lightning-dev < lightning-dev at lists.linuxfoundation.org> wrote: > Good morning list, > > Thanks Rusty for following up on this, I'm glad it may be useful for > offers! > I certainly want this as well for wallet users' privacy. > > I have gathered my proposal in a better format than my previous gist here: > > https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md > > You will note that I've been able to simplify the scheme a bit compared to > my > gist. It's now very clear that this is exactly the same kind of secrets > derivation than what Sphinx does. I still have things I want to add to the > proposal, but at least the crypto part should be ready to review (and I > think > it does need more eyes on it). > > Feel free to add comments directly on the branch commits, it may be easier > to > review that way. Let me know if you think I should turn it into a draft PR > to > facilitate discussions. It kept it vague on some specific parts on purpose > (such as invoice fields, encrypted blob format); we will learn from early > prototype implementations and enrich the proposal as we go. > > A few comments on your previous mails. I have removed the (ab)use of > `payment_secret`, but I think your comment on using the `blinding` to > replace > it would not work because that blinding is known by the next-to-last node > (which computes it and forwards it to the final node). > The goal of `payment_secret` is explicitly to avoid having the > next-to-last node > discover it to prevent him from probing. But I think that you didn't plan > on > doing the blinding the same way I'm doing it, which may explain the > difference. > > As for ZmnSCPxj's suggestion, I think there is the same kind of issue. > The secrets we establish with anonymous multi-hops locks are between the > *sender* > and each of the hops. In the route blinding case, what we're adding are > secrets > between the *recipient* and the hops, and we don't want the sender to be > able to > influence those. It's a kind of reverse Sphinx. So I'm not sure yet the > recipient > could safely contribute to those secrets, but maybe we'll find a nice > trick in > the future! > > Cheers, > Bastien > > Le mer. 11 mars 2020 ? 00:22, Rusty Russell a > ?crit : > >> ZmnSCPxj writes: >> > Good morning Rusty, et al., >> > >> > >> >> Note that this means no payment secret is necessary, since the incoming >> >> `blinding` serves the same purpose. If we wanted to, we could (ab)use >> >> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's >> >> the ECDH for Carol to decrypt enc1). >> > >> > I confess to not reading everything in detail, but it seems to me that, >> with payment point + scalar and path decorrelation, we need to establish a >> secret with each hop anyway (the blinding scalar for path decorrelation), >> so if you need a secret per hop, possibly this could be reused as well? >> >> Indeed, this could be used the same way, though for that secret it can >> simply be placed inside the onion rather than passed alongside. >> >> Cheers, >> Rusty. >> _______________________________________________ >> 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 > -- Yours sincerely, Subhra Mazumdar. -------------- next part -------------- An HTML attachment was scrubbed... URL: