你广播了一笔交易，记下它的哈希准备对账；几分钟后链上确认的却是另一个哈希——钱到了，金额对了，对账单却对不上。这不是诈骗，而是隔离见证上线前比特币的一个结构性特性：交易延展性（transaction malleability）。理解它，是理解 txid 为什么重要、闪电网络为什么必须先解决它的钥匙。
原理：签名不是被动的水印
比特币脚本验证签名时，签名内容覆盖交易的大部分内容——但早期实现里，签名本身所处的字段与它承诺的内容存在自指缝隙：脚本规则允许在特定条件下改写签名的编码形式或脚本结构，交易字节变了、交易哈希随之改变，但“从谁到谁、金额多少”的语义完全不变。一个不改动任何输出的第三方（比如一个转发交易的公共节点），手里就多了一张“同一笔钱、另一个身份证号”的改写权。这段可被第三方改写的字节区，在隔离见证之后被单独归入 witness 字段——它不影响谁能花这笔钱，却参与旧版规则下交易哈希的计算。
危害不在链上，在对账方
改写后的交易在共识层面完全合法：同一个输入集合、同样的输出，矿工照常打包——链本身不受伤。受伤的是拿 txid 当唯一凭证的系统。充值检测是经典事故剧本：交易所看到 A 哈希的交易进入内存池，记账“已收到 A”，攻击者把同笔输入改写成 B 哈希广播，链上确认的是 B，交易所对 A 永远等不到确认，充值单卡死——这段历史正是闪电网络立项阶段的直接动因之一。闪电网络受害更深：通道状态交易的输入若引用一笔可延展的交易，双方签署的下一版承诺可能在对手手里变成另一张脸——通道协议寸步难行。闪电开发社区当时的解法（先签名后定身份、用反演 txid 的 anchor 思路）直接推动了隔离见证的共识路线。
隔离见证：把可变部分搬出哈希
SegWit 的答案在结构：把签名等 witness 数据移出交易 ID 的计算范围——txid 现在只覆盖不含签名的部分，身份先于签名确定，第三方再也找不到“改字节不改语义”的自由度；witness 数据另走独立的承诺（见 重组（reorg）是什么？为什么已打包的交易可能消失邻域：区块头承诺树的结构思路）。对普通用户，这意味着 2017 年后的新式地址（P2WPKH 等）默认免疫此类改写，历史脚本型地址的旧交易在混合场景里仍可能遇到延展问题。
快速问答
- “延展性攻击会转走我的币吗？“不会。它改不了输出与金额，受害的是把 txid 当“不可变收据号”的第三方流程；你的钱跟着输出走，不跟着哈希走。
- “怎么判断一笔交易可不可延展？“看输入脚本类型：见证脚本的输出天然免疫；对旧式 P2PKH 输入，钱包在构造时可选择按严格编码规则签名以降低可延展性。
- “闪电为什么把这事看得那么重？“通道安全依赖“双方签的交易身份永久不变”——承诺交易若不免疫改写，惩罚机制的指向都可能被漂移（通道结构见 比特币闪电网络是什么？）。
- “以太坊有同类问题吗？“以太坊签名同样存在理论上的编码自由，但 EIP-2 强制 s 值取低半区、统一编码，加上账户模型里 nonce 与 from 均进签名摘要，压缩了改写空间。
常见误区
- 误区一：把“两个哈希”理解成“两笔交易”。同一笔资金流转只有一个可确认版本，另一个哈希会在某个版本确认后随竞争失败而消失。
- 误区二：以为 SegWit 后所有交易都不可延展。免疫来自“新式地址的输出被当作输入使用时，其 witness 不进 txid”这一条件；老地址旧 UTXO 参与的交易在构造细节上仍需留意。
- 误区三：把延展性归为“比特币的设计缺陷被黑客发现”。它是脚本规则的早期权衡被社区在闪电时代正视、并以共识升级方式修正的教科书案例（升级路径见 硬分叉是什么？与软分叉、升级有何区别）。
小结
交易延展性的教训是“身份证号必须比签名先生成”：把可变数据排除出身份哈希，收据才配叫收据。SegWit 用它顺手解决的这场结构手术，同时是闪电网络的点火钥匙——链下支付的一切可能性，都建立在“交易身份稳定”这块被修复的地基上。
风险提示：本文不构成投资建议。钱包与交易所的充值确认策略各异，涉及大额对账请以交易内容而非单一哈希字段为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。