It has been suggested that a proof-of-payment can be achieved by the sender signing a different message with the same spend key and signing algo.
The idea is to re-do the RingCT Signature but this time signing the Payment instead of the ReissueTransaction.
Given sender's signature over a Payment, we can verify that sender created the Dbc(s) contained in the payment by checking that the key-images are identical.
This is because the second ringct signature would only be possible if the signer knows the secret key that corresponds to that key-image.
Some related observations:
This technique enables Alice to prove she paid Bob without revealing the amount she paid.
This technique enables proof-of-payment to multiple recipients, not just one.
This approach does not require that the recipient(s) are online. (unlike the Invoice approach)
With this functionality in place, it seems that the only additional thing that the Invoice/PaidInvoice approach gives us is a mechanism to request a payment amount without revealing that amount to any 3rd parties. Maybe we don't even need it.
It has been suggested that a proof-of-payment can be achieved by the sender signing a different message with the same spend key and signing algo.
The idea is to re-do the RingCT Signature but this time signing the
Paymentinstead of theReissueTransaction.Given sender's signature over a
Payment, we can verify that sender created the Dbc(s) contained in the payment by checking that the key-images are identical.This is because the second ringct signature would only be possible if the signer knows the secret key that corresponds to that key-image.
Some related observations: