š
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
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 12:53:47
in reply to nevent1qā¦g9dc
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:53:47Event JSON
{
"id": "3c82c3e7c53fb739bbebc79e68a2c6be6291cd68ee9539f9b61b46ebbed4c196",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315227,
"kind": 1,
"tags": [
[
"e",
"ca4ba408a7f58042d7f13af4ffdac9ce35c46314a12c4b25cf60835498578c43",
"",
"root"
],
[
"e",
"f5832bdca25342d327db09b5de03d38fb697e839a713bcd97a639c7888732419",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2019-01-07\nš Original message:\nGood morning all,\n\n\u003e 6. In addition, F adds to the OM onion hop packet the below information:\n\u003e 1. `payment_point`\n\u003e 2. `exchange_rate_point`\n\u003e 3. The point sum of `(om_to_s_scalar + s_to_om_scalar) * G`\n\u003e 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`.\n\u003e 7. The OM verifies:\n\u003e 1. That `exchange_rate_point` is a point corresponding to some exchange rate quotation it issued before.\n\u003e 2. That the exchange rate is still economically viable for it.\n\u003e 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.\n\nOf 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.\n\nA simple, naive mitigation would be for invoices to include a signature using the `payment_point` of an empty string.\nThen this signature also needs to be provided to OM in order to assure it that `payment_point` does not cancel its point.\n\nThis is a simple proof-by-example that you should not trust your money to cryptosystems created by random people on the Internet.\n\nRegards,\nZmnSCPxj",
"sig": "9807c672cd39dbc14aacc92288c12f1f309b42e191dfd4ce11b3f6c04d320f2d1640998e17b65fa66fc47ea6ddb85a831cefc3991a7079751ce2872821683a4c"
}