[Lightning-dev] Blind paths revisited

ZmnSCPxj ZmnSCPxj at protonmail.com
Mon Mar 16 00:06:12 UTC 2020


Good morning Bastien,

> 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.


Not every secret is chosen by the sender --- the final target payment scalar comes from the receiver, after all, and if the payee can somehow attack the sender if multiple scalars are given, then the payee can also attack the sender if a single scalar is given, because linearity.
Whether the final receiver secret is a single scalar, or multiple scalars summed together, seems to be immaterial.

So for example if the payment point + scalar is (N, n), then as usual the sender creates blinding scalars s0 s1 s2 and creates an initial PTLC that requests for (s0 + s1 + s2) * G + N, each hop the sender select subtracts some s[i], then the rendezvous point receives just N.
Then the rendezvous unwraps the receiver-side onion, which reveals a path with blinding scalars r0 r1 r2, each subsequent receiver-selected path subtracts some r[i] until the receiver receives a PTLC asking for the scalar behind N - (r0 + r1 + r2) * G.
Since the receiver knows n such that N = n * G, and knows all the r[i], it can claim that PTLC.

Thus the sender can treat the rendezvous point as the "real" receiver, with an abnormally high `final_cltv_expiry`, and of course the receiver is now the one paying for the fees deducted by each hop the receiver chose (i.e. the sender is obligated to deliver the agreed funds only up to the rendezvous node).
As far as the sender is concerned, the payment point + scalar is N = n * G, not N - (r0 + r1 + r2) * G = n - r0 - r1 - r2.

Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list