btcpop 链接：把「我付过了」的证明请求装进二维码

收款证明在电商客服和线下纠纷里是个真实需求：买家想向卖家出示「我付过这笔」，而且不希望把钱包余额一起交出去。BIP-120 付款证明设计了一套「卖家发起、钱包出证」的协议，但它缺一条从卖家设备到买家钱包的传送带——BIP-121 就是那条传送带：一种名为 btcpop: 的 URI 方案，2015 年 7 月 27 日由 Kalle Rosenbaum 立项，与 BIP-21 收款链接同一血统，今天状态是 Closed，随整个付款证明机制一起退出了主流实现。

格式上，BIP-121 几乎照抄 BIP-21 的骨架，改动四处。第一，协议头从 bitcoin: 换成 btcpop:，一眼区分「要钱」和「要证明」。第二，路径部分（也就是放地址的位置）永远为空，因为请求要的不是转到某个地址，而是让钱包翻自己的账本。第三，两个必填参数：p 是证明回递地址，可以是一个 https 网址，也可以是 mailto 这类 URI——钱包生成证明后往这里送；n 是一次性 nonce，Base58 编码，用来防止有人截获旧证明原样重放。第四，可选的 txid 参数，同样 Base58 编码，直接告诉钱包该为哪笔交易出证。规范还保留了 BIP-21 的扩展规则：req- 前缀参数表示硬要求，钱包不认识就必须整条 URI 作废；其余未知参数忽略即可。

有个细节体现了作者对扫码场景的体感：为什么 txid 和 nonce 用 Base58 而不是惯常的十六进制？因为二维码越短越抗糊。手机摄像头隔着亚克力展示牌、镜头有划痕、分辨率又低，字符数从 64（十六进制哈希）压到 44（Base58）能显著提高解码头像的稳定性。这类「为物理世界设计协议」的考量，在今天的支付 URIs 里依然常见。

钱包扫到 btcpop: 之后做什么？按规范，它要用 URI 里的提示参数过滤自己的交易集合：label、amount、message 若存在，必须与当初 BIP-21/BIP-70 收款的记录严格对得上（label 对 memo、amount 对输出合计），txid 必须匹配交易哈希；过滤后把候选交易显示给用户挑选，或按自动规则选定，再走 BIP-120 的签名出证流程——用那笔交易的输出密钥签名卖家给的 nonce，证明「我当时确实控制这笔输出」，全程不必暴露其他任何一笔收支。

这个方案的宿命值得复盘。BIP-120 和 BIP-121 在 2015—2016 年间有过少量实现（BitPay 生态一度试验过 Proof of Payment），但现实里买家根本不愿意在收银台多做三个步骤，而交易所和钱包最终选择了另一条证明路线：直接把对账交给链上数据服务或站内工单。两个 BIP 先后关闭，btcpop: 成为协议博物馆里的展品。但它留下的两个设计——请求也要带 nonce 防重放、二维码载荷能短则短——仍然是任何「扫码办正事」方案的基本功。

把整套流程串起来看一遍，能更清楚这条传送带的位置：卖家系统生成订单，按 BIP-21 给出收款链接；买家钱包扫码付款，交易上链、获得确认；数日后发生争议，卖家想请买家出具凭证，于是生成一条 btcpop: 链接印在网页上——p 参数指向卖家的接收端点，n 是卖家刚生成的随机串，txid 填那笔已知付款。买家钱包扫码，弹出一笔可证明的交易，签名后把证明 POST 回 p。整条链路里买家从不交出账户余额，卖家从不要求预共享密钥。方案优雅是优雅的，唯独一步棋走窄了：它假设买家愿意为一张凭证再扫一次码——而对大多数人来说，让客服在区块浏览器上核对交易号，同样能解决纠纷。