Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-01 📝 Original message: Commenting on it : "As ...
📅 Original date posted:2020-04-01
📝 Original message:
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 <rusty at rustcorp.com.au> a
> écrit :
>
>> ZmnSCPxj <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200401/1e7b9725/attachment.html>;
📝 Original message:
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 <rusty at rustcorp.com.au> a
> écrit :
>
>> ZmnSCPxj <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200401/1e7b9725/attachment.html>;