想用共识规则堵住可延展性:比特币为什么没有走BIP 62这条路 图 1
想用共识规则堵住可延展性:比特币为什么没有走BIP 62这条路 · 图 1

比特币里同一笔交易可以有好几个不同的编号,却花的是同样的钱——这就是交易可延展性。围绕怎么根治它,2014 年 3 月有人提交了 BIP 62,标题直译就是“处理可延展性”,作者是 Pieter Wuille。它的思路很直接:修改共识层的交易有效性规则,让所有能被改形的写法直接不合法。十一年过去,这份提案的状态停在 Closed,从未部署。搞清楚它为什么被搁置,比记住它的内容更有价值。

它想修的是什么

ECDSA 签名本身带着一批等价写法:编码规则允许签名换一种表示而依旧有效;脚本里多塞一个恒真判定、调整某些数据推入的方式,也能造出字节不同、逻辑相同的交易。这些改法都不需要花费任何资金,却让 txid 变了。对普通转账只是观感问题,对依赖“先算好未上链交易编号再往下搭”的程序却是致命的——闪电网络的前身状态通道要求双方先锁定一笔资金交易的编号再生成后续交易,编号变了,整条依赖链就断了。历史上交易所因编号变动导致充值记账混乱的事故,也把这个问题推到了台前。

想用共识规则堵住可延展性:比特币为什么没有走BIP 62这条路 图 2
想用共识规则堵住可延展性:比特币为什么没有走BIP 62这条路 · 图 2

BIP 62 的方案与它的尴尬

BIP 62 提出的是一揽子共识规则收紧:规范签名与脚本的各种写法,从规则层面堵死改形空间。但提案文件开头有一段少见的自我声明,大意是这份文档仍在编写中、不完整、未被实现、不适合部署。它本质是一个工作草案,规则条目多、兼容性判断复杂,而且堵得再死也只能覆盖“发送方不主动绕开”的情况。2015 年隔离见证的设计文档里专门比较过它:如果靠 BIP 62 做可延展性修复,多方必须先见到对方的资金交易签名才能签自己的后续交易,先亮签名的一方会被对方无限期锁住资金——这个先有鸡还是先有蛋的困境,恰是状态通道场景最不能接受的。

比特币实际走的两步

现实中的修复分成两层。第一层是 BIP 66:要求签名严格符合 DER 编码。它作为中继策略在核心客户端 0.8.0 起就被执行,后来以“版本 3 区块加旧式计票门槛”的方式完成软分叉部署,规范状态为 Deployed;由于任何不合规签名都能无损改写为合规形式,这条规则几乎不损失功能。隔离见证规范在陈述收益时明确引用了这一点,称其附带减少了可延展性。第二层是 BIP 141 隔离见证:把见证数据挪出编号的计算范围,编号只对不含签名的部分做哈希,从此签名怎么改都不影响 txid。这是结构性的根治,规则本身反而不需要禁止任何旧写法。两步走完,BIP 62 的生态位被清空,闭案是自然结果。

快速问答

问:为什么说隔离见证修好了可延展性而不是禁止了它?

答:隔离见证没有让“变形后的签名”违法,而是让签名不再参与交易编号的哈希输入。你依然可以改字节,但改出来的交易 txid 不变,依赖编号的协议就安全了。

问:BIP 62 被否决了吗?

答:官方状态是 Closed,提案头部自己写着不完整、未实现、不适合部署。它更多是被后来的方案超越了,而不是某次投票明确否决。

常见误区

一是把 BIP 66 的 DER 规则说成可延展性的完整修复,它只堵住了签名编码一类,脚本层面的改形依旧存在。二是把隔离见证当成一次硬分叉,它是带软分叉兼容设计的升级,旧节点靠见证承诺机制接受新结构。三是拿 BIP 62 的存在证明“协议随时会改规则堵你的路”,一个从未部署的 Closed 提案不构成任何部署先例。

风险提示:本文为协议历史科普,不构成任何投资建议;涉及协议变动的判断请以官方规范与版本说明为准。