协议演进 / BIP/比特币改进提案 / BIP-71

BIP-71 支付协议 MIME 类型

为支付协议的三种消息定义 MIME 媒体类型，使 PaymentRequest、Payment 与 PaymentACK 能按互联网标准经 HTTP 或邮件传递。本 BIP 目前处于已部署状态。

一、档案卡

二、放在哪一族

BIP-71 是支付协议族里最小的一份配套件，与 BIP-70、BIP-72 同日指定：BIP-70 定义消息本身，BIP-71 定义这些消息在互联网传输时的“信封标签”，BIP-72 定义如何用一个链接把顾客带进流程。

它被姊妹文档直接引用：BIP-70 规定发送 Payment 消息时必须按 BIP-71 设置 Content-Type 与 Accept 头；BIP-72 规定钱包抓取 PaymentRequest 时必须带 Accept: application/bitcoin-paymentrequest 头——那个类型名正是本篇定义的。

三、它要解决什么

BIP-70 的消息是二进制的 Protocol Buffers 数据，需要经 HTTP 或电子邮件在钱包与服务器之间传递。

原文的动机只有一句，但很实在：通过邮件或 HTTP 发送支付协议消息的钱包或服务器软件，应当遵循互联网标准，正确地封装这些消息。没有统一的媒体类型，接收方就只能靠猜——这团二进制字节到底是账单（PaymentRequest）、回执（Payment），还是确认（PaymentACK），三者的处理方式完全不同。

四、规则本身

4.1 三个媒体类型

比特币支付协议消息的媒体类型（即 HTML / 邮件头里的 Content-Type）定为：

消息	Type / Subtype
PaymentRequest	application/bitcoin-paymentrequest
Payment	application/bitcoin-payment
PaymentACK	application/bitcoin-paymentack

MIME 本身依 RFC 2046。本篇还明确：支付协议消息一律按二进制编码。

4.2 示例

一台生成 PaymentRequest 消息以启动支付协议的 Web 服务器，应在二进制消息数据之前加上这样的头：

Content-Type: application/bitcoin-paymentrequest
Content-Transfer-Encoding: binary

其余两条消息在实际流程中的用法由 BIP-70 给出：钱包发送 Payment 时设置 Content-Type: application/bitcoin-payment、Accept: application/bitcoin-paymentack；商户服务器据此识别消息种类并回以对应类型的确认。

五、谁必须动

普通持币人：无直接变化。媒体类型是软件之间的约定，用户看不见也不需要看见。

钱包开发者：发送与请求支付协议消息时，按本篇填写 Content-Type 与 Accept 头；收到消息时按类型分派处理。

商户与支付服务器开发者：生成 PaymentRequest 时标注 application/bitcoin-paymentrequest 并声明二进制传输；接收 Payment、回送 PaymentACK 时同样使用对应类型。

全节点与矿工、共识层：完全不必动。这组类型只存在于链下的 HTTP / 邮件传输里，不进入区块链。

六、现在算不算数，以及一个常见误读

状态为 Deployed（已部署）。它与 BIP-70、BIP-72 一起构成支付协议的完整约定：凡实现这套协议的软件，消息的封装标签以本篇为准。

常见误读：

“消息标上了 application/bitcoin-paymentrequest，就说明这份付款请求是经过认证的。”

不对。MIME 类型只是一个标签，作用是声明“这团字节是哪种消息、按二进制传输”，不做任何认证。付款请求的真伪来自 BIP-70 的 X.509 证书与数字签名，与信封上写什么字无关。

七、延伸

• 阅读版：https://bips.dev/71
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki
• 相关：BIP-70 支付协议、BIP-72 bitcoin: URI 扩展
• 仓库总目录：https://github.com/bitcoin/bips

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。