The payment proofs RFC at

states payment proofs for invoices as an Unresolved question.

In the invoice transaction building flow we have

- receiver sends her public nonce and excess
- sender sends back his public nonce and excess, and other stuff including a partial kernel signature
- receiver computes their partial kernel signature and finalizes

The payment proof is a signed statement that the receiver accepts the on-chain confirmation of a specific kernel as proof of payment of a specific amount by a specific sender.

The receiver doesnâ€™t know the kernel yet in step 1, as the kernel excess depends on the sender excess sent in step 2. So for the sender to withhold payment until they have a payment proof would require two extra rounds, if we want the receiver to finalize (for which there are good reasons):

- receiver sends her public nonce and excess
- sender sends back his public nonce and excess
- receiver sends payment proof
- sender sends other stuff including a a partial kernel signature
- receiver computes their partial kernel signature and finalizes

This is obviously undesirable. So the question is if we can come up with a payment proof that can be sent in round 1, depending only on the receiver nonce R_r and excess X_r.

Recall that in step 3, the receiver produces a partial signature (s_r, R_r) that satisfies

s_r * G = R_r + e * X_r

where e is the hash challenge H((R | X | â€¦) .

What if the receiver accepts, as proof of payment of a specific amount by a specific sender, any pair (s_r, i) where i is the index of an on-chain kernel whose hash challenge e satisfies the above equation?

No one should be able to present this information unless the receiver made her partial signature, and the resulting transaction hit the chain.