wTXID

A wTXID is a hash of a whole transaction, witness included. The TXID hashes the same transaction without its witness. Blocks use wTXIDs to commit to the witness data, while you still use TXIDs to find a transaction on the chain.

For a transaction with no witness, the two are identical.

How is a wTXID different from a TXID?

The TXID covers the version, the inputs, the outputs and the locktime. It leaves out the marker, the flag and the witness. The wTXID covers all of the raw transaction, including those three parts.

The difference only exists for SegWit transactions. A legacy transaction has no marker, flag or witness, so the wTXID and the TXID are the same value.

How is a wTXID calculated?

A wTXID comes from running HASH256 over the serialized transaction. HASH256 means SHA-256 applied twice. In the notation of BIP 141, it looks like this:

wTXID = HASH256(version | marker | flag | inputs | outputs | witness | locktime)

Bitcoin displays hashes in reverse byte order, so the value the hash function produces is flipped before you see it. The same rule applies to TXIDs.

Here is the calculation in Python. It needs only the standard library, and raw_hex is the full serialized transaction, as a node returns it:

import hashlib

def hash256(data: bytes) -> bytes:
    return hashlib.sha256(hashlib.sha256(data).digest()).digest()

raw = bytes.fromhex(raw_hex)        # the whole transaction, witness included
wtxid = hash256(raw)[::-1].hex()    # reverse the bytes for display

The TXID needs one more step. Its input is the same transaction with the marker, flag and witness removed, so a parser must strip those fields first.

A SegWit example

Take the SegWit transaction c06aaaa2…. Its raw form is 225 bytes. Stripping the marker, flag and witness gives the TXID:

TXID:  c06aaaa2753dc4e74dd4fe817522dc3c126fd71792dd9acfefdaff11f8ff954d
wTXID: f12d56f2234e809129dbf59392961bbe7a89b6250651f6aea7852cc00ced63ff

The two values differ because the wTXID hashes the witness too. Only the wTXID changes if someone edits a signature.

A legacy example

The legacy transaction 25346687… has no witness, so its TXID and wTXID are the same:

25346687d5d10239c25a88193c97228327826a4ff66a36c4ba7e038f3e2ae9ed

If you run your own node, bitcoin-cli getrawtransaction <txid> 1 returns a hash field. That field holds the wTXID, which equals the TXID for legacy transactions.

Where are wTXIDs used?

wTXIDs are used in one place: the block's witness commitment. A block whose transactions carry witness data must commit to it. The commitment comes from a merkle tree built over the wTXIDs, called the witness merkle root.

The steps run in order:

1. Take the wTXID of every transaction in the block. The coinbase is the exception: its wTXID counts as 32 zero bytes, because it holds the commitment itself.
2. Build a merkle root over that list. The result is the witness merkle root.
3. Hash the witness merkle root together with the 32-byte witness reserved value, which is zeros today. The result is the wTXID commitment.
4. Place the commitment in an output of the coinbase transaction, after a 4-byte header. If more than one output has that form, the one with the highest index counts.

Example: block 553,724

Block 553,724 holds four transactions. The first three use SegWit, and the last does not. The table lists each value as explorers show it. The tree itself uses the reverse of that order, the natural byte order of the hash.

Position	Transaction	Value used in the witness merkle tree
0	coinbase 2d4cdcd2…	32 zero bytes
1	d367b86c…	wTXID 8700d546…
2	76d11f7e…	wTXID c54bab59…
3	e51de361…	its TXID, because it is legacy

Hashing the witness merkle root with the reserved value gives this commitment:

6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715

The coinbase transaction's second output holds it, in this form:

OP_RETURN  OP_PUSHBYTES_36  aa21a9ed  6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715

The aa21a9ed header marks the output as a witness commitment, and the last 32 bytes hold the commitment. We rebuilt the root from the four transactions in this block, and the commitment matched the coinbase output.

Because the commitment covers every witness in the block, changing a signature anywhere in the block breaks it. Such a block is invalid.

Why is the TXID still used to look up transactions?

A TXID hashes what a transaction does: the coins it spends and the outputs it creates. The witness only proves that the spend was authorized. Signatures can change without changing that effect, so the TXID stays stable where the wTXID would not.

For that reason, search engines, wallets and explorers use the TXID. Our explorer looks up /tx/<txid>, and the wTXID never needs to be typed in.

Why do two IDs exist at all?

Before SegWit, one ID was enough, and the TXID changed when a signature changed. SegWit moved the signatures out of the TXID's scope, which fixed that problem. The wTXID then exists so the witness data still belongs to the block, through the commitment.

Once a transaction confirms, its outputs wait in the UTXO set until something spends them. The UTXO page explains how nodes track them.

Sources

• BIP 141: Segregated Witness defines the wTXID, the witness merkle root and the commitment.
• BIP 141, commitment structure describes the output and the header.