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 _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
