协议演进 / BIP/比特币改进提案 / BIP-73
BIP-73
让扫码钱包用一个短的支付请求 URL、靠 HTTP Accept 头协商服务器返回 bitcoin URI 还是一份完整的 PaymentRequest，免得二维码塞满长串而扫不出来。本 BIP 目前处于已部署状态。
一、档案卡
| 编号 | BIP-73 |
|---|---|
| 标题 | Use "Accept" header for response type negotiation with Payment Request URLs |
| 作者 | Stephen Pair <[email protected]> |
| 指定日期 | 2013-08-27 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Deployed（已部署） |
| 阅读版 | https://bips.dev/73 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki |
二、放在哪一族
支付协议（Payment Protocol）族的一块小补丁，紧贴 BIP-70（Payment Protocol）、BIP-71（支付协议 MIME 类型）与 BIP-72（支付协议的 bitcoin: URI 扩展）。
BIP-70 让商户能给出带金额、收款脚本和退款信息的结构化 PaymentRequest；BIP-72 把下载 PaymentRequest 的地址塞进 bitcoin: URI 的参数里。问题是 URI 一长，二维码就密。BIP-73 不改 PaymentRequest 本身，只改“怎么用一个短 URL 把它取回来”：同一个端点，按客户端想要什么返回什么。
它也不要求实现方先完整支持 BIP-70——原文明确说，实现本 BIP 不以完整支持 PaymentRequest 为前提。
三、它要解决什么
3.1 长 URI 把二维码撑密了
支付协议在 bitcoin: URI 之外又加了一个参数，指向存放 PaymentRequest 的 URL。URI 本身已有地址、金额等信息，再叠加一个不短的请求 URL，渲染成二维码后信息密度很高。密度越高越难扫，用户体验越差——尤其在光线、屏幕或摄像头条件一般时。
3.2 通用扫码器扫到之后没用
普通二维码扫描 App 不懂 bitcoin: URI。若二维码里只是一个网页地址，它至少还能打开一个页面；若塞满支付参数，通用扫描器往往无能为力。本 BIP 想让同一个二维码对钱包、对浏览器、对通用扫描器都各有可用的回应。
目标因此很具体：让扫码钱包能用密度更低的二维码——码里只放支付请求 URL，细节留到取回时再协商。
四、规则本身
4.1 把非 bitcoin URI 当作取件端点
支持本 BIP 的扫码钱包，应把从二维码扫到的非 bitcoin URI 视为一个端点：向它发请求，可以取回一份 bitcoin URI，或一份 PaymentRequest，二选一由协商决定。
4.2 用 Accept 头表明想要什么
钱包客户端用 HTTP 的 Accept 头声明自己能接受什么：
text/uri-list：表示接受一份 bitcoin URI；application/bitcoin-paymentrequest：表示能处理 PaymentRequest。
服务器据此回应。原文不要求客户端与服务器完整实现 HTTP Accept 的全部语义，只定了一条优先级：
- 头里出现
application/bitcoin-paymentrequest，服务器就应发 PaymentRequest，不管头里还写了什么； - 只出现
text/uri-list（且没有前者），应返回一份有效的 Bitcoin URI； - 两者都没出现，服务器可以返回一份 HTML 页面。
没有 Accept 头时，服务器预期返回适合在浏览器里渲染的 text/html。这样通用扫描器扫到同一个码，也能打开一个带支付链接的网页，用户点链接唤起设备上的钱包继续付款。
4.3 uri-list 只取第一条
当服务器返回 uri-list 时，只用列表里的第一条，并预期它就是 bitcoin URI；其余 URI 一律忽略。这一条避免了多条链接时钱包不知该跟哪一条的歧义。
五、谁必须动
普通持币人：无感。不必改设置；扫码时钱包若支持本 BIP，二维码可以更疏、更好扫。
钱包开发者：扫码逻辑要改——扫到非 bitcoin URI 的 URL 时，不要直接报错，而要带 Accept 头去取内容：能处理 PaymentRequest 就声明 application/bitcoin-paymentrequest，只想要 URI 就声明 text/uri-list；拿到 uri-list 只取第一条。
商户与支付服务器：同一个支付请求 URL 要能按 Accept 头分流：给钱包发 PaymentRequest 或 URI，给浏览器和通用扫描器发 HTML 页。还应提供退路，例如让用户可切换成 bitcoin: URI 的二维码。
全节点与矿工：不涉及。不改共识、不改交易格式、不改网络转发规则。
六、现在算不算数，以及一个常见误读
状态为 Deployed（已部署）。它属于 BIP-70 支付协议时代的一组配套规范，价值在于把“短码 + 按需取件”写成了各家可互操作的约定。是否“算数”，只看仓库标注的 Deployed，不等于今天所有钱包与商户仍在用支付协议——原文没有给出采用统计，本页也不臆测。
常见误读：
“BIP-73 是 BIP-70 的替代，要先完整实现支付协议才能用它。”
不对。原文在摘要里就写明：实现本 BIP 不要求完整支持 PaymentRequest。它泛化的是支付请求 URL 的行为——用 Accept 头协商返回内容——一个只想要 bitcoin URI 的钱包也能从中受益。
七、延伸
- 阅读版：https://bips.dev/73
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki
- 相关：BIP-70 支付协议、BIP-71 MIME 类型、BIP-72 bitcoin: URI 扩展
- 仓库总目录：https://github.com/bitcoin/bips