BIP for Proof of Payment

Summary:

This document proposes a BIP for "Proof of Payment" (PoP), which is a way for a wallet to prove to a server that it has the ability to sign a certain transaction. The PoP system has several use cases such as pre-paid hotel rooms, ad-signs, online video rental services, lottery, and parking lots. It also has desirable properties such as generating a PoP on demand, only usable once to avoid theft issues, ability to create a PoP for any payment, proving that you have enough credentials to unlock all inputs of the proven transaction, and easy implementation by wallets and servers to ease adoption.The current methods of proving a payment include BIP0070 and signing messages chosen by the server using private keys. However, they do not meet certain desirable properties such as 1,2,3, and 4. The proposed PoP has the same structure as a bitcoin transaction with an added OP_RETURN output inserted at index 0, known as the pop output. This output must have a specific format, including version, txid, and nonce.The Proof of Payment (PoP) system is signed using the same process as bitcoin transactions. Once the PoP has reached the server, a new nonce is generated for every PoP request, making the previous one useless. Since a PoP is indistinguishable from a bitcoin transaction, there is a risk that it might accidentally or maliciously enter the bitcoin p2p network. Therefore, the outputs of the PoP must match those in T, and the zero transaction fee in PoP(T) is used to minimize the incentives for miners to select PoP(T) for inclusion.The wallet identifies a transaction T if possible; otherwise, it asks the user to select among the ones that match the hints in 1.iii. The wallet creates an unsigned PoP (UPoP) for T and asks the user to sign it. The UPoP(T) is signed by the wallet, creating PoP(T), which is sent to the destination in 1.ii. The server receiving the PoP validates it and responds with “valid” or “invalid,” which is displayed to the user.The validation process includes checking the format of the PoP, confirming the PoP output at index 0 conforms to the OP_RETURN output format outlined above, ensuring that the rest of the outputs exactly correspond to the outputs of T, checking the nonce, verifying that the inputs of the PoP are the same as in transaction T, and checking the scripts of all the inputs as would be done on a normal transaction. The txid in the PoP output is also verified to be the transaction intended for proof.Security considerations include the possibility of someone intercepting the PoP-request and changing the PoP destination or txid. Wallets should not rely on the transaction id of the outgoing transaction, and transaction malleability may cause the server to have another transaction id than the wallet for payment. A reference implementation for the PoP system can be found on GitHub, along with a Mycelium fork. References to BIP0021 and BIP0070 are made in the context of the PoP system.

Updated on: 2023-05-19T20:31:46.342713+00:00