Solo Mining Calculator: Estimate Odds and Timeframes
Use a solo mining calculator correctly: enter productive hashrate, network conditions, uptime and time horizon, then read expected time and probability without.
Read article
ASIC mining knowledge centre
BIP 70 Bitcoin Payment Protocol Explained: Security and Legacy Risks
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.
TL;DR
- What it is: BIP 70 defined a merchant-to-wallet payment protocol using Protocol Buffers, HTTP or HTTPS and optional X.509 identity. PaymentRequest described outputs and expiry, Payment carried signed transactions and refund outputs, and PaymentACK confirmed receipt.
- Why it matters: 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.
- Current position: Where the feature is closed or legacy, isolate the parser and record that limitation before testing.
BIP 70 Payment Protocol in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Three-message sequence
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.
PaymentRequest contents
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.
Merchant identity and X.509
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 and refund outputs
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.
Acknowledgement and retry
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.
Resource and dependency risks
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.
How specialists test it
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.
Frequently asked questions
What is BIP 70 Bitcoin Payment Protocol?
BIP 70 defined a merchant-to-wallet payment protocol using Protocol Buffers, HTTP or HTTPS and optional X.509 identity. PaymentRequest described outputs and expiry, Payment carried signed transactions and refund outputs, and PaymentACK confirmed receipt.
Is BIP 70 Bitcoin Payment Protocol active or supported today?
Where the feature is closed or legacy, isolate the parser and record that limitation before testing.
Why does BIP 70 Bitcoin Payment Protocol matter?
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.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
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.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
On this page
Search More Guides
BIP-110 Explained: Rules, Signalling and Why It Closed
BIP-110 Explained made simple. See the main facts, costs, risks and practical checks before you make a decision.
Read article
Bitcoin Core 29.4 Release: Chainstate Disk I/O Guide
Bitcoin Core 29.4 guide covering repeated chainstate rewrites, regular compaction, LevelDB seek compaction, transaction-data lifetime and wallet sizing fixes.
Read article
Need Advice for Your Mining Setup?
Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.