bitcoinjs-lib维护者披露两处比特币(BTC)手续费高危漏洞
bitcoinjs-lib中两处高危漏洞可使部分签名交易显示的手续费远低于实际网络费用,5.2.2、6.1.9和7.0.4三个版本已发布修复。
AI 摘要AI
- bitcoinjs-lib维护者10月26日发布两份高危安全公告
- 另一案例显示9.1万聪手续费被显示为1000聪
- 修复版本为5.2.2、6.1.9和7.0.4
- 受影响范围涵盖v5.1.0至v7.0.3多个版本段
bitcoinjs-lib两份高危安全公告
广泛用于构建比特币(BTC)交易的JavaScript库bitcoinjs-lib存在两处高危漏洞,可能导致部分签名交易显示的手续费远低于网络实际收取的金额。该库的维护者于10月26日发布两份安全公告,将这两个缺陷均定级为高危,并同步为各受影响版本系列发布修正版。两处缺陷都位于钱包在交易确认前展示给用户的手续费核算层。如果用户依据应用显示的数字完成签名,实际广播出去的交易可能携带比屏幕承诺更高的矿工费。两个缺陷均不涉及比特币(BTC)价格或网络共识规则,问题只出在钱包在签名环节展示的账目上。
受影响范围包括通过该库处理PSBT、并依赖其手续费计算或超额手续费防护功能的应用。PSBT由BIP 174定义,是在应用与签名设备之间传递交易数据和签名的互换格式;BIP 174要求每个输入携带其所花费的前一笔输出记录,签名者正是用这个数值来计算并展示手续费。这一结构的雏形出现在隔离见证(Segregated Witness)将签名数据变成一种独立输入类型之后。第一处缺陷在单个输入同时携带两条相互冲突的前一笔输出记录时触发:签名环节读取真实数值,而手续费计算却可能取用另一条记录中较低的那个数字。在维护者的复现案例中,一笔实际为9亿聪的手续费被计算成200聪。签名验证通过,交易提取过程也没有触发默认费率警告。维护者强调,这个数字是对漏洞的复现,并非用户实际损失的统计。
两处缺陷能做什么、不能做什么
第二处缺陷出现在已签名输入完全缺失前一笔输出记录的情况下。当库把该输入的价值按零聚合时,计算出的手续费就会低于交易实际支付的金额。在维护者给出的示例中,一笔实际为9.1万聪的手续费被显示为1000聪。两个案例指向同一结果:屏幕上的手续费数字和超额手续费区块,可能与交易的真实成本脱节。
两处缺陷都无法伪造签名,也无法在未经用户批准的情况下转走比特币。损失的发生需要一个经用户批准、签名有效的交易被广播、被接受并最终确认;届时全额手续费(包括任何超额部分)将依据网络的工作量证明规则支付给执行加密货币挖矿的矿工,多付的差额不会退还给发送方。
受影响版本在v5系列内部并不一致:记录冲突问题波及5.2.0至5.2.1,而记录缺失问题则可上溯至5.1.0,并同样覆盖5.2.1。两处缺陷影响v6全系列(6.0.0至6.1.8)以及从7.0.0-rc.0到7.0.3的v7版本。修复落在5.2.2、6.1.9和7.0.4三个版本。维护者同一天共发布了15份安全公告,其中还涉及其他问题,并指出5.2.3、6.1.10和7.0.5为各系列的当前发布版本。
给开发者的建议相当具体:审计直接和间接依赖是否落在受影响区间;在无法升级的场合,独立核验每个输入的前一笔输出价值,并拒绝数值冲突或缺失的输入。至于具体哪些钱包受暴露、是否已经出现真实损失,目前尚无确认。这两份公告确定了缺陷本身及其在库内的影响范围,但并未统计基于该库构建的钱包数量,因此真正处于风险中的用户群体,超出了这两份文件所能度量的边界。
手续费显示为何是一道信任边界
对于嵌入众多钱包技术栈的库而言,手续费数字是用户在点击确认前最信任的那个数,而这两份公告表明,这一层显示可以与交易的真实成本脱钩。应对之策落在比特币开发团队一侧:依赖树需要审计,手续费显示需要独立验证,而不是对库整体照单全收。签名生态此前也经历过碎片化采用的阶段,例如区块高度709,632的Taproot升级中钱包支持并非强制,市场各方的跟进程度因此参差不齐。在应用确认已运行修复版本之前,用户应把任何PSBT显示的手续费视为参考值,而非最终账单。
本文由人工智能辅助生成、经 AI 审核,并在 COINOTAG 编辑监督 下发布。

