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 <zmnsc...@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
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to