[Lightning-dev] An Argument For Single-Asset Lightning Network

ZmnSCPxj ZmnSCPxj at protonmail.com
Mon Jan 7 12:11:14 UTC 2019


Good morning all,

> 6.  In addition, F adds to the OM onion hop packet the below information:
>     1.  `payment_point`
>     2.  `exchange_rate_point`
>     3.  The point sum of `(om_to_s_scalar + s_to_om_scalar) * G`
>     4.  A signature using the point `(om_to_s_scalar + s_to_om_scalar) * G` of the serialization of the `payment_point` and `exchange_rate_point`.
> 7.  The OM verifies:
>     1.  That `exchange_rate_point` is a point corresponding to some exchange rate quotation it issued before.
>     2.  That the exchange rate is still economically viable for it.
>     3.  That the sum of the `payment_point`, `exchange_rate_point`, and `(om_to_s_scalar + s_to_om_scalar) * G` correspond to the point that OM will need to learn the scalar of.

Of course, this is susceptible to a key cancellation attack; `payment_point` may be `secret * G - exchange_rate_point`, which removes the exchange from controlling when the payment completes.

A simple, naive mitigation would be for invoices to include a signature using the `payment_point` of an empty string.
Then this signature also needs to be provided to OM in order to assure it that `payment_point` does not cancel its point.

This is a simple proof-by-example that you should not trust your money to cryptosystems created by random people on the Internet.

Regards,
ZmnSCPxj



More information about the Lightning-dev mailing list