Transaction identity: distinguish txid from the witness commitment
A transaction identifier authenticates the bytes included in its hash calculation. For a SegWit serialization, txid and wtxid cover different byte sequences. Preserve that distinction when comparing explorer exports, stored transaction objects or proofs. A shared txid does not establish that two files contain identical witness data.
It also does not establish that either file describes a valid spend. Serialization, identifier calculation, script validity and confirmed economic activity are four separate checks. The worked fixtures below intentionally test only the first two.
Name the serialization before comparing hashes
BIP 141, Transaction ID, defines txid from the traditional serialization and wtxid from the witness serialization. Its Commitment structure section describes the block’s separate witness commitment through the coinbase transaction. A transaction’s ordinary Merkle inclusion path therefore should not be described as directly committing to all witness bytes through its txid.
Keep the exact raw object as well as both identifiers. Record whether a source supplied a stripped serialization or the complete witness serialization. An export omitting witness data may still be useful for identifying outputs; it is inadequate for a task that must inspect the supplied witness.
Do not manufacture missing witness bytes from a readable explorer label. If a purported full object is unavailable, state which checks cannot be completed. A hash is an identifier for candidate bytes, not a way to reconstruct unavailable bytes.
A reproducible byte fixture
Construct a fictional serialization with version 2, one input referring to a repeated placeholder hash, one output and locktime zero. The input’s previous output is not established and the witness is deliberately a one-byte dummy item. This is not an authorized Bitcoin spend, an actual payment or a transaction suitable for broadcasting.
The following Python uses only the standard library. Hex fragments define the bytes, not human-readable monetary values concatenated into a string. The displayed identifier convention reverses the final digest bytes.
import hashlib
def identifier(raw):
first = hashlib.sha256(raw).digest()
return hashlib.sha256(first).digest()[::-1].hex()
version = bytes.fromhex('02000000')
inputs = bytes.fromhex('01' + '11' * 32 + '00000000' + '00' + 'ffffffff')
end = bytes.fromhex('00000000')
def fixture(value, item):
outputs = bytes.fromhex('01') + value.to_bytes(8, 'little')
outputs += bytes.fromhex('16' + '0014' + '22' * 20)
base = version + inputs + outputs + end
full = version + bytes.fromhex('0001') + inputs + outputs
full += bytes.fromhex('0101') + bytes([item]) + end
return len(base), len(full), identifier(base), identifier(full)
for case in [(1000, 1), (1000, 2), (1001, 1)]:
print(fixture(*case))All three base objects have 82 bytes; their full objects have 87. The extra five bytes comprise the marker and flag plus the three-byte dummy witness encoding. The construction is explicit so that a reader can distinguish parser behavior from an assertion about valid signatures.
Interpret the three results
| Fixture | Output value | Dummy witness item | txid prefix | wtxid prefix |
|---|---|---|---|---|
| A | 1000 sat | 01 | b91b72010378 | bb79fcaf4238 |
| B | 1000 sat | 02 | b91b72010378 | 3f1d4dfd0055 |
| C | 1001 sat | 01 | a5e34c11b070 | 676ed39808f6 |
Compare full identifiers when validating the exercise; the prefixes are abbreviated only to keep the table readable. A and B have identical base bytes and therefore identical txid. Changing the dummy witness item changes the witness serialization and its wtxid. C changes the output value, which is present in both serializations, so both identifiers differ in this fixture.
The monetary change from A to C is one satoshi, or 0.00000001 BTC. It is not established as a real transfer because the fixture lacks the evidence required for an actual valid input and spend. The result demonstrates hash coverage, not acceptance by miners or consensus.
Why arbitrary witness changes are not valid alternatives
A real witness must satisfy the spending rules applicable to the previous output and transaction context. Flipping a signature byte can invalidate a spend even while leaving its base serialization unchanged. Thus “same txid, different witness” cannot be translated into “two equally valid payments.”
For research using real data, obtain the previous output’s script and the applicable validation context. Check whether each candidate object was merely received, parsed, accepted by a node, included in a block or subsequently removed from the selected chain. Those statuses supply evidence absent from a file comparison.
Likewise, a change to an output may require new authorization and can conflict with the original input spend. A distinct txid is not a guarantee of a second independent economic event. Inspect the shared outpoints and confirmed outcome before adding values.
Boundary case: an export strips the witness
Suppose an archive stores the base serialization while a second source returns a full object. Their raw file hashes differ because the files differ, yet the correctly computed txid can identify the same base transaction. That is not automatically an inconsistency.
Do not compute a purported wtxid from the stripped bytes and label it verified. Mark witness coverage unavailable unless the required serialization is obtained. For transactions without witness inputs, BIP 141 describes circumstances in which wtxid equals txid; that special case should be established from the object rather than used to excuse missing material.
Verification and release table
| Check | Preserve | Error caught |
|---|---|---|
| Parse the candidate | Raw bytes and parser version | Truncation or unsupported encoding |
| Separate serializations | Base and complete byte sequences | Hashing an export wrapper or stripped object by mistake |
| Recompute identifiers | Full txid and wtxid with display convention | Wrong coverage or byte order |
| Assess validity | Previous output and applicable rules | Treating a dummy or altered witness as authorized |
| Assess settlement | Block identity and selected-chain status | Calling an unconfirmed candidate a settled payment |
| Count activity | Input relationships and output semantics | Adding alternative candidates as independent receipts |
Reopen the record when complete bytes become available, an identifier is corrected or chain status changes. Preserve the earlier file with its coverage label. The final statement should say which bytes were compared, which identifier matched and which validity or settlement evidence was actually inspected.
FAQ
Can two different files share a txid?
Yes, when their differences lie outside the base serialization used for txid, as the dummy witness fixtures demonstrate. The files still need separate validity checks.
Does changing witness data always create another valid transaction?
No. A changed witness may fail the applicable rules. Identifier calculation does not validate the spend.