比特币节点之间的流量默认是明文。任何一个能看到你网络包的中间人——ISP、机房交换机、公共 WiFi 的网关——都能认出「这是比特币流量」，甚至能从你刚广播的交易里读出金额与收款方。对全节点而言这无伤大雅，但对轻钱包（SPV 节点）却可能造成实质性的隐私伤害与审查压力。解决明文问题的现代答案 BIP-324（v2 加密传输）人尽皆知，而它的第一次严肃尝试要回到 2016 年 3 月 23 日 Jonas Schnelli 立项的 BIP-151《Peer-to-Peer Communication Encryption》。它状态 Closed，元数据里带着一行少见的标记：Proposed-Replacement: 324——指定自己的替代者。这份文本因此是整条传输加密演进线上最完整的考古现场。
BIP-151 的设计目标写得很克制：把针对比特币用户的批量监视与流量分析变难，让数据篡改（中间人截断特定命令）对通信双方可识别；同时它坦承自己的边界——加密后的消息仍有尺寸与发送间隔特征，流量类型分析不可能完全消除；VPN、Tor、stunnel 等深层方案早已存在，但对 SPV 与 NAT/DHCP 环境不够友好，且需要相当专业的配置知识，协议内建加密是为了让保护成为默认而非选修。
机制部分是教科书级的密钥协商流程。发起加密的一方先生成一对临时会话密钥，给对端发一条 encinit 消息，内容是 33 字节的压缩临时公钥加 1 字节的对称加密算法编号（当年只登记了一种：0 号 chacha20-poly1305@openssh.com）；应答方回一条同样结构的 encack，双方由此各算出 ECDH 共享秘密。有三条纪律贯穿整个设计。第一，加密谈判必须双向独立：每个方向各跑一遍 encinit/encack，各派生一把对称密钥，两个方向的密文互不相通。第二，加密初始化必须在发送任何其他消息之前完成，version 之后插进来的 encinit 一律忽略，杜绝明文窗口里塞命令的灰色地带。第三，密钥用 HKDF 从共享秘密派生：先以字符串 bitcoinecdh 为盐、把共享秘密与算法编号一起喂进 HKDF-Extract 得到 PRK，再以 BitcoinK1、BitcoinK2 为上下文标签分别扩展出两把 32 字节密钥——算法编号必须进派生输入，这是防「降级到弱加密」的经典手法；再以 BitcoinSessionID 扩展出 256 位会话 ID，供上层把一条加密会话链接到一个身份验证结果。两把密钥的分工也值得注意：K1 只负责加密消息长度字段（明文时代连包长都裸奔，包长本身就是强特征），K2 配合 Poly1305 做认证加密（AEAD）。文档还记了一笔有趣的成本账：Pieter Wuille 的测算显示 SHA-256 每字节的 CPU 周期比 ChaCha20 与 Poly1305 更多，加密可能比现行的未加密消息格式更省 CPU。
它的死因同样有档案价值：Comments-Summary 字段写着「有争议的；有人推荐、有人劝阻」。当年的争议焦点集中在「无认证的加密」这一属性上——BIP-151 的握手没有任何身份绑定，中间人可以各别协商、照常转发，明文变两段密文，窃听者什么都没丢，只是多了一道需要重启的工序；反对者据此认为它提供的隐私是纸面的，却为协议栈增加了永久性复杂度。这个批评后来被 BIP-324 正面接住：v2 传输用 XOR 加 BCH 码的设计容忍比特腐蚀、用可选的身份认证层回答「对面是谁」，把 151 留下的那道追问补完了。BIP-151 的价值因此不在复用，而在标定问题：它用一份完整规格书证明了「P2P 加密」不是加不加的问题，而是加密、认证、降级保护、性能四件事必须同时交付。
常见误区三条。一是把 BIP-151 与 BIP-150（对等认证）混谈：150 管「对面是谁」，151 只管「话别裸奔」，两者在当年的设计里相互独立。二是把 encinit/encack 当成 v2 的消息名：v2 的握手消息是版本协商加密钥交换的新格式，名字与结构都不同。三是以为加密必然暴露不了交易内容：加密保护的是传输路径上的旁观者，广播进内存池之后全网节点照例看得见你的交易内容，隐私账要分段算。
快速问答。问：BIP-151 现在能用吗？答：它是 Closed 状态，主流客户端未实现，只作文献存在。问：它和 Tor 方案怎么选？答：Tor 隐藏 IP 与流量来源，但引入延迟与出口节点风险；协议内建加密不隐藏 IP，胜在默认与轻。问：会话 ID 给谁用？答：规范本身只定义用途概念，具体绑定机制留给实现。
风险提示：本文为网络机制科普，不构成投资建议；对节点通信做隐私评估时请记住，传输加密保护的是链路旁观者，交易一经广播全网可见，两本账要分开算。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。