Bitcoin txid and wtxid: two identifiers for different serialisations
Segregated Witness distinguishes a traditional transaction identifier from a witness-inclusive identifier. A reconciliation system must know which one it is comparing.
Full analysis is selected. Choose Quick brief to scan the key points first.
WFN QUICK BRIEF · UNDER 1 MIN
The short version
MODE 2 OF 2
What the primary record establishes
BIP-141 keeps txid as the double-SHA256 hash of the traditional transaction serialisation. It defines wtxid using the serialisation that also includes witness data. The specification therefore gives different meanings to two similarly shaped identifiers. Bitcoin BIPs — BIP-141 Segregated Witness ↗
What the distinction changes
A support desk receiving one identifier from a wallet and another from an infrastructure log should first establish the field type. An unequal string comparison is not enough to conclude that a payment was duplicated, replaced or sent to another recipient.
What to check before drawing a conclusion
Keep field names explicit in APIs, exports and incident reports. Preserve the raw transaction where appropriate and verify it with a node or documented decoder. Do not silently truncate, rename or treat every 64-character hexadecimal value as an interchangeable payment reference.
Quick Brief is a reading aid. The full article and source trail stay on this page.
WFN STORY COMPASS
Choose your reading angle
Move between the reported record, market context and open questions. Status labels keep claims distinct from findings.
All context layers are visible. Choose a lens to jump to that part of the story.
AI-generated editorial illustrationWFN · 16 October 2026
Editorial noteSource-based explanation with original WFN analysis. Historical records retain their dates; numerical examples are illustrative. The AI-generated conceptual illustration is not documentary evidence.
WFN REALITY LEDGER
What is on the record?
Primary-source explainer
Primary-source explainer
Primary record / reference periodBIP-141 consensus specification; checked 16 October 2026
The linked source supports the documented record; WFN interpretation and illustrative examples are separate.
Segregated Witness distinguishes a traditional transaction identifier from a witness-inclusive identifier. A reconciliation system must know which one it is comparing.
01 · VERIFIED RECORD
What the primary record establishes
BIP-141 keeps txid as the double-SHA256 hash of the traditional transaction serialisation. It defines wtxid using the serialisation that also includes witness data. The specification therefore gives different meanings to two similarly shaped identifiers. Bitcoin BIPs — BIP-141 Segregated Witness ↗
For a transaction without witness data, wtxid equals txid. For witness transactions they can differ, while referring to the same transaction effects. BIP-141 also specifies a witness commitment in blocks; this is separate from the traditional transaction Merkle root. Bitcoin BIPs — BIP-141 Segregated Witness ↗
02 · WFN EDITORIAL ANALYSIS
What the distinction changes
A support desk receiving one identifier from a wallet and another from an infrastructure log should first establish the field type. An unequal string comparison is not enough to conclude that a payment was duplicated, replaced or sent to another recipient.
Conversely, a hash match alone does not establish confirmations, ownership of an output or a service’s crediting policy. Identifier reconciliation and payment acceptance are related operational tasks, but they require different evidence and may use different databases.
03 · REVIEW POINTS
What to check before drawing a conclusion
Keep field names explicit in APIs, exports and incident reports. Preserve the raw transaction where appropriate and verify it with a node or documented decoder. Do not silently truncate, rename or treat every 64-character hexadecimal value as an interchangeable payment reference.
When investigating a discrepancy, compare outputs, network, block inclusion and the service’s deposit records after identifying the serialisation. WFN explains the standard’s data model; it makes no claim about the finality of a particular transfer.
