协议演进 / BIP/比特币改进提案 / BIP-72
BIP-72
给 BIP-21 的 bitcoin: URI 增加可选的 r 参数，指向应去抓取的 PaymentRequest，让点击链接即可启动 BIP-70 支付协议且不破坏旧钱包兼容。本 BIP 目前处于已部署状态。
一、档案卡
| 编号 | BIP-72 |
|---|---|
| 标题 | bitcoin: uri extensions for Payment Protocol |
| 作者 | Gavin Andresen <[email protected]> |
| 指定日期 | 2013-07-29 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Deployed（已部署） |
| 阅读版 | https://bips.dev/72 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki |
二、放在哪一族
BIP-72 是支付协议族的入口件，与 BIP-70、BIP-71 同日指定。它站在两套东西之间：一头是 BIP-21 早已通行的 bitcoin: URI（链接里带地址、金额、标签），一头是 BIP-70 的支付协议（要先抓取一份签名的 PaymentRequest 才开始）。
本篇做的事，就是在 URI 上开一扇门：多带一个参数，支持新协议的钱包由此转入 BIP-70 流程；不支持的旧钱包照常按地址付款。发起抓取时用的 Accept 头（application/bitcoin-paymentrequest）则由 BIP-71 定义。
三、它要解决什么
BIP-70 的流程从“顾客表明准备付款、商户服务器回一份 PaymentRequest”开始，但顾客最初是怎么接触到商户的付款入口的，原协议没有规定。
原文的动机是：让用户能点击网页或电子邮件里的链接来启动支付协议，同时与既有的比特币钱包向后兼容。链接是最自然的入口——用户本来就习惯点 bitcoin: 链接唤起钱包；问题只是怎样让同一个链接对新旧钱包分别做对的事。
四、规则本身
4.1 r 参数
bitcoin: URI 方案新增一个可选的参数 r，其值是一个 URL，钱包应从该 URL 抓取一份 PaymentRequest 消息。URL 中不允许出现在查询参数范围内的字符，必须按 RFC 3986 与 BIP-21 做百分号编码。
若提供了 r 参数、且不要求向后兼容，URI 的比特币地址部分可以省略，形式变为：
bitcoin:?r=...
4.2 支持本篇的钱包怎么做
收到带 r 参数的 bitcoin: URI 时，钱包应忽略 URI 里的地址、金额、标签与消息字段，转而抓取 PaymentRequest，并按 BIP-70 的支付协议继续走。
- 钱包必须支持经 http 与 https 抓取 PaymentRequest，可以支持其他协议；
- 经 HTTP(S) 抓取时，请求必须带 Accept 头（按 RFC 2616 定义），其值即 BIP-71 定义的类型：
Accept: application/bitcoin-paymentrequest
- 若 PaymentRequest 抓不到（例如服务器不可用），应告知顾客：商户的支付处理系统不可用；
- HTTP 回覆里既非成功也非错误的状态码（如重定向），按 RFC 2616 的规定处理。
4.3 向后兼容与示例
不支持本篇的钱包会直接忽略 r 参数，照常向 URI 中的比特币地址发起付款。这决定了两种写法的用途分工：需要兼容旧钱包时，把地址与金额照常写进 URI、再附加 r——旧钱包按地址付，新钱包走协议；不需要兼容时，才用省去地址的纯 r 形式。
向后兼容的请求：
bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
不等兼容的等价形式：
bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
五、谁必须动
普通持币人：操作不变，仍是点链接、钱包打开、确认付款。区别只在钱包背后：支持本篇的钱包会按抓回的 PaymentRequest（经证书认证的商户身份与输出）走完 BIP-70 流程，而不是照链接字面付款。
钱包开发者：需解析 r 参数：带 r 时忽略 URI 内的地址等字段、按 4.2 抓取并走支付协议，抓取失败要明确告知用户系统不可用，而不是悄悄退回按地址付款。
商户与支付服务器：在网页与邮件里发布带 r 的链接，并保证该 URL 能回出 PaymentRequest；是否同时保留地址与金额，取决于是否需要兼容旧钱包。
全节点与矿工、共识层：完全不必动。本篇只改钱包打开链接时的行为，最终交易与此前无异。
六、现在算不算数，以及一个常见误读
状态为 Deployed（已部署）。它是支付协议族三件套的最后一块：链接负责引路（本篇），消息标签负责封装（BIP-71），消息与流程本身由 BIP-70 定义。
常见误读：
“链接里写了地址和金额，支持 BIP-72 的钱包就会照这个地址和金额付款。”
不对。恰恰相反：对支持本篇的钱包，URI 里的地址、金额、标签、消息都应被忽略，最终付款条款以抓回的 PaymentRequest 为准。地址与金额留在链接里，只是给不支持本篇的旧钱包用的兼容退路。
七、延伸
- 阅读版：https://bips.dev/72
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki
- 相关：BIP-70 支付协议、BIP-71 支付协议 MIME 类型、BIP-21 bitcoin: URI
- 仓库总目录：https://github.com/bitcoin/bips