BIP 70 Payment Protocol explained: understand PaymentRequest, Payment and PaymentACK messages, X.509 identity, refunds and legacy security risks.
This guide explains BIP 70 Payment Protocol in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 70 Payment Protocol: The BIP set size recommendations for request, payment and acknowledgement messages. Protocol Buffer parsers, certificate libraries and HTTP clients expanded the wallet attack surface.
A node operator is checking BIP 70 Payment Protocol. Wallets had to reject unsupported networks, expired requests and oversized messages before asking for authorisation. A merchant returned a PaymentRequest, the wallet validated and displayed it, the customer authorised payment, and the wallet optionally posted a Payment to the payment URL.
A merchant returned a PaymentRequest, the wallet validated and displayed it, the customer authorised payment, and the wallet optionally posted a Payment to the payment URL. The merchant answered with PaymentACK. Broadcast and merchant acknowledgement were related but separate; a failed HTTP response did not necessarily mean the Bitcoin transaction was absent.
PaymentDetails named the network, one or more amount-and-script outputs, creation time, optional expiry, memo, payment URL and opaque merchant data. A wrapper added version, PKI type, certificate data and signature. Wallets had to reject unsupported networks, expired requests and oversized messages before asking for authorisation.
The optional PKI mode signed the serialised request with a key certified through the web public-key infrastructure. Successful validation associated the request with a certificate identity, not with the truth of every commercial claim. Certificate expiry, revocation, compromised authorities, hostname interpretation and legacy SHA-1 support all affected assurance.
Payment carried the satisfying transaction or transactions, merchant data, a memo and refund_to outputs. Refund destinations supplied by a compromised client or altered connection could divert later refunds. A merchant needed to authenticate order state and use a current, independently confirmed refund process rather than treating old refund outputs as timeless authority.
PaymentACK echoed the Payment and could include a status memo. Servers were expected to acknowledge repeated identical Payment messages so a transport failure could be retried. Idempotency is essential: a retry must not create a second order, refund or accounting event merely because the client did not receive the first acknowledgement.
The BIP set size recommendations for request, payment and acknowledgement messages. Protocol Buffer parsers, certificate libraries and HTTP clients expanded the wallet attack surface. Redirects, MIME handling and payment URLs required strict controls. A checkout should not revive unmaintained parsing code simply to support a historical merchant flow.
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
BIP 70 Payment Protocol: The BIP set size recommendations for request, payment and acknowledgement messages.
A merchant returned a PaymentRequest, the wallet validated and displayed it, the customer authorised payment, and the wallet optionally posted a Payment to the payment URL.
PaymentDetails named the network, one or more amount-and-script outputs, creation time, optional expiry, memo, payment URL and opaque merchant data.
The optional PKI mode signed the serialised request with a key certified through the web public-key infrastructure.
BIP 70 offered authenticated requests and immediate acknowledgements, but its PKI, parser and refund model brought lasting operational risk. Existing records may require careful legacy interpretation; new payment systems should use maintained protocols with narrower trust boundaries.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 128 guide to Draft timelock-recovery plan storage, presigned transaction pairs, relative delay, checksums, monitoring, cancellation and reorg safety.
BIP 433 guide to Draft keyless Pay to Anchor outputs, CPFP fee bumping, standardness, ephemeral dust, TRUC anti-pinning and wallet safety.
What is BIP-110? Learn what Bitcoin’s reduced-data soft-fork proposal restricted, why it was controversial and why it later closed.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.