比特币 txid 和 wtxid 有什么区别？ 图 1
比特币 txid 和 wtxid 有什么区别？ · 图 1

你在比特币浏览器里看到一串交易哈希，复制到另一处查询时却发现字段名称或结果对不上，可能会怀疑是不是查错了交易。对 SegWit 交易来说，先要确认比较的是 txid 还是 wtxid：两者都由交易数据计算，却使用不同的序列化形式作为输入。理解这道分界，就能解释为什么同一笔交易会有两种标识，也能知道它们何时其实相同。

两个名字背后是两份序列化输入

BIP 141 对这两个标识给出了明确区分。txid 按传统的、去掉 witness 的交易序列化数据计算双 SHA-256；wtxid 则按包含 marker、flag 和 witness 数据的新序列化形式计算双 SHA-256。这里的关键不是“对同一个哈希再取一个名字”，而是哈希函数收到的字节内容不同。输入不同，算出的标识便可能不同。

标识用于哈希的序列化数据BIP 141 定义的计算方式
txid不含 witness 的传统序列化形式双 SHA-256
wtxid包含 marker、flag 与 witness 的新序列化形式双 SHA-256

可以把它想成同一份交易的两种“打包视图”：一份只保留传统交易序列化所需的内容，另一份还把见证数据纳入。双 SHA-256 在两条路径上都相同；造成差别的是送入计算的序列化字节。若想先理解交易输入为何会引用旧交易输出，可读比特币 UTXO 是什么？；那篇文章讲的是输出如何被花费，本篇进一步聚焦交易身份所依据的数据边界。

txid 与 wtxid 分别在哪些地方发挥作用

理解两者用途时，可以从“引用交易”和“携带见证数据”两个问题入手。BIP 144 规定，交易哈希以及输入 outpoint 使用旧的、非 witness 序列化形式计算；包含 witness 数据的新哈希，则对应 witness 序列化形式。也就是说，旧格式的交易引用仍围绕非 witness 版本组织，而需要表达见证数据时，节点可以使用包含 witness 的序列化数据。

这与比特币 UTXO 的定位方式相连：某个输入需要指向先前交易产生的输出，txid 与输出序号构成 outpoint 的引用部分。wtxid 则让含 witness 的交易内容也有对应的哈希标识。不要把“用于引用前序输出的标识”和“包含见证数据的交易哈希”当作两个可以随意互换的字段。

BIP 144 的点对点传输规则也说明了这种兼容安排：请求见证交易数据时，getdata 使用非 witness 序列化的交易哈希；节点返回的数据可以采用 witness 序列化形式。因此，发出请求时用的标识与返回内容所含字节并不要求采用完全相同的序列化视图。若你在协议文档、节点接口或浏览器中看到哈希字段，先看它定义指向哪种交易数据，再判断它对应 txid 还是 wtxid。

没有 witness 输入时，两者为何相同

BIP 141 还给出一个重要边界：如果一笔交易的所有输入都不是 witness program，那么 wtxid 与 txid 相同。原因可以从计算输入理解：当没有适用的 witness 数据时，纳入 witness 的新序列化路径不会提供一组不同的见证内容来区分哈希结果，于是两个标识落在同一结果上。

这条规则有助于避免过度解读。看到 txid 和 wtxid 相等，不足以证明浏览器漏掉字段或节点出了错；对满足上述条件的交易，相等本来就是 BIP 141 规定的情况。反过来，若某笔交易涉及 witness program，不能只凭“它是比特币交易”就推断两个标识应相同，仍要确认自己比较的是对应序列化路径的结果。

浏览器字段不一致时，按这几项核对

区块浏览器可能用“Transaction ID”“Hash”或其他标签展示标识。标签本身不能代替接口定义，因此可以按以下顺序检查：

  1. 确认字段语义。 查看该浏览器或节点接口对字段的说明，判断它表示 txid、wtxid，还是泛称交易哈希。不要仅凭标签长度或显示位置推断。
  2. 确认比较对象。 确保两边指向的是同一笔交易、同一网络和同一数据快照，避免把不同记录当成哈希差异。
  3. 确认序列化范围。 txid 对应不含 witness 的传统序列化形式；wtxid 对应包含 marker、flag 与 witness 的新序列化形式。
  4. 检查输入条件。 若所有输入都不是 witness program，BIP 141 规定两个标识相同；其他情况应按各自定义分别核对。
  5. 区分请求标识与返回内容。 在 BIP 144 的 P2P 规则中，请求见证数据使用非 witness 序列化的交易哈希，响应可以包含 witness 序列化数据。

如果只是要查询一笔交易的公开记录，可以参照交易哈希（TXID）怎么查？了解浏览器核验的基础流程；若要读懂交易原始字节中的字段顺序，可继续看比特币交易的原始字节长什么样。两篇文章分别讨论查询方式与序列化结构，本篇关注的是它们如何形成两种哈希标识。

别把交易标识、签名哈希和 witness commitment 混在一起

txid 与 wtxid 讨论的是交易序列化数据及其双 SHA-256 标识。它们不是交易签名哈希，也不应直接等同于区块中的 witness commitment。后两者属于不同概念；本文事实包没有提供足够材料展开其计算细节，因此不根据名称相似去推导它们的格式或作用。遇到具体实现，应该回到对应规范和接口文档核对，而不是把所有带“哈希”的字段当成一个东西。

同样，单看某个浏览器页面不能确认它采用了哪种字段口径。若要复算指定交易的具体哈希，需要拿到该笔交易的原始数据，并按相应序列化定义独立计算；本文没有实时交易样例，也不给出虚构的计算结果。

记住这条判断线

txid 是对不含 witness 的传统序列化数据做双 SHA-256；wtxid 是对包含 marker、flag 与 witness 的新序列化数据做双 SHA-256。两者的差异在哈希输入，而不是哈希算法。如果一笔交易所有输入都不是 witness program，二者相同；如果你在浏览器或节点接口中遇到不同展示，先核对字段语义、序列化范围和查询对象，再判断是否存在问题。

本文依据 Bitcoin BIP 141 与 BIP 144 解释协议定义，只用于比特币交易结构科普，不构成投资建议或交易建议。核对实际交易时，应以对应接口文档和原始交易数据为准；不要仅凭某个界面标签判断交易内容或状态。