TXID

A txid is a transaction’s name: a 32-byte hash of its contents. Change one byte of the transaction and the name changes completely.

Pearl computes it exactly as Bitcoin does. Strip the witness, hash the rest twice with SHA-256, and show the result backwards. A second name, the wtxid, hashes everything including the witness. Here are both, worked out for a real payment.

Try it

SHA256d is just SHA-256, applied to its own output. Try it on any input.

How is a txid computed?

Take this real payment from block 130,825:

1. Strip the witness

   Remove the marker and flag (00 01) and the witness (01 40 4686c701…a86ba2). What’s left is version, inputs, outputs and locktime: 137 of the 205 bytes.

2. Hash once

   SHA-256 of those 137 bytes: ab06ab7ff1c853149284c345b20af8a71e5bd69f0ff6aff81abfe5d7d01eb328.

3. Hash again

   SHA-256 of that 32-byte result: c984b3c142eccd72e50f7ba61f1b4ed2ddf00388d931efce39d7df4a2ae019d9. This is the txid in internal byte order.

4. Reverse for display

   Read the 32 bytes backwards: d919e02a4adfd739ceef31d98803f0ddd24e1b1fa67b0fe572cdec42c1b384c9. That’s the txid explorers show.

The 137 stripped bytes, for checking at home:

01000000 01 5939557091bae792be66f26cbd83fc78f16a690a854109e8a1d115e253812133 ab020000 00 ffffffff
02 b0359f1100000000 22 5120d7ab02c96a342bdddb5d07b9f3ebd6c04e077ff41418110b9a1e5997439416b2
   00c2eb0b00000000 22 512062e9da3682aab288392cf7218bafc36287288abb3ce200c5d1a50aa234073b2b
00000000

(Spaces and line breaks added for reading; hash the bytes without them.)

Why is it shown backwards?

Habit, inherited from Bitcoin. Early Bitcoin code treated a hash as one huge little-endian number and printed it biggest digit first, which reverses the bytes. Every Bitcoin-derived chain kept the convention, Pearl included.

So there are two orders, and both are in use:

You can see it in the payment itself: its input spends a transaction shown everywhere as 33218153…70553959, but the bytes in the input are 59395570…53812133. Same 32 bytes, opposite order. The byte order page has more.

What is the wtxid?

The same recipe applied to the whole transaction, marker, flag and witness included:

A transaction with no witness has wtxid = txid. Pearl’s genesis coinbase, serialized the old way with no witness, has both equal to 302f59c6f1239648bd38eddf16b22acc8c8df3c96de2e4f552bd2f38371675c1. Since it’s the only transaction in block 0, that’s also the genesis block’s Merkle root.

Why leave the witness out of the txid?

To make the name unforgeable after the fact. Before segwit, a third party could re-encode a signature in an equivalent form, which changed the txid without invalidating the transaction. Any unconfirmed transaction that spent its outputs, referring to it by the old txid, was suddenly pointing at nothing.

With the witness excluded, the txid is fixed before anyone signs. You can build and sign a chain of transactions that spend each other’s outputs, knowing their names won’t change. The wtxid still changes if the witness does; it’s used where the witness itself must be committed to.

What goes wrong when you compute one?

Four mistakes cover almost every “my txid doesn’t match” puzzle:

• Hashing the hex text. The characters 01000000… are not the bytes 01 00 00 00…. Decode first.
• Forgetting to strip the witness. Hash all 205 bytes and you get the wtxid, 1e7d5c18…, not the txid.
• Hashing once. A single SHA-256 gives ab06ab7f…. The txid needs a second pass.
• Mixing the two orders. An outpoint written with the display-order txid points at a transaction that doesn’t exist. Inside the bytes, always use internal order.

Where are txids and wtxids used?

• Outpoints. Every input names the output it spends by txid (internal order) and index.
• The block’s Merkle root. The header commits to all txids in the block through a Merkle tree.
• The witness commitment. A second Merkle tree over all wtxids, with the coinbase’s wtxid replaced by 32 zero bytes, is committed in the coinbase. See coinbase.

import { sha256 } from '@noble/hashes/sha2.js';
import { hexToBytes, bytesToHex } from '@noble/hashes/utils.js';

const stripped = hexToBytes('01000000015939…00000000');   // the 137 bytes above, no spaces
const internal = sha256(sha256(stripped));
const txid = bytesToHex(internal.reverse());              // d919e02a…c1b384c9