付款前先亮明身份再加密回函：BIP-75 带外地址交换的两封新信

把比特币付给别人，最原始的办法是对方甩给你一串地址。静态地址伤隐私，BIP-32 的观战公钥（X-Pub）又要求钱包替你盯着一整条对方链条的地址、还可能把钱打到对方已经丢钥匙的旧地址上。2015 年 11 月 20 日立项的 BIP-75 想解决的就是「让钱包自己把地址要回来」：它是 BIP-70 支付协议的扩展，状态 Deployed，作者是 Justin Newton、Matt David、Aaron Voisine 和 James MacWhyte。它做两件事——让付款方也能签名亮明身份，让回函在离开本机前就完成加密。

先看它在 BIP-70 的基础上加了什么。第一封信叫 InvoiceRequest：想付款的一方把「我的公钥、我想付多少、备注、一个接收回信的 notification_url」打包，再附上一份 PKI 签名。第二层变化是 pki_type 字段扩容：除 BIP-70 原有的 x509 证书外，新增 OpenPGP 证书（pgp+sha256）和 secp256k1 公钥（ecdsa+sha256）两种，且 SHA1 被弃用只留 SHA256。BIP-70 时代只有收款方能出示证书，BIP-75 让双方都能带身份，收发双方各自留下的链下账务流水因此都变得「认得出人」。

第三封信的分工要拆开讲。所有消息现在都装进 ProtocolMessage 信封——版本号、状态码、消息类型（INVOICE_REQUEST、PAYMENT_REQUEST、PAYMENT、PAYMENT_ACK 四选一）、序列化正文、和一个把整轮交换串起来的 identifier。错误不再靠传输层状态码传话，而是写进信封正文里，这让跨服务器的协议行为可预测。轮到加密登场：EncryptedProtocolMessage 用双方公钥做一次 ECDH 得到共享密钥，把真正的 ProtocolMessage 用 AES 加密后再走 TLS。也就是说，即使中间那台存储转发服务器被攻破，攻击者也读不了、改不动内容，只能删掉密文——原文列举的三个用例之一正是「移动钱包借公共中转站异步收发货单」。

版本协商规矩也定了：本 BIP 定义协议版本 1。首发消息带自己能懂的最高版本号；收到版本高于自己认知的消息，必须原样退回并附状态码 101（version too high），把对方的版本号降回来重发，或者直接中止。这套「先报家底、过高就退」的做法与许多网络协议的版本降级一脉相承。

它设想的场景里最有画面感的是「地址簿」：钱包只需要存每个收款人的公钥，付款那一刻在后台悄悄完成一轮请求-回函，拿到的是一次性的新地址。如果对方换机丢了钥匙，这轮协商会直接失败，钱就不可能被误打到「死地址」上。第二个场景是「有许可的地址发放」：收款方可以先看付款方身份再决定给不给地址，白名单客户自动拿新址，陌生请求则被挡住——BIP-70 时代服务器来者不拒地发地址的问题就此收口。

它的宿命与 BIP-70 绑定。支付协议家族依赖 TLS 证书体系与专用基础设施，钱包实现者寥寥，随 BIP-70 一起淡出日常使用，被后来以明文 URI 为主的收款方式和闪电发票等路线替代。但「收款地址应协商而非静态」「回函内容应端到端加密」这两条主张，在 Payjoin 与各类 invoice 协议里都能找到回声。

一次交换的完整旅程值得走一遍。付款方钱包先生成一对临时 secp256k1 密钥，把公钥、金额、备注和自己的 notification_url 装进 InvoiceRequest，用选定的 PKI 类型签上名，经 TLS 发给收款服务器；服务器核对签名后，收款方钱包在本地决定这次付款要用的新地址，构造 PaymentRequest，把整封回信先用 ECDH 共享密钥做 AES 加密、再套上 EncryptedProtocolMessage 外壳，送往付款方留下的回调地址；付款方解密、验地址、上链付款，最后可能再走一轮 Payment 与 Payment_ACK 收尾。整条链路上，公开服务器只经手密文与路由信息，两端的钱包各自留下一份带身份的人话日志——这正是作者自述的目标：「让比特币更有人味，同时提升交易隐私」。

常见误区有三个。其一，以为 BIP-75 改了链上交易：它全部工作发生在付款之前的带外（out-of-band）通信里，链上只看到普通转账。其二，把 InvoiceRequest 当成收款方专属：恰恰相反，它是付款方主动发起的。其三，以为加密靠 TLS 就够了：BIP-75 特意在 TLS 之下再加一层 ECDH 加密，防的正是 TLS 终端（服务器）本身。

快速问答。问：它和 BIP-70 的关系？答：是扩展而非替换，PaymentRequest 等原消息仍在用，新增了信封与加密外壳。问：为什么要叫带外交换？答：地址与票据在区块链之外的通道协商，链上只出现最终结果。问：今天做收款系统还要读它吗？答：作为支付协议史料值得读；实现层面前者罕有人支持。

风险提示：本文是协议机制科普，不构成投资建议；任何要求你在邮件或聊天窗口直接转账号的「付款流程」都先核对域名与身份，协议加密不了你点进去的那个假页面。