📅 Original date posted:2020-03-13
📝 Original message:
Good morning ZmnSCPxj,
Ok I see what you mean. In that case it would be slightly different from
the current path blinding proposal.
The recipient would need to give the sender all the blinding points for
each hop in the blinded path.
Currently the recipient only gives one blinding point and then each node in
the blinded path is able to
compute the next blinding point and send it to the next node.
This may work, but I think it deserves a closer look. The security
assumptions in multi-hop locks is that
the sender can choose every secret from a random distribution. If instead
these secrets are provided by
the recipient, this may open up some attack vectors on the sender. Maybe
the sender can tweak each
recipient secret with a secret of its own, but one would need to write the
exact maths down to verify that
it works end-to-end.
I'm not saying it's impossible, I'm just saying that it's not trivial at
all and the devil is in the details ;)
Cheers,
Bastien
Le ven. 13 mars 2020 à 01:42, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning tbast, rusty, and list,
>
>
> > 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!
>
> Not quite?
>
> The recipient knows the secrets from the first recipient-selected-hop to
> itself, and, if it knows the payment scalar, can subtract those secrets
> from the receiver scalar.
> Thus the sender only has to arrange to deliver the payment point to the
> first recipient-selected-hop, the rest of the recipient-selected-hops will
> add their blinding scalars (which come from the recipient), and the final
> recipient can linearly deduct those.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200313/4f7865b8/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 12:59:17
in reply to nevent1q…2zpl
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 12:59:17Event JSON
{
"id": "ca9cab6ad00b3fa5b411b9577811e64b9469e862d2b4240dc80774adb40f6dbf",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315557,
"kind": 1,
"tags": [
[
"e",
"bdf43e4bc08687232ed81714c7a2374ed959a034fef2fe272a2bb53b5a09849b",
"",
"root"
],
[
"e",
"41be51b07a8bad612194ecf12388a022c50c7b6821036c9ac000d06a902ceba3",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-03-13\n📝 Original message:\nGood morning ZmnSCPxj,\n\nOk I see what you mean. In that case it would be slightly different from\nthe current path blinding proposal.\nThe recipient would need to give the sender all the blinding points for\neach hop in the blinded path.\nCurrently the recipient only gives one blinding point and then each node in\nthe blinded path is able to\ncompute the next blinding point and send it to the next node.\n\nThis may work, but I think it deserves a closer look. The security\nassumptions in multi-hop locks is that\nthe sender can choose every secret from a random distribution. If instead\nthese secrets are provided by\nthe recipient, this may open up some attack vectors on the sender. Maybe\nthe sender can tweak each\nrecipient secret with a secret of its own, but one would need to write the\nexact maths down to verify that\nit works end-to-end.\n\nI'm not saying it's impossible, I'm just saying that it's not trivial at\nall and the devil is in the details ;)\n\nCheers,\nBastien\n\nLe ven. 13 mars 2020 à 01:42, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning tbast, rusty, and list,\n\u003e\n\u003e\n\u003e \u003e As for ZmnSCPxj's suggestion, I think there is the same kind of issue.\n\u003e \u003e The secrets we establish with anonymous multi-hops locks are between the\n\u003e *sender*\n\u003e \u003e and each of the hops. In the route blinding case, what we're adding are\n\u003e secrets\n\u003e \u003e between the *recipient* and the hops, and we don't want the sender to be\n\u003e able to\n\u003e \u003e influence those. It's a kind of reverse Sphinx. So I'm not sure yet the\n\u003e recipient\n\u003e \u003e could safely contribute to those secrets, but maybe we'll find a nice\n\u003e trick in\n\u003e \u003e the future!\n\u003e\n\u003e Not quite?\n\u003e\n\u003e The recipient knows the secrets from the first recipient-selected-hop to\n\u003e itself, and, if it knows the payment scalar, can subtract those secrets\n\u003e from the receiver scalar.\n\u003e Thus the sender only has to arrange to deliver the payment point to the\n\u003e first recipient-selected-hop, the rest of the recipient-selected-hops will\n\u003e add their blinding scalars (which come from the recipient), and the final\n\u003e recipient can linearly deduct those.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200313/4f7865b8/attachment.html\u003e",
"sig": "5eef443f5c818d61cdc3c77f373bb69d13179957da0fb16adcae1dfaecc26fbf01ec8d4dc79dc898be672ee2ebf325c52e6134c3b5f51b99bee6910e65e0fafa"
}