TxID vs wtxid: What’s the Difference? Bitcoin Transaction Verification

 / 
7

The most practical difference between TxID and wtxid is this: when you take a TxID from an exchange or wallet and look it up on a block explorer, you find the transaction itself. But if the transaction is a SegWit transaction, its wtxid is a different value, and explorers usually do not show it as the main identifier. For older transactions without SegWit, the two are the same. For SegWit transactions, the TxID does not include witness data such as signatures, while the wtxid does.

OKX Exchange
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!!

This difference has a concrete consequence when verifying transactions: if you treat wtxid as TxID in code or tools, you may not find the transaction, or you may find a different one than the one you want to confirm. Conversely, if you need to confirm that the full data of a transaction, including signatures, has not been replaced, checking only the TxID is not enough, because the TxID does not commit to witness data.

How they are calculated determines what they commit to

In Bitcoin Core's code, Txid and Wtxid are two different types. Txid commits to all fields of a transaction except the witness. Wtxid commits to all fields including the witness. In plain terms: the TxID is a double SHA256 of the transaction with signature data removed, while the wtxid is a double SHA256 of the complete transaction including signature data.

If a transaction has no inputs with witness data, meaning it is a legacy transaction, its serialization has no witness part, so the two hashes are naturally the same. Once a transaction includes SegWit inputs, witness data is attached to the transaction structure, so the wtxid changes while the TxID stays the same.

Why two identifiers are needed

The direct reason SegWit introduced wtxid was to fix transaction malleability. Before SegWit, a third party could modify signatures without changing the essential content of a transaction, causing the TxID to change. If a service used the TxID to track an unconfirmed transaction, the original TxID would become invalid after the signature was replaced, even though the transaction itself could still be confirmed. SegWit moves signatures into the witness area, and the TxID no longer covers signatures, so signature changes do not affect the TxID.

But because of this, the TxID no longer commits to witness data. If someone replaces witness data, such as swapping a signature, the TxID does not change, but the actual content of the transaction does. The wtxid exists to provide an identifier for the complete transaction including the witness. BIP 339 describes a scheme for using wtxid to announce and request transactions on the P2P network. The reason is that if nodes only announce transactions by TxID, after a node rejects a transaction, an attacker can tamper with witness data to produce a different invalid version whose TxID is unchanged, and the node can still be tricked into downloading it, causing efficiency problems.

Which one to use when verifying

To check whether a transaction is on chain, how many confirmations it has, and what its inputs and outputs are: use the TxID. Block explorers, exchange withdrawal records, and wallet transaction histories all display and accept the TxID by default. References to UTXOs, meaning which previous output a transaction spends, must also be specified by TxID. This is the most common scenario, and you do not need to touch wtxid.

To check whether the complete data of a transaction has been modified: in theory you should verify the wtxid, but ordinary users rarely have a scenario that requires this. Wallet software handles witness data integrity on its own when constructing and signing transactions. If you are writing code and need a finer integrity guarantee than just whether a transaction is confirmed, then you should consider wtxid.

One easy mistake is getting a hash value from a tool or API without a type label. Some libraries or interfaces may return a field called hash, and it may actually be the wtxid rather than the TxID. Bitcoin Core developer chat logs mention this confusion: txid and hash return different values because hash is actually the wtxid, while txid is the hash without witness data. If you take a hash of unknown origin to mempool.space and cannot find it, first check whether it is a wtxid.

A concrete example

Take any SegWit transaction on mempool.space as an example. The hexadecimal TxID shown on the page is the identifier the explorer uses to index that transaction. If you use Bitcoin Core's getrawtransaction to get the raw transaction and then use a library to calculate the wtxid, you will get a different string. Both are hashes of the same transaction, but their uses are different: the former is used to locate the transaction in blocks and the mempool, while the latter is used to commit to the complete transaction data.

For Taproot transactions, which also belong to the SegWit system, this difference also exists. Taproot witness data can be more complex than ordinary SegWit, but the TxID still covers only the non-witness part.

OKX Exchange
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!!

References

  1. Bitcoin Core · transaction_identifier.h, 2026-10-22
  2. Bitcoin Core · Transaction Structure and Lifecycle, 2026-10-22
  3. BIP 339 · WTXID-based transaction relay, 2026-10-22
  4. Bitcoin Optech · Newsletter #272 (Type-safe transaction identifiers), 2026-10-22
  5. Bitcoin IRC · bitcoin-core-dev 2017-10-16 log, 2026-10-22
  6. Binance · What is Segregated Witness, 2026-10-22