ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-07 📝 Original message: Good morning all, > 6. In ...

📅 Original date posted:2019-01-07
📝 Original message:
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