“身份”在 P2P 层和签名层是两回事
先把问题拆开：一笔比特币交易之所以有效，是因为输出脚本验证通过了密码学签名——这一层的”身份”就是私钥，任何网络消息都伪造不了它。而节点之间交换区块和交易的 P2P 层，从设计之初就没有身份概念：谁连上谁，只要说的是同一套协议、跑在相同魔法字节的网络上，就交换数据。BIP-324（v2 加密 P2P 传输）在这条分界线的网络一侧做了文章，但它验证的对象仍然不是”你是谁”。
v2 传输到底加了什么
v2 传输为节点间的连接引入一次密钥协商：发起方先随机生成一个 secp256k1 私钥并发送其 ElligatorSwift 编码（编码结果与随机字节无法区分），双方再据 ECDH 共享秘密用 HKDF-SHA256 派生两个方向各自的加密密钥；数据包的载荷用 ChaCha20-Poly1305 这一 AEAD 加密认证，包长度字段则用另一把独立密钥的 ChaCha20 做不认证的加密。之后所有 P2P 消息（包括最初的握手消息）都在加密信道里走，握手前的垃圾流量也被纳入认证。这样做的收益是：路径上的中间设备不能再把”比特币流量”当明文识别，也就难以按协议特征做干扰或降级；单条消息被中途改写会被认证标签发现。规范明确写道：这层加密不提供身份认证——它不含任何签名、证书或长期密钥的验证。
为什么没做身份认证
规范给出的理由可以概括为三条。第一，比特币节点的网络地址本身就是轮换且廉价的，绑定身份的收益有限，而证书分发与吊销会拖慢每一次连接建立。第二，一旦在传输层验身份，就等于把一层新的全局信任结构（谁能签发节点身份）塞进一个以无需许可为底色的协议里。第三，安全性上够用：想伪造一笔交易请走密码学路径，那里有 ECDSA 或 Schnorr 签名把关；传输层要防的是被动窃听与在路途中随意篡改，这两件事加密层已覆盖。规范同时提醒：加密不等于匿名，v2 传输自身不隐藏 IP，想隐藏连接位置要配合 Tor 之类的传输层手段——这属于连接层隐私，与身份验证是两条线。
那中间人还剩什么手段
没有身份认证，意味着理论上的在路径中间人可以制造”两半连接”：与你的节点各说各话，把两侧流量转发拼接。但这类位置做不了更危险的事：它伪造不了区块，因为区块里每笔交易都要过密码学验证；它也藏不起恶意区块，比特币不是先到先得，而是累计工作量最大的链赢——中间人递给你一个假链头，你的节点会自己向更多对端要区块和头并比对工作量。中间人最现实的能力只是拒绝服务：掐断这条连接、延迟消息、或同时欺骗这一条连接看不到某些交易。针对断连的对策不是加密，而是多连几个独立对端。
部署现状怎么查
v2 传输由 Bitcoin Core 自 v27.0 起默认启用（可用 -v2transport=0 关闭，对不支持的对端自动回落明文）；其他实现的支持进度各不相同，是否启用应查各自版本的发布说明与配置项，而不是从版本号区间猜。在 Core 里可以通过 debug.log 中每对连接的传输类型信息核对当前连接实际走了哪条路。需要强调：是否加密不改变一条连接的信任权重——节点对等端始终按”不可信”对待，所有数据都要过本地全验证，这条原则在任何版本都一样。
一句话收束
“比特币节点如何验证身份”这个问题本身就藏着一个错位：签名层用数学验身份，网络层压根不验身份，v2 传输加强的是”别被中间设备看懂和偷改”。把这两层分开，你就能准确回答”加密了是否就没人能冒充我”——传输层没有冒充的概念，能冒充你花钱的只有拿到私钥的人。本文只做机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。