Transaction ID (txid)

What Is a Transaction ID (txid)?

A transaction ID, or txid, is a 256-bit hash that uniquely identifies a Bitcoin transaction. Every transaction broadcast to the Bitcoin network receives a txid computed by hashing its serialized data with the double SHA-256 algorithm (SHA-256 applied twice). The result is displayed as a 64-character hexadecimal string.

The txid serves as a transaction's fingerprint. Block explorers use it to look up transaction details. Wallets use it to track payment confirmations. And most fundamentally, every transaction input references a previous output by its txid, forming the chain of ownership that defines Bitcoin's UTXO model. For a complete walkthrough of how transactions move from creation to confirmation, see the Bitcoin transaction lifecycle guide.

How It Works

Computing a txid involves serializing the transaction into bytes, then hashing that data. The exact fields included in the hash depend on whether the transaction uses SegWit.

Serialization and Hashing

For all transactions, the txid is computed from these serialized fields in order:

1. nVersion (4 bytes): the transaction version number, currently 1 or 2
2. Input count and inputs: each input contains a previous txid, output index, scriptSig, and sequence number
3. Output count and outputs: each output contains a value in satoshis and a scriptPubKey
4. nLockTime (4 bytes): the earliest time or block height at which the transaction can be mined

The double SHA-256 hash of this serialized data produces the txid:

txid = SHA256(SHA256(nVersion || txins || txouts || nLockTime))

Satoshi chose double SHA-256 to protect against length-extension attacks, a class of vulnerability that affects single-pass SHA-256 when used with secret prefixes.

Byte Order Convention

Bitcoin has an unusual byte order convention for displaying hashes. The raw output of the SHA-256 function is in little-endian (natural) byte order, but txids are displayed with the bytes reversed into big-endian order.

For example, the first Bitcoin payment from Satoshi to Hal Finney (block 170) has a txid that looks completely different in internal versus display format:

# Internal (natural) byte order — used in raw transaction data
169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4

# Display (reversed) byte order — used in explorers, wallets, and RPC
f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

This reversal convention, inherited from how Satoshi displayed block hashes, means developers working with raw transaction data must reverse the byte order when converting between internal references and user-facing displays. Block explorers, wallet interfaces, and RPC commands all use the reversed (display) format.

txid vs wtxid

SegWit (defined in BIP 141) introduced a second transaction identifier: the witness transaction ID, or wtxid. The distinction is straightforward:

• txid: hashes only the non-witness fields (version, inputs, outputs, locktime). The witness data containing signatures and scripts is excluded.
• wtxid: hashes the complete serialized transaction including the SegWit marker byte (0x00), flag byte (0x01), and all witness fields.

For legacy transactions without witness data, the txid and wtxid are identical. For SegWit transactions, they differ because the wtxid includes the additional witness fields.

The txid remains the primary identifier for looking up transactions and referencing outputs. The wtxid is used in the block's witness commitment: a Merkle tree of all wtxids is computed and embedded in the coinbase transaction. BIP 339 also introduced wtxid-based transaction relay between nodes, preventing bandwidth waste from witness data manipulation.

Transaction Malleability

Before SegWit, txids had a critical flaw: they could be changed without invalidating the transaction. This problem, known as transaction malleability, arose because the txid hash included the scriptSig, which contains signatures that do not sign themselves.

How Malleability Worked

Multiple attack vectors allowed third parties to modify a valid transaction's txid:

• ECDSA signature flexibility: for every valid signature (r, s), the value (r, -s mod N) is also valid for the same message. Flipping the s-value changed the scriptSig and therefore the txid.
• Encoding variations: early Bitcoin used OpenSSL, which accepted multiple DER encodings for the same signature. Different but equivalent encodings produced different txids. BIP 66 later mandated strict DER encoding to close this vector.
• Extra scriptSig data: additional opcodes or data pushes could be inserted into the scriptSig without invalidating the signature, altering the txid.

Mt. Gox cited transaction malleability as a contributing factor in its 2014 collapse, claiming that attackers modified txids of withdrawal transactions to make them appear as though they had failed, prompting duplicate withdrawals. Subsequent research by ETH Zurich estimated the actual losses attributable to malleability attacks were far smaller than claimed: approximately 386 BTC rather than the hundreds of thousands initially alleged.

How SegWit Fixed It

SegWit moved all signature and witness data out of the txid preimage entirely. Since the scriptSig for SegWit inputs is empty (containing only a witness program reference), there is nothing left to malleate. The txid becomes immutable once the transaction's non-witness fields are finalized.

This fix was a prerequisite for the Lightning Network. Lightning channels rely on chains of unconfirmed transactions: commitment transactions reference the funding transaction's output by txid. If the funding txid could change after broadcast, all dependent commitment transactions would become invalid, breaking the channel. SegWit's immutable txids made this architecture safe, enabling HTLCs, payment channels, and Layer 2 systems like Spark.

The fixes came progressively: BIP 66 mandated strict DER signature encoding. BIP 62 attempted a comprehensive malleability fix but was withdrawn as insufficient for payment channel use cases. BIP 141 (SegWit) provided the definitive solution by removing signatures from the txid computation altogether.

Use Cases

Tracking Payments

The most common use of a txid is confirming that a payment has been sent or received. After broadcasting a transaction, the sender can share the txid with the recipient, who looks it up on a block explorer to verify the amount, destination, and confirmation status. Services that accept Bitcoin payments typically display the txid as a receipt and monitor its confirmation count.

Referencing Outputs (Outpoints)

Every transaction input must reference the specific unspent output it is spending. This reference, called an outpoint, consists of the txid of the transaction that created the output plus the output's index (vout):

outpoint = txid:vout

# Example: spending the first output (index 0) of a transaction
f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16:0

This outpoint mechanism is the backbone of Bitcoin's UTXO model. Every satoshi on the network can be traced through a chain of outpoints back to the coinbase transaction that created it. For a comparison with alternative models, see the UTXO vs account model analysis.

Block Merkle Trees

The txids of all transactions in a block serve as the leaves of a Merkle tree. The root of this tree is stored in the block header as the hashMerkleRoot. This structure enables lightweight clients to verify that a transaction is included in a block without downloading the entire block: they only need the Merkle proof (a logarithmic number of hashes) and the block header.

Fee Bumping

Both replace-by-fee (RBF) and child-pays-for-parent (CPFP) rely on txids. RBF replaces an unconfirmed transaction (producing a new txid), while CPFP creates a child transaction that spends an output of the parent txid with a higher fee, incentivizing miners to confirm both. For more on how fees interact with confirmation priority, see the Bitcoin fee market dynamics guide.

Partially Signed Bitcoin Transactions

PSBTs (BIP 174) use txids extensively when constructing multi-party transactions. Each input in a PSBT references the previous output by txid, and signers can independently verify the transaction they are signing by recomputing the expected txid from the provided unsigned transaction data.

Why It Matters

Txids are not just identifiers: they are a structural pillar of Bitcoin. The reliability of txids determines whether unconfirmed transaction chains are safe, whether Layer 2 protocols can function, and whether users can trust that a payment reference will remain stable after broadcast.

SegWit's fix to transaction malleability transformed txids from potentially mutable identifiers into deterministic ones, unlocking an entire generation of protocols built on pre-signed transaction chains. HTLCs, Lightning channels, and Layer 2 systems like Spark all depend on the guarantee that a txid will not change once a transaction is constructed. Without this guarantee, pre-signed transactions referencing future outputs would be fundamentally unreliable.

Risks and Considerations

Legacy Transaction Malleability

While SegWit fixed malleability for transactions spending SegWit outputs, legacy (non-SegWit) transactions remain malleable. Any system that relies on unconfirmed legacy txids can still be affected. Modern wallets default to SegWit address types (P2WPKH or Taproot), but legacy transactions are still valid on the network.

Unconfirmed Txids Are Not Final

A txid exists as soon as a transaction is constructed, even before it is broadcast or confirmed. Until confirmation, the transaction may be replaced via RBF, dropped from mempools, or (for legacy transactions) malleated. Services that treat unconfirmed txids as final risk accepting payments that never settle. For strategies around accepting unconfirmed transactions, see the zero-conf Bitcoin payments guide.

Privacy Implications

Txids are public and permanent. Anyone with a txid can look up the full transaction details: inputs, outputs, amounts, and addresses. Sharing a txid with a counterparty reveals the complete transaction graph connected to that payment. Users concerned with privacy should be cautious about sharing txids outside of necessary payment verification contexts.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.