协议演进 / BIP/比特币改进提案 / BIP-121
BIP-121
定义 btcpop: URI 方案，把付款证明请求（回送地址与一次性随机数）编码成可扫码或经 NFC 传递的链接。本 BIP 目前处于已关闭状态。
一、档案卡
| 编号 | BIP-121 |
|---|---|
| 标题 | Proof of Payment URI scheme |
| 作者 | Kalle Rosenbaum <[email protected]> |
| 指定日期 | 2015-07-27 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Closed（已关闭） |
| 阅读版 | https://bips.dev/121 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0121.mediawiki |
二、放在哪一族
应用层的 URI 方案族，是 BIP-120（Proof of Payment）的配套传输层。BIP-120 明确把“请求如何送达钱包”留给单独规范，BIP-121 就是那份规范。
它的骨架直接沿用比特币支付链接 BIP-21：同样的查询参数风格、同样的 UTF-8 与百分号编码规则、同样的扩展规则，只是换了 scheme 与必填参数。同族还有为区块链引用设计的 BIP-122（blockchain: 方案），两者都是“用一条链接把意图递给用户自己的钱包／工具”的思路。
三、它要解决什么
BIP-120 的流程第一步是：想验证付款的一方把 PoP 请求送到付款人的钱包。请求里有回送地址、一次性 nonce、以及定位交易的提示——这些信息怎么递过去，需要一个钱包能统一识别的载体。
本提案的答案是 URI：把请求编码成一条 btcpop: 链接，可以印成二维码让钱包扫，也可以经 NFC 传递。钱包一打开链接，就知道要为哪笔付款生成证明、把证明发到哪里、用哪个 nonce。
四、规则本身
4.1 与 BIP-21 的四点差异
规范主体与 BIP-21 相同，差异只有四处：
- scheme 是
btcpop，不是bitcoin； - 路径部分（地址部分）恒为空；
- 必填参数
p：PoP 的回送目的地，例如一个 https: URL 或一个 mailto: URI； - 必填参数
n：nonce，Base58 编码。
可选参数 txid 给出要证明的交易哈希，同样用 Base58 编码。除 p 与 n 外，所有参数都只是帮钱包定位交易的提示。BIP-21 的可扩展性同样适用（例如将来可加 date、toaddr 参数）；req- 前缀参数的规则不变：钱包不支持某个 req- 参数时，必须视该 URI 为无效。
4.2 为什么强调 URI 要短
二维码太长，镜头有划痕或分辨率低时就扫不稳。因此 nonce 与 txid 都用 Base58 而非十六进制：txid 由此从 64 个字符压到 44 个。p 参数也不应无谓地长。
4.3 钱包如何解读提示
钱包用 URI 中的提示过滤自己的交易集：label、amount、message 若出现，必须与原付款的对应数据精确匹配（label 对应 BIP-21 的 label 或 BIP-70 PaymentDetails 的 memo；amount 对应原付款输出金额之和；message 在 BIP-70 中无对应项）；txid 必须与付款的交易哈希一致。
过滤后把候选交易展示给用户选择；恰好剩一笔时可以自动选中，但必须保留让用户在匹配项中自由选择的方式。候选为空时要提示无匹配；作为兜底，还必须允许用户无视全部提示、从钱包里任选一笔交易——以防钱包元数据因恢复备份等原因丢失。
4.4 PoP 如何回送
p 指向 http: 或 https: 时，钱包必须支持，且须用 POST 发送：PoP 以二进制序列化的交易作为请求体，Content-Type 设为 application/bitcoin-pop。p 也可以是其他类型的 URI（例如 mailto:）。
原文示例的结构如：btcpop:?p=https://www.example.com/pop/352&n=zgWTm8yH&label=video%2042923——回送到示例站点、带 nonce 与标签提示，全文可到原文核对三则完整示例。
五、谁必须动
普通持币人：无协议层面变化。多见的动作只是扫一个 btcpop: 二维码、在钱包里确认要证明的那笔付款。
钱包开发者：需注册处理 btcpop: scheme，按 4.3 实现提示过滤与兜底选择，并按 4.4 实现 http/https 的 POST 回送。
服务端开发者：需生成合规的 btcpop: URI（必填 p 与 n、nonce 每次随机），并准备好接收端点；其后的验证流程属 BIP-120。
全节点与矿工／共识层：完全不动。这是纯应用层的链接格式约定。
六、现在算不算数，以及一个常见误读
状态为 Closed（已关闭）。它依赖的 BIP-120 同样已关闭，btcpop: 没有成为钱包普遍注册的 scheme；原文给出的参考实现仍是当年的演示服务器与 Mycelium 分支钱包。
常见误读：“btcpop: 链接是用来付款的。”不对。它与 bitcoin: 支付链接长得像，但路径（地址）部分恒为空、根本不指定收款方；它传递的是一份“请证明你付过款”的请求。扫它不会转出任何比特币，真正签出的 PoP 也被 BIP-120 设计为不能上链成交。
七、延伸
- 阅读版：https://bips.dev/121
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0121.mediawiki
- 相关：BIP-120 付款证明、BIP-21 URI 方案、BIP-122 区块链引用 URI 方案、BIP-70 支付协议
- 仓库总目录：https://github.com/bitcoin/bips