扫二维码付款时，你有没有想过：钱包怎么知道付给了谁、多少钱、要不要找零？最原始的方案是 BIP21 那种 bitcoin:地址?amount=… 的链接，但地址是死的，商户找零、多收款人、过期时间全靠猜。BIP70 支付协议试图把“账单”变成一种钱包能机器阅读、能用证书验证的结构化请求，代价是引入一套中心化色彩很浓的证书信任体系。它在 2013 年由 Gavin Andresen 与 Mike Hearn 提出，此后十余年是一场关于“支付体验该由谁定义”的完整实验，也早已进入消亡倒计时。
一份账单该有什么
BIP70 用 Protocol Buffers 定义了三类消息：payment request（商户发起的收款请求：金额、时间戳、退款地址、手续费提示）、payment（钱包付完款后的回执）、payment ACK/NAK（商户对付款的确认或拒绝）。相较一个裸地址，它多了解决真实商户痛点的字段：一次性合并多笔收款（一次扫码付多个订单）、指定退款与找零去向、给账单设过期时间。协议用 X.509 证书对请求签名，钱包可以显示“这份请求来自某某公司、证书由某某机构签发”，理论上把“扫码劫持换成攻击者地址”这类中间人攻击变成可检测事件。
为什么没活下来
设计目标没有错，错的是信任地基和工程成本。证书链条依赖传统 PKI 的证书颁发机构体系——这个体系历史上屡有签发失误，而密码社区早已习惯“不依赖任何可被钓鱼或胁迫的中心权威”的安全模型；部分部署还采用自签证书，警告弹窗对用户形同虚设。协议本身的状态机与错误处理复杂，钱包正确实现的成本高、可测试性差，安全细节又依赖实现质量。对商户端，它把“收款”从静态二维码变成需要持续可用的服务器端点，可用性与隐私问题（请求服务器知道你何时查询了账单）一起招致批评。多重因素叠加：采用率始终没有滚起雪球，2018 年底一场围绕签名交易捕获漏洞的公开讨论只是压垮骆驼的最后一根稻草，社区共识早已转向“协议本身该被弃用”。
版本时间线（要分清三态）
2013 年提案提出；2017 年被最大的比特币支付处理商全面强制使用（当时其发票系统只接受该协议）；随后争议发酵——Bitcoin Core 在 0.19.0 中把对该协议的支持默认关闭，0.20.0 起移除了对它的完整支持。也就是说，“协议在 BIP 仓库里存在”“某钱包能解析”“Core 默认支持”是三件事，时间线各自独立。今天绝大多数钱包与商户路径都不再依赖它；处理收款链接这类请求时，把它视为遗留系统、按需核验每一字段的立场更贴近现实。
它留下的遗产
支付请求这件事没有被放弃，只是换了几条路继续长：BIP21 链接（可嵌入 lightning: 参数）仍是事实标准；BOLT11/BOLT12 发票把“机器可读账单”在闪电网络里做得更彻底（金额、过期、描述哈希都在编码内）；一些商户采用带认证的简化 JSON 接口，保留了服务器响应能力但不再背 X.509 的历史包袱。回看 BIP70，它的教训比代码更值钱：在加密世界里，任何重新引入中心化信任根、且把复杂度推给实现方的改进，哪怕 UX 叙事再动听，也很难在长期竞选中活下来。
常见误区
一是把“扫码时弹出公司名”当成安全证明：那取决于证书体系与钱包校验质量，钓鱼页面同样能显示字段；地址金额以你自己节点或可信来源的解析为准。二是把“某支付商仍在使用”误读为“主流标准”，商户系统惯性与协议生命力是两回事。三是把 BIP70 与 BIP21 混淆：后者是 URI 语法，至今在用，前者是重量级请求协议，已进博物馆。
风险提示：本文为支付协议演进史科普，不构成任何投资建议；各软件的支持状态随版本变化，请以当期发布说明为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。