z->t case, there’s a perfectly-satisfactory existing solution: the merchant generates a receiving t-address specifically for that interaction (as they would already be doing for any Bitcoin transaction), and then proof-of-payment is simply providing a transaction ID in the block chain. This doesn’t prove that it was a specific address that sent the payment, but that is irrelevant for a merchant (and unnecessarily privacy-leaking); all they need is to be able to definitively state whether or not they received a payment associated with a particular merchant-client interaction (i.e. “did this address receive the amount I expected?”) and for a user to be able to prove that such a payment exists (which is trivially inspectable on the block chain for
z->Sapling case, this workflow can be replicated with diversified addresses (merchant generates a new diversified address for every interaction, and once they reach
2^87 interactions they switch to a new key), or the merchant can require that the memo field contain a specific value (and then just ignore any payment without it). What is lacking is the ability for a user to simply point at a transaction in the chain and say “this was it!” - the merchant can still claim that the transaction was not to the address they specified, or with the required memo field contents. Refuting this requires the user to provide the merchant with the necessary information to decrypt a transaction, and this is built into the Sapling protocol: the user can derive
ock (the per-output recovery key) and provide the tuple
(transaction id, output index, ock) to the merchant. Anyone with this information can decrypt the specified output and verify that it indeed was sent to a specific Sapling address, with a specific amount and memo field content.
There is an even stronger property that one might want, which is where a user proves that they (or more precisely, anyone with access to their spending keys) were the one that made a specific transaction, rather than simply that the transaction exists (since once the above payment disclosure has been created, anyone can use it to show the existence of said interaction). I posit this is not required for normal merchant interactions: the merchant only cares that they are paid for their goods or services, and the user only cares that the merchant can see that a payment has been made. For situations where it is required, creating this stronger proof would I think require caching at least some of the randomness from the transaction generation process (in order to re-derive one of the re-randomized keys used for signatures in the transaction), which is not currently cached by any implementation.