协议演进 / BIP/比特币改进提案 / BIP-150

BIP-150 对等节点认证

让节点用预共享的身份公钥在加密通道上相互认证，确认对方身份并据此开放或限制节点服务，且不给指纹识别留机会。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

P2P 网络身份与隐私族的一篇，与它的前置文档是一对：

BIP-151：对等通信加密。本篇的认证必须跑在它建立的加密通道之上——原文第一条规范就写明，加密会话未建立，不得开始认证。

两者之后，这条路线由 BIP-324（v2 P2P 加密传输协议）以另一套设计承接；本篇与 BIP-151 的状态均为 Closed。

在本篇内部，认证解决的问题不是“数据会不会被偷看”（那是加密的事），而是“对面到底是不是我以为的那个节点”。

三、它要解决什么

原文的设想从节点运营者的两个需求出发：

• 运营者想把某些节点服务只开放给选定的一部分节点，或给它们更高的数据流优先级；
• 节点要向特定对方广播交易、向对方请求过滤等可能泄露敏感信息的操作，运营者需要先确认对面确实是目标节点，而不是中间人（MITM）攻击者。

原文列出的认证收益包括：

• 连接已知节点时能识破中间人攻击；
• 把耗资源的交易过滤只开放给特定节点；
• 把可能导致节点指纹暴露的敏感信息（如手续费估算）只给认证过的节点看；
• 允许向已认证节点使用自定义消息类型（私有扩展）。

难点在于隐私：认证过程本身不能变成一种“探测”工具——随便连上来问一句，就能试出对方是不是某个身份。整篇规范的哈希问答设计，都是为了在证明身份的同时不给指纹识别留机会。原文同时明说：本篇不做“首次使用即信任”（TOFU），身份公钥必须事先通过其他渠道交换。

四、规则本身

4.1 前提与总则

• 方案基于椭圆曲线密码的 ECDSA，秘密（私钥）永不在线路上传输；
• 认证只能在 BIP-151 的加密通道建立之后开始，认证会用到加密通道的会话 ID（encryption-session-ID）；
• 身份公钥必须预先通过另一渠道共享（邮件/PGP、纸面交换等），本篇不覆盖公钥的首次分发；
• 认证状态保持到加密/连接终止为止；一条连接只允许一次认证，要重新认证必须重建连接。

4.2 两份本地名单与身份密钥

每个支持认证的节点要维护两份可由用户编辑的“数据库”：

• known-peers：已知的身份公钥，连同网络标识（IP 与端口），作用类似 OpenSSH 的 known-hosts 文件；
• authorized-peers：被授权的身份公钥名单，认证通过后能访问哪些受限服务，由它决定。

本地身份密钥为 ECC 密钥（私钥 32 字节），一个节点可以配置多把。原文特别提醒：每个网络接口（IPv4、IPv6、Tor）应使用各自独立的身份密钥，否则可能把某个 Tor 地址与某个 IP 地址关联起来。

4.3 双向认证的四步问答

认证要求双方互相认证，全程只交换哈希与签名，不直接亮出公钥：

1. 请求方发送 AUTHCHALLENGE（哈希）；
2. 应答方回 AUTHREPLY（签名）；
3. 请求方发送 AUTHPROPOSE（哈希）；
4. 应答方再发 AUTHCHALLENGE（哈希），请求方再回 AUTHREPLY（签名）。

三个消息的构造都有防探测设计：

• AUTHCHALLENGE（32 字节）：hash(加密会话 ID || 挑战类型 || 对方预期的身份公钥)，挑战类型为单字符，首次请求用 i，第二次（对方发起）用 r。应答方用自己的公钥在本地算同样的哈希比对即可，外人无法从哈希反推公钥；
• AUTHREPLY（64 字节）：用身份私钥对加密会话 ID 所做的紧凑签名；若挑战哈希与本地公钥对不上，签名位置必须填 64 字节的零——看起来像应答了，实际什么也没证明；
• AUTHPROPOSE（32 字节）：hash(加密会话 ID || "p" || 本方身份公钥)，用来提议公开本方身份；哪怕提议的公钥不在对方的 authorized-peers 名单里，对方也必须回 AUTHCHALLENGE（对不上时填 32 字节零）。

配套的隐私纪律是：验证失败也不能撕破脸。原文规定，即便签名无效，请求方仍须继续流程、改发 32 字节随机数充当 AUTHPROPOSE；认证过程中途断开连接或中止，同样不被允许——因为“断开”这个动作本身就会泄露“对不上”的信息。

4.4 认证后重新换钥与身份地址

第二次 AUTHREPLY 完成之后，双方必须按 BIP-151 重新生成对称加密密钥（re-keying），但换钥的推导哈希要把双方的身份公钥一并算进去，使加密会话与已认证的身份绑定。

为方便人工核对，身份公钥应以“身份地址”的形式展示与记录：对公钥做 ripemd160(sha256) 后作 Base58Check 编码，前缀字节为 0x0F、后跟身份地址版本号 0xFF01，外观上如同一个可比对的指纹字符串。

4.5 兼容与代价

向后兼容：不支持本篇的节点会忽略新的 AUTH* 消息。原文自陈的缺点是慢：当 authorized-peers 名单很大时，应答方要对名单里的每个公钥逐个算哈希比对 AUTHPROPOSE，名单越大越慢。

五、谁必须动

普通持币人：不涉及钱包与地址体系。这里的“身份”是节点的身份，不是用户的比特币身份；不动私钥，也不上链。

钱包开发者：直连节点的轻钱包若想使用受限服务，需要实现这套认证握手并管理 known-peers；托管型与接口型钱包一般不涉及。

全节点与矿工：完全自愿。节点运营者自行决定是否配置身份密钥、维护两份名单、以及把哪些服务设为“认证后可用”。不实现的节点照常联网，只是进不了别人的白名单。

共识层：本篇不触碰共识。它全程是节点之间的可选会话层协议，认证与否不影响区块与交易的有效性。

六、现在算不算数，以及一个常见误读

状态为 Closed（已关闭）。这套认证方案没有成为比特币 P2P 网络的通行做法；它的前提 BIP-151 同样为 Closed，而节点间加密这条线后来由 BIP-324 以不同设计推进。本篇档案序言中亦留有一句评论摘要，记为“有一人表示不鼓励实现（Discouraged for implementation）”——这属于提案讨论的留痕，本页如实转述，不另作评价。

常见误读：

“BIP-150 是给比特币地址做实名认证。”

完全不对。它认证的是节点与节点之间的连接身份，材料是运营者事先私下交换的节点身份公钥；它不登记地址、不绑定用户、不产生任何链上记录。把 P2P 层的运维认证读成用户层面的身份制度，是把两个层面混在了一起。

七、延伸

• 阅读版：https://bips.dev/150
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
• 相关：BIP-151 对等通信加密、BIP-324 v2 P2P 加密传输协议
• 仓库总目录：https://github.com/bitcoin/bips

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。