TxID与wtxid有什么不同？比特币交易核验

加密基础

2026年10月23日

TxID 和 wtxid 最实际的区别在于：你拿交易所或钱包给出的 TxID 去区块浏览器查，查到的是交易本身；但如果这笔交易是 SegWit 交易，它的 wtxid 是另一个值，浏览器通常不会把它作为主标识展示。对于没有 SegWit 的老交易，两者相同；对于 SegWit 交易，TxID 不包含见证数据（签名等），wtxid 包含。

欧易OKX交易所
全球领先的加密货币平台，适合新手与进阶交易者
新手福利：注册即享20% 交易手续费减免！

立即注册 APP下载

这个区别在核验交易时会产生一个具体后果：如果你在代码或工具里把 wtxid 当成 TxID 去查，可能查不到，或者查到的不是你想确认的那笔交易。 反过来，如果你需要确认一笔交易的完整数据（包括签名）没有被替换，只看 TxID 是不够的，因为 TxID 对见证数据不做承诺。

计算方式决定了它们承诺什么

比特币 Core 的代码里，Txid 和 Wtxid 是两种类型。Txid 承诺交易中除见证以外的所有字段；Wtxid 承诺包括见证在内的所有字段。用更直白的话说：TxID 是对"去掉签名部分之后的交易"做两次 SHA256，wtxid 是对"包含签名部分的完整交易"做两次 SHA256。

一笔交易如果没有任何输入带见证数据（传统交易），序列化时本来就没有见证部分，两种哈希结果自然一样。一旦交易包含 SegWit 输入，见证数据被附加到交易结构里，wtxid 就变了，而 TxID 保持不变。

为什么需要两个标识

SegWit 引入 wtxid 的直接动因是修复交易延展性。在 SegWit 之前，第三方可以在不改变交易实质内容的情况下修改签名，导致 TxID 变化。如果某个服务用 TxID 来追踪一笔未确认交易，签名被替换后，原来的 TxID 就失效了，但交易本身仍然可能被确认。SegWit 把签名移到见证区域，TxID 不再覆盖签名，所以签名怎么变都不影响 TxID。

但这样一来，TxID 就不再承诺见证数据了。如果有人替换了见证数据（比如替换签名），TxID 不会变，但交易的实际内容变了。wtxid 的存在就是为了给"包含见证的完整交易"提供一个标识。BIP 339 描述了在 P2P 网络中改用 wtxid 来公告和请求交易的方案，原因是：如果只按 TxID 公告，一个节点拒绝了某笔交易后，攻击者可以篡改见证数据产生一个不同的无效版本，但 TxID 不变，节点仍然会被诱导去下载它，造成效率问题。

核验时该用哪一个

查交易是否上链、确认了几次、输入输出了什么：用 TxID。区块浏览器、交易所的提币记录、钱包的交易历史，默认展示和接受的都是 TxID。UTXO 的引用（一笔交易花的是哪个前序输出）也必须用 TxID 来指定。这是最常规的场景，不需要碰 wtxid。

检查一笔交易的完整数据是否被改动过：理论上应该核对 wtxid，但普通用户几乎没有场景需要这样做。钱包软件在构造和签名交易时自己会处理见证数据的完整性。如果你在写代码，并且需要比"交易是否被确认"更细的完整性保证，才需要考虑 wtxid。

一个容易出错的地方是从工具或 API 拿到的哈希值没有标注类型。某些库或接口可能返回一个叫 hash 的字段，它可能是 wtxid 而不是 TxID。Bitcoin Core 开发者聊天记录里有人提到过这个混淆：txid 和 hash 返回不同的值，因为 hash 实际上是 wtxid，而 txid 是去掉见证的哈希。如果你拿一个来路不明的哈希去 mempool.space 查不到，先确认它是不是 wtxid。

一个具体的例子

以 mempool.space 上任意一笔 SegWit 交易为例，页面展示的十六进制 TxID 是浏览器用来索引这笔交易的标识。如果你用 Bitcoin Core 的 getrawtransaction 拿到原始交易，再用某个库计算 wtxid，会得到一个不同的字符串。两者都是这笔交易的"哈希"，但用途不同：前者用来在区块和内存池里定位交易，后者用来对完整交易数据做承诺。

对于 Taproot 交易（同样属于 SegWit 体系），这个区别同样存在。Taproot 的见证数据可能比普通 SegWit 更复杂，但 TxID 依然只覆盖非见证部分。

欧易OKX交易所
全球领先的加密货币平台，适合新手与进阶交易者
新手福利：注册即享20% 交易手续费减免！

立即注册 APP下载