wTXID

A wTXID is like a TXID, but a wTXID includes the witness data of a transaction.

For example:

A wTXID is the HASH256 of all of the transaction data, including the marker, flag, and witness:

Whereas a TXID is the HASH256 of all of the transaction data except the marker, flag, and witness:

The diagrams above do not show the marker and flag fields.

Examples

How do you create a wTXID?

From a technical perspective, a wTXID is calculated by hashing the following fields of a serialized raw transaction:

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

Segwit Transaction

Here's the raw transaction data for a segwit transaction. I've highlighted the new segwit fields:

01000000000101438afdb24e414d54cc4a17a95f3d40be90d23dfeeb07a48e9e782178efddd8890100000000fdffffff020db9a60000000000160014b549d227c9edd758288112fe3573c1f85240166880a81201000000001976a914ae28f233464e6da03c052155119a413d13f3380188ac024730440220200254b765f25126334b8de16ee4badf57315c047243942340c16cffd9b11196022074a9476633f093f229456ad904a9d97e26c271fc4f01d0501dec008e4aae71c2012102c37a3c5b21a5991d3d7b1e203be195be07104a1a19e5c2ed82329a56b431213000000000

The TXID is the HASH256 of all of the transaction data except the marker, flag, and witness:

The wTXID is then just the HASH256 of all of the transaction data including the marker, flag, and witness:

You can check this for yourself by putting the data through HASH256 manually:

Byte Order. Don't forget that TXIDs and wTXIDs are displayed in reverse byte order, so the initial result of the HASH256 will be in natural byte order (which means that the result looks backwards at first).

Legacy Transaction

A non-segwit transaction will have the same TXID and wTXID.

For example, here's the raw transaction data for a legacy transaction:

0100000001ba1e48633efb7397536c3b45582cb763b1903b1364865f6de0f53387d306c87d010000006b483045022100df50e78ee42725165eceed6e6e1c534936015d3ef9e410d301de682a3655012f02203d21199bc19d982926fcf6bfe26773f4a0b2befdabb742542469f04e739764cb012103668b0f35effa223f001fb1c39d61bde513d5c6291b84227e84fd3e7daf0e3a6afeffffff02ce6d6002000000001976a9144ccb1bfd0099bf5ba2e2799a9f444f9583a74ce088ac35102408000000001976a914e5555373c7d95bb6a2cfcf7e9ffb3fcb5a305ba988ac711a0600

This is the TXID:

And seeing as a legacy transaction does not include a marker, flag, or witness, it will have the same wTXID:

You can find the wTXID of a transaction by running bitcoin-cli getrawtransaction <txid> 1. The wTXID will be equal to the "hash" field, as this "hash" is the HASH256 of the entire transaction data (in reverse byte order), which is currently equal to the wTXID.

wTXID Commitment

Committing transaction witness data to the block

wTXIDs are used to commit the new data in segwit transactions to the block via a witness root hash.

For example, all of the legacy transaction data is committed to the block header by creating a merkle root of all the TXIDs in the block.

However, the TXIDs do not include the marker, flag, and witness data. So for all blocks since the Segregated Witness upgrade, we also create a merkle root for all of the wTXIDs, and commit that to the block by creating a witness root hash.

This witness root hash gets HASH256'd with the witness reserved value to create a wTXID commitment. This gets placed inside the ScriptPubKey of one of the outputs of the coinbase transaction.

So now there is a commitment for all the new segwit transaction data placed inside the block. So if anyone tries to change the contents of the witness data in any of the transactions in the block, it will not match the wTXID commitment and the block will be invalid.

wTXIDs are ultimately used to prevent anyone from editing the new segregated witness transaction data included in the block.

Example

The block at height 553,724 contains the following 4 transactions:

The first three are segwit transactions, so they contain witness data that will not be committed to the block header via their TXIDs alone.

These are the wTXIDs for each of the transactions:

When calculating the witness root hash, the wTXID for the coinbase transaction must be set to all zeros. This is because it's eventually going to contain the commitment inside it, so this avoids a circular reference.

The last transaction is a non-segwit transaction, so its wTXID is the same as its TXID.

If we create a merkle root from all of these wTXIDs we get the witness root hash:

witness root hash: dbee9a868a8caa2a1ddf683af1642a88dfb7ac7ce3ecb5d043586811a41fdbf2

Now if we look inside the input of the coinbase transaction we find the witness reserved value:

witness reserved value: 0000000000000000000000000000000000000000000000000000000000000000

Finally, if we concatenate and HASH256 the witness root hash and witness reserved value, we get the wTXID commitment:

wTXID commitment = HASH256(witness root hash | witness reserved value)
wTXID commitment = 6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715

This wTXID commitment gets placed in the ScriptPubKey of one of the outputs in the coinbase transaction. So if we check the ScriptPubKey of output 1 of the coinbase transaction for this block we find the following script:

You'll see that the wTXID commitment is contained within the last 32 bytes of that data push.

• The first 4 bytes aa21a9ed is just a fixed header used to identify that this output contains the wTXID commitment.
• The next 32 bytes 6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715 is the same wTXID commitment we have just calculated.

All coinbase transactions since the segregated witness upgrade must include this commitment to the witness data. They all have to include an output with this script pattern: starting with OP_RETURN, followed by a OP_PUSHBYTES_36 that contains a 4-byte header followed by the 32-byte wTXID commitment.

The wTXID commitment can be contained inside any of the outputs of the coinbase transaction. If there are multiple outputs with this structure for some reason, the highest output index number that contains this wTXID commitment structure will be taken as the commitment.

Usage

How are wTXIDs used in Bitcoin?

wTXIDs are only used internally in Bitcoin to create a commitment for the new segwit fields of transactions.

So you wouldn't use the wTXID to look up a transaction in the blockchain or anything like that.

You still use the TXID for looking up transactions in the blockchain. A TXID is still a unique identifier of a transaction, as it still hashes the effect of a transaction (moving coins from existing outputs to new outputs), which is always unique to each transaction. The witness data is only important for transaction validation (unlocking the inputs), and this does not make the transaction data any more unique than it already is.

Resources

• BIP 141
• Why include the Segregated Witness Merkle Root in the input field of the coinbase transaction?