BIP70 (Payment Protocol)

BIP70 (Payment Protocol) was an ambitious payment protocol designed to make Bitcoin payments to merchants safer and more informative than pasting a raw address. Instead of paying to an opaque address string, a customer's wallet would fetch a signed PaymentRequest from the merchant, exchange Payment and PaymentACK messages, and receive a cryptographic receipt. It is now abandoned, and understanding it matters mainly so you recognize why it is no longer used — and what its failure teaches about trusted third parties.

What it tried to solve

The core problem was real. A bare Bitcoin address gives the payer no assurance about who they are paying: malware that swaps an address on the clipboard, or an attacker who tampers with a checkout page, redirects funds invisibly. BIP70's answer was to use X.509 TLS certificates — the same certificate-authority system that secures HTTPS — to bind a payment request to a verifiable identity, so a wallet could display "example.com" rather than a meaningless string. It also aimed to provide proof of payment for disputes and let merchants supply refund addresses automatically. The messages were encoded with Google Protocol Buffers and delivered over HTTP/HTTPS.

Why it was abandoned

In practice the design proved heavy and fragile. Reliance on the centralized X.509 certificate-authority system reintroduced exactly the kind of trusted third party Bitcoin exists to avoid: whoever the CAs would certify became "verified," and whoever they wouldn't, didn't. The protocol's complexity — certificate parsing, protobuf handling, network fetches inside the wallet — expanded the attack surface, and several wallets shipped implementation flaws in their BIP70 handling. Merchant processors that mandated BIP70 for a time drew sustained criticism from wallet developers who refused to carry the machinery. Bitcoin Core added deprecation warnings in v0.18, disabled the protocol by default in v0.19 (2019), and later removed support entirely (PR #17165). Modern guidance directs everyone to simpler, trust-minimized alternatives.

What replaced it

The practical replacement for everyday payments is the lightweight BIP21 Bitcoin URI scheme, which encodes an address, amount, and label in a plain URI (and today commonly a Lightning invoice alongside, in the "unified QR" pattern) without any certificate machinery. The address-verification problem BIP70 chased is now handled differently: confirm the receive address on the trusted display of a hardware wallet, and for interactive payments the Lightning Network provides signed invoices natively, with the recipient's node key doing the authentication instead of a certificate authority.

The lesson for sovereign users

BIP70 is a case study in how not to fix a trust problem: it solved "don't trust the address" by adding "trust the certificate authorities," swapping a visible risk for an institutional one. The approaches that survived — verify on hardware you control, authenticate with keys rather than certificates, keep the payment layer simple enough to audit — all follow the verify, don't trust principle instead. We note BIP70 here for historical accuracy; if you encounter a service still offering it, treat that as a sign of unmaintained software. Sovereign users should not deploy it, and no maintained wallet asks them to.

There is also a working answer to BIP70's merchant-side goals that keeps the trust model honest: self-hosted payment processors such as BTCPay Server generate invoices signed by infrastructure the merchant runs, give the customer an exact amount and expiry, and produce records for disputes — all without a certificate authority or an intermediary holding funds. That is the pattern D-Central itself uses to accept Bitcoin in the shop: the payment request is authenticated by the merchant's own server, not by a third party's signature on their identity. BIP70's goals were sound; its trust architecture was the flaw.