📅 Original date posted:2020-03-11
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200311/959e4614/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 12:59:16
in reply to nevent1q…pnu7
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 12:59:16Event JSON
{
"id": "bf6583b0b1578dc6cb518a4b78aeb604e5780765ab6e2244752630382710c67c",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315556,
"kind": 1,
"tags": [
[
"e",
"bdf43e4bc08687232ed81714c7a2374ed959a034fef2fe272a2bb53b5a09849b",
"",
"root"
],
[
"e",
"0d6fe146017975447c15d4c8de267373aae976a39cc5d9bf398ddf33718767e5",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2020-03-11\n📝 Original message:\nGood morning list,\n\nThanks Rusty for following up on this, I'm glad it may be useful for offers!\nI certainly want this as well for wallet users' privacy.\n\nI have gathered my proposal in a better format than my previous gist here:\nhttps://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md\n\nYou will note that I've been able to simplify the scheme a bit compared to\nmy\ngist. It's now very clear that this is exactly the same kind of secrets\nderivation than what Sphinx does. I still have things I want to add to the\nproposal, but at least the crypto part should be ready to review (and I\nthink\nit does need more eyes on it).\n\nFeel free to add comments directly on the branch commits, it may be easier\nto\nreview that way. Let me know if you think I should turn it into a draft PR\nto\nfacilitate discussions. It kept it vague on some specific parts on purpose\n(such as invoice fields, encrypted blob format); we will learn from early\nprototype implementations and enrich the proposal as we go.\n\nA few comments on your previous mails. I have removed the (ab)use of\n`payment_secret`, but I think your comment on using the `blinding` to\nreplace\nit would not work because that blinding is known by the next-to-last node\n(which computes it and forwards it to the final node).\nThe goal of `payment_secret` is explicitly to avoid having the next-to-last\nnode\ndiscover it to prevent him from probing. But I think that you didn't plan on\ndoing the blinding the same way I'm doing it, which may explain the\ndifference.\n\nAs for ZmnSCPxj's suggestion, I think there is the same kind of issue.\nThe secrets we establish with anonymous multi-hops locks are between the\n*sender*\nand each of the hops. In the route blinding case, what we're adding are\nsecrets\nbetween the *recipient* and the hops, and we don't want the sender to be\nable to\ninfluence those. It's a kind of reverse Sphinx. So I'm not sure yet the\nrecipient\ncould safely contribute to those secrets, but maybe we'll find a nice trick\nin\nthe future!\n\nCheers,\nBastien\n\nLe mer. 11 mars 2020 à 00:22, Rusty Russell \u003crusty at rustcorp.com.au\u003e a\nécrit :\n\n\u003e ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e writes:\n\u003e \u003e Good morning Rusty, et al.,\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\u003e Note that this means no payment secret is necessary, since the incoming\n\u003e \u003e\u003e `blinding` serves the same purpose. If we wanted to, we could (ab)use\n\u003e \u003e\u003e payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's\n\u003e \u003e\u003e the ECDH for Carol to decrypt enc1).\n\u003e \u003e\n\u003e \u003e I confess to not reading everything in detail, but it seems to me that,\n\u003e with payment point + scalar and path decorrelation, we need to establish a\n\u003e secret with each hop anyway (the blinding scalar for path decorrelation),\n\u003e so if you need a secret per hop, possibly this could be reused as well?\n\u003e\n\u003e Indeed, this could be used the same way, though for that secret it can\n\u003e simply be placed inside the onion rather than passed alongside.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200311/959e4614/attachment.html\u003e",
"sig": "5995e63a0e0b88558e8d91d623d1575a04926e656439f418481f92dce19be07bbc88f8e6012dfadcc351ad81ca7d1ceaea66fbd7bd26cde2ab22a84751ba217a"
}