BIP 120 Proof of Payment Explained: Design, Security and Closure

This guide explains BIP 120 Proof of Payment in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

What the proof claimed

The proof aimed to show control of all credentials used to unlock the inputs of transaction T. That can support access to a prepaid service or claim linked to a payment. It does not prove who made the payment, who owned the coins economically or whether a later refund or transfer changed entitlement.

Transaction-shaped structure

The object reused the original inputs in the same order, set sequence values to zero and included exactly one zero-value proof output carrying marker, version, nonce and transaction commitment data. Reusing transaction signing machinery reduced new cryptography but made strict structural validation essential.

Preventing blockchain inclusion

Lock time was set to 499,999,999 while zero sequences kept the lock effective, making accidental mining impractical under the intended rules. A wallet still had to keep the proof off the peer network and send it only to the requested service. Non-mineable did not mean non-sensitive.

Nonce challenge

A fresh random server nonce bound the proof to one request and limited reuse of a captured object. The server needed enough entropy, expiry, single-use storage and brute-force throttling. A stolen proof could still reveal transaction relationships and might succeed if challenge management was weak.

Validation steps

The server checked structure, nonce, transaction correspondence, input order and signatures against the outputs spent by the original transaction. That required trustworthy access to the transaction and UTXO history. A public explorer response alone was not equivalent to local consensus validation or complete archival data.

Malleability and wallet state

A wallet that remembered only its original outgoing TXID could fail when a malleated form confirmed. The BIP recommended observing the network’s confirmed transaction. Empty wallets could still produce valuable proofs, so deleting keys merely because value was spent could destroy access credentials.

Threat-model rehearsal

On regtest, create a qualifying payment, request two nonces and prove that a response works only once and only for its matching transaction. Mutate input order, output marker, lock time, signatures and destination. Measure what transaction and identity information the verifier learns and define retention limits.

Conclusion

BIP 120 explored payment-linked credentials but tied authentication to transaction keys, history and sensitive proof exchange. Because it is closed, modern services should use maintained authentication methods and interpret legacy proofs only in isolated tests.