BIP70: PaymentACK semantics



Summary:

In an email thread, Jeremy Spilman suggested separating two issues: getting refund/memo fields to the merchant/payee and how transactions are broadcasted, retried, locked, and double-spent. He believed that issue #1 could be solved without fully specifying behavior for issue #2, and he focused on ensuring that merchants cannot act maliciously. Chuck proposed a solution in which customers send unsigned transactions as well as fully signed transaction hashes in a PaymentApprovalRequest message that is signed with the private key of the refund address. The customer keeps the fully signed transactions private until the merchant acknowledges the unsigned versions, and the merchant monitors the network for delivery of the signed transaction using the hash. However, Chuck's proposal was not clear, and he clarified that the customer includes the UNsigned transactions and only the hashes of the fully signed transactions.


Updated on: 2023-06-08T00:52:10.496658+00:00