Return to Answer

Calculating TxID

1. convert data into Bitcoin's pre-segwit network serialisation. Taking care not to make any of the most common mistakes:

   • Encode counts/lengths using the Bitcoin variable-length Compact-Integer format (sometimes called VarInt) and
   • Take into account Bitcoin's inconsistent and non-standard use of Endianness (byte order).
   • Never convert to, or use, hexadecimal string representations (until you have a final TxId result that you want to present that way). Because f("B5") ≠ f(0xB5)

2. Calculate SHA256(SHA256(serialised-data)).

A note about Segregated Witness (Segwit)

When Segwit was introduced, it was designed to be backwards compatible with pre-Segwit nodes. So, when sending data to nodes that don't signal Segwit support, Segwit nodes send them data in the pre-Segwit network serialisation, not the Segwit serialisation used for sending data to Segwit nodes. To ensure that both Segwit and pre-Segwit nodes use the same TxID, the pre-Segwit serialisation was used to calculate the TxID even for Segwit transactions. This is what is always used in transaction input references. This makes sure that both Segwit and pre-Segwit nodes maintain the same view of Bitcoin network state, the same view of the UTXO set.

There is a separate WTxID based on a hash of the Segwit serialisation. As BIP 141 says:

Transaction ID

A new data structure, witness, is defined. Each transaction will have 2 IDs.

Definition of txid remains unchanged: the double SHA256 of the traditional serialization format:

Calculating TxID

1. convert data into Bitcoin's pre-segwit network serialisation. Taking care not to make any of the most common mistakes:

   • Encode counts/lengths using the Bitcoin variable-length Compact-Integer format (sometimes called VarInt) and
   • Take into account Bitcoin's inconsistent and non-standard use of Endianness (byte order).
   • Never convert to, or use, hexadecimal string representations (until you have a final TxId result that you want to present that way). Because f("B5") ≠ f(0xB5)

2. Calculate SHA256(SHA256(serialised-data)).

Example program

TxID  88877248B629DA0DF5A8E31FD0D1FBECAFE48A3D1FC65EAFF141DDD9BDB3361A

A note about Segregated Witness (Segwit)

When Segwit was introduced, it was designed to be backwards compatible with pre-Segwit nodes. So, when sending data to nodes that don't signal Segwit support, Segwit nodes send them data in the pre-Segwit network serialisation, not the Segwit serialisation used for sending data to Segwit nodes. To ensure that both Segwit and pre-Segwit nodes use the same TxID, the pre-Segwit serialisation was used to calculate the TxID even for Segwit transactions. This is what is always used in transaction input references. This makes sure that both Segwit and pre-Segwit nodes maintain the same view of Bitcoin network state, the same view of the UTXO set.

There is a separate WTxID based on a hash of the Segwit serialisation. As BIP 141 says:

Transaction ID

A new data structure, witness, is defined. Each transaction will have 2 IDs.

Definition of txid remains unchanged: the double SHA256 of the traditional serialization format:

Calculating TxID

1. convert data into Bitcoin's pre-segwit network serialisation. Taking care not to make any of the most common mistakes:

   • Encode counts/lengths using the Bitcoin variable-length Compact-Integer format (sometimes called VarInt) and
   • Take into account Bitcoin's inconsistent and non-standard use of Endianness (byte order).
   • Never convert to, or use, hexadecimal string representations (until you have a final TxId result that you want to present that way). Because f("B5") ≠ f(0xB5)

2. Calculate SHA256(SHA256(serialised-data)).

A note about Segregated Witness (Segwit)

When Segwit was introduced, it was designed to be backwards compatible with pre-Segwit nodes. So, when sending data to nodes that don't signal Segwit support, Segwit nodes send them data in the pre-Segwit network serialisation, not the Segwit serialisation used for sending data to Segwit nodes. To ensure that both Segwit and pre-Segwit nodes use the same TxID, the pre-Segwit serialisation was used to calculate the TxID even for Segwit transactions. This is what is always used in transaction input references. This makes sure that both Segwit and pre-Segwit nodes maintain the same view of Bitcoin network state, the same view of the UTXO set.

There is a separate WTxID based on a hash of the Segwit serialisation.

Calculating TxID

1. convert data into Bitcoin's pre-segwit network serialisation. Taking care not to make any of the most common mistakes:

   • Encode counts/lengths using the Bitcoin variable-length Compact-Integer format (sometimes called VarInt) and
   • Take into account Bitcoin's inconsistent and non-standard use of Endianness (byte order).
   • Never convert to, or use, hexadecimal string representations (until you have a final TxId result that you want to present that way). Because f("B5") ≠ f(0xB5)

2. Calculate SHA256(SHA256(serialised-data)).

A note about Segregated Witness (Segwit)

When Segwit was introduced, it was designed to be backwards compatible with pre-Segwit nodes. So, when sending data to nodes that don't signal Segwit support, Segwit nodes send them data in the pre-Segwit network serialisation, not the Segwit serialisation used for sending data to Segwit nodes. To ensure that both Segwit and pre-Segwit nodes use the same TxID, the pre-Segwit serialisation was used to calculate the TxID even for Segwit transactions. This is what is always used in transaction input references. This makes sure that both Segwit and pre-Segwit nodes maintain the same view of Bitcoin network state, the same view of the UTXO set.

There is a separate WTxID based on a hash of the Segwit serialisation. As BIP 141 says:

Transaction ID

A new data structure, witness, is defined. Each transaction will have 2 IDs.

Definition of txid remains unchanged: the double SHA256 of the traditional serialization format:

1. convert data into Bitcoin's pre-segwit network serialisation. Taking care not to make any of the most common mistakes:

   • Encode counts/lengths using the Bitcoin variable-length Compact-Integer format (sometimes called VarInt) and
   • Take into account Bitcoin's inconsistent and non-standard use of Endianness (byte order).
   • Never convert to, or use, hexadecimal string representations (until you have a final TxId result that you want to present that way). Because f("B5") ≠ f(0xB5)

2. Calculate SHA256(SHA256(serialised-data)).

Calculating TxID

1. convert data into Bitcoin's pre-segwit network serialisation. Taking care not to make any of the most common mistakes:

   • Encode counts/lengths using the Bitcoin variable-length Compact-Integer format (sometimes called VarInt) and
   • Take into account Bitcoin's inconsistent and non-standard use of Endianness (byte order).
   • Never convert to, or use, hexadecimal string representations (until you have a final TxId result that you want to present that way). Because f("B5") ≠ f(0xB5)

2. Calculate SHA256(SHA256(serialised-data)).

A note about Segregated Witness (Segwit)

When Segwit was introduced, it was designed to be backwards compatible with pre-Segwit nodes. So, when sending data to nodes that don't signal Segwit support, Segwit nodes send them data in the pre-Segwit network serialisation, not the Segwit serialisation used for sending data to Segwit nodes. To ensure that both Segwit and pre-Segwit nodes use the same TxID, the pre-Segwit serialisation was used to calculate the TxID even for Segwit transactions. This is what is always used in transaction input references. This makes sure that both Segwit and pre-Segwit nodes maintain the same view of Bitcoin network state, the same view of the UTXO set.

There is a separate WTxID based on a hash of the Segwit serialisation.