TXID

A TXID is the transaction ID: a 32-byte hash that names one transaction. It is made by hashing the transaction's bytes twice with SHA-256. Inputs use it to point at the earlier transaction that created the output they spend, and explorers use it to look transactions up. Nothing in the characters describes the transaction. They are unique because they come from the data.

For a legacy transaction, the TXID hashes every byte. For a segwit transaction, it leaves out the marker, the flag and the witness, so the signatures do not change the ID.

What is a TXID used for?

Three things rely on the TXID.

First, it names a transaction. Paste one into an explorer and you see that transaction's inputs, outputs and confirmations. Our explorer shows every transaction this way. You can also ask your own node. bitcoin-cli getrawtransaction takes a TXID. Unless the node keeps a full transaction index (txindex=1 in bitcoin.conf), it only finds transactions in the mempool or in your wallet.

Second, an input refers to an output by TXID and VOUT. The pair is called an outpoint, and it is what makes each output unique on the chain.

Third, the TXIDs in a block are hashed together into the merkle root in the block header. Change one transaction and its TXID changes, which changes the merkle root and the block hash.

How is a TXID created?

A TXID is the HASH256 of the transaction's bytes, which means SHA-256 applied twice. The result is 32 bytes. Those bytes are in natural order, which is the order they are stored in the raw data. Explorers reverse them before showing the result. The full steps are:

1. Serialize the transaction as raw bytes.
2. For a legacy transaction, use all of them. For a segwit transaction, drop the marker, the flag and the witness.
3. Hash the bytes with SHA-256, then hash that result with SHA-256 again.
4. Reverse the 32 bytes. The result is the TXID that explorers show.

This Python function does steps 3 and 4. Pass it the bytes from step 2 as a hex string:

import hashlib

def txid(raw_hex):
    raw = bytes.fromhex(raw_hex)
    once = hashlib.sha256(raw).digest()
    twice = hashlib.sha256(once).digest()
    return twice[::-1].hex()

The bytes.fromhex line converts the hex into bytes first. Hashing the hex text instead gives a different and wrong result. The last line reverses the bytes into the explorer form.

Why are the bytes reversed?

The hash comes out in one byte order, and explorers and most tools show the reversed form by long-standing convention. The byte order page covers the two forms. You only need to remember this: when you copy a TXID from an explorer into raw data, such as an input's TXID field, reverse it first. When you copy one from raw data into an explorer, reverse it the other way.

For example, the 2009 payment to Hal Finney is f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 on an explorer. Inside its raw data, the same hash appears as 169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4. Run the function above on that transaction's full raw hex and you get the explorer form.

What is a segwit TXID?

Segwit moved the signatures into the witness, and a TXID that hashed the witness would change whenever a signature changed. Signatures can be altered without changing what the transaction does, so a TXID that depended on them could be changed after broadcast. Segwit fixed this by leaving the witness out of the TXID.

Take the segwit transaction that starts 020000000001013a53de6e…. Its TXID is 6cd9ff242a04dbb6b0683c2b8576c397f341b7f0c1747b206f878db597a4cd01 when reversed. That is the hash of the 82 non-witness bytes, not of the 191 bytes in full. The wTXID is the hash that includes the witness.

Can two transactions have the same TXID?

Almost never, but there are two known cases on the chain. Both are coinbase transactions from November 2010. The coinbase input has a fixed TXID and VOUT, and early miners could reuse the same output script and reward. The duplicated transactions are e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468 and d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599, each mined in more than one block.

Because they are the same transaction in two blocks, the duplicate is not a hash collision. It did cause a problem. Outputs are named by TXID and VOUT, so a later spend cannot tell the two copies apart. Only the most recent copy's outputs can be spent, and the 50 BTC outputs of each earlier copy are out of reach.

BIP 30 stopped new duplicates from being created, and BIP 34 made each coinbase unique by putting the block height in it. Software that stores transactions in a database should allow for these two historic cases.

The next page, VOUT, covers the other half of the outpoint: the index of the output inside the transaction.

Sources

• Bitcoin white paper, section 2 on transactions
• BIP 141: Segregated Witness, for what the segwit TXID leaves out
• BIP 30 and BIP 34, for the duplicate coinbase fixes