ECDSA 签名常被当成一个确定函数:一把私钥、一条消息,签出来应当只有一个答案。真实规则却留了两个自由度:签名者可以任选随机数 k,算出不同的 r;给定 r 之后,s 与 n-s 又是等价的两个解。自由度是风险的入口——k 值泄露或复用会直接暴露私钥(钱包历史上「同消息双签撞 k」的事故足够写一本合集),而任意合法的签名形态还给恶意签名者留了一条小动作通道:同一笔语义可以膨胀出体积不同、字节不同的签名。BIP-461 由 Liam Gilligan 起草,2026 年 6 月在 bitcoin-dev 发起讨论、8 月 12 日立项,要做的就是把这两个自由度焊死:签名输出完全由私钥和消息哈希决定。
算法骨架其实不新——RFC 6979 早在 2013 年就定义了确定性 nonce:用 HMAC 链把私钥、消息哈希揉进一个初始值,迭代产出一个伪随机数当 k。BIP-461 在此基础上做了三处比特币语境的定制。第一,派生时允许混入一段额外数据 extra(可为空),并用一个尝试计数器 count 驱动重试:若产出的 k 落在无效区间(零或不小于一),或者派生的 r、s 为零,就沿 HMAC 链再走一步换下一个候选,最多可试到 2 的 32 次方减一次。第二,低 r 打磨:r 大于 255 字节的(DER 编码时会多占一个填充字节)不算合格,继续换 k 重签,直到 r 是「小」的。第三,低 s 归一:s 超过半曲线序(n-1 除以 2)时,替换为等价的 n-s——这正是 BIP-62 时代就写进中继政策的规范化。三道工序之后,签名的 DER 编码最长 70 字节,而任意合法 ECDSA 签名最长是 72 字节。
比体积更要紧的是提案的「可检测性」论证。它指出:确定性算法被标准化之后,签名者不再可能「不小心」泄露密钥材料——同一把私钥装进两台独立设备、对同一消息各签一次,只要结果不同,必然至少有一台没守规矩。这个性质把「验设备行为」变成了一次简单的差分测试;而如果没有公认标准,非标准算法连个对拍对象都没有。换句话说,BIP-461 想收编的不只是字节数,是一种问责机制:多签、硬件签名器、审计场景里,「你的设备是否老实跑标准算法」第一次有了不依赖信任的检验路径。对普通用户,直接收益则是可预期的签名长度——交易体积估算、虚拟大小计算在涉及可回收签名或打包器时都会更稳定。
需要冷静看待的是它的层级:这是 Applications 层的草案,不是共识规则。链上验证器至今仍然接受任意合法的 ECDSA 签名,BIP-461 约束的是「诚实签名者应当怎么签」。它能否像当年的低 s 规则那样,从政策约定沉淀为生态默认,取决于钱包、硬件设备与中继政策的跟进速度;RFC 6979 在以太坊生态早已是事实标准,而比特币世界拖到今天才把细节钉成 BIP,这本身就是生态节奏差异的一个注脚。
还有一个现实动因藏在字节数里。比特币的交易体积按虚拟字节计费、按重量单位限块,签名每省两个字节,多签交易与批量服务的长期成本就降一档;更关键的是「可预测」——交易构造器、费率估算器、批量打包器都可以把签名尺寸当常数处理,而不必在 70 与 72 之间做最坏情况预留。这类工程红利单看每笔都是分币级,乘以全网多年就是提案者的真实动机。
快速问答
问:低 r 打磨会不会很慢? 答:r 超过 255 字节的概率约为二百五十六分之一,期望上几乎一两次重试就收敛,实际成本可忽略。
问:它和 BIP-66(严格 DER)什么关系? 答:BIP-66 管的是「什么样的编码字节可被接受」,BIP-461 管的是「签名者应产生哪一个」;前者是验证侧语法,后者是生成侧规范,互不替代。
风险提示:签名实现细节涉及资产控制路径,更换签名库或设备后建议用历史签名对拍验证行为一致,再承接生产流量。

发表评论
还没有评论,来说两句吧。
评论区为展示样式,提交不会被处理。