A Litecoin transaction can have a traditional transaction identifier, txid, and a witness identifier, wtxid. They are two views of transaction data, not two separate payments. Knowing either identifier also does not prove broadcast, valid signatures, confirmation or recipient credit.
This guide focuses on ordinary transparent SegWit transactions in Litecoin Core 0.21.5.8. It reuses a published regtest archive and adds offline hash calculations. It does not broadcast altered transactions or apply the ordinary serialization recipe to MWEB-only transactions.
What each identifier commits to
For the ordinary transparent case, txid is the double SHA-256 hash of the traditional serialization: version, inputs, outputs and locktime. Witness data is omitted. The wtxid includes the witness serialization, including its marker, flag and witness stacks. Human-readable hexadecimal identifiers conventionally display the resulting hash bytes in reversed order.
The SegWit specification defines the two identifiers. Litecoin's versioned implementation shows its corresponding hash paths. If a transaction has no witness, its witness hash equals its traditional hash under this ordinary path.
| Item | What it identifies | Common confusion |
|---|---|---|
| txid | Transaction under its traditional hash path | Not a receipt from the network |
| wtxid | Transaction including witness data | Not a second independent payment |
| txid plus output index | A specific transparent outpoint | A transaction can contain several recipients and change |
| Block hash | A particular block header | Not the transaction ID or proof of service credit |
This hashing is separate from Scrypt mining. A transaction's txid is not the miner's Scrypt proof-of-work result, and changing a transaction is not the same operation as trying a block-header nonce. The Scrypt guide describes those work inputs.
Why Core can return both txid and hash
The pinned transaction JSON writer labels the traditional identifier txid and the witness hash hash. For an ordinary SegWit transaction these fields can legitimately differ. A user comparing a block explorer's transaction ID with the wrong JSON field can therefore see a mismatch without there being two payments.
Use your exact wallet or node version's help. One read-only example is:
litecoin-cli help decoderawtransaction
litecoin-cli decoderawtransaction "<raw-transaction-hex>"Decoding parses the serialized data and describes its fields. It does not establish that referenced outputs exist, signatures satisfy their conditions, fees meet current policy or the transaction entered a block. A valid-looking JSON object is not an execution receipt.
For a known wallet transaction, gettransaction can supply wallet context. For other transactions, getrawtransaction has availability requirements: mempool knowledge, an available specified block or an enabled transaction index as applicable. Its RPC implementation states those conditions. Failure to retrieve one transaction is not proof that it never existed.
An offline example with one preserved transaction
Our original September 2026 signed-candidate archive contains 164 local regtest policy checks. Those payment candidates were not broadcast or mined. The new script independently recomputes all 164 recorded txids and weights before selecting its first ordinary SegWit candidate for demonstration.
The selected original has 222 serialized bytes, 113 base bytes, weight 561 and virtual size 141. Its txid begins ca26832440e8…; its calculated wtxid begins 28348f7d0610…. These shortened prefixes are explanatory labels, not complete lookup identifiers. Full results and the procedure are downloadable below.
| Case | txid result | wtxid result |
|---|---|---|
| Archived original | ca26832440e8… | 28348f7d0610… |
| One witness byte changed | Same as original | Changes to 0e48b206e8bd… |
| One output-value byte changed | Changes to 65829f599ca5… | Changes to 2d87528b251a… |
The witness-only alteration leaves the traditional serialization unchanged. The output alteration changes data included in both hash paths. All three variants have the same byte counts in this particular demonstration; byte count alone cannot identify transaction contents.
Crucially, recomputing a hash does not validate a signature. The changed witness and output cases are unvalidated byte strings, not demonstrated alternate valid spends. The exercise shows what the identifiers cover, not a technique to change somebody else's authorized payment.
What SegWit does and does not stabilize
Separating witness data from txid addresses important forms of unintentional malleability for eligible transactions. It does not freeze every possible transaction constructed from the same funds. Changing a covered output, input, sequence or locktime normally changes the traditional identifier as well.
An authorized replacement is a different topic from an outsider changing an existing signature representation. A fee bump can alter outputs or other covered transaction data and produce a new txid. Support for creating and relaying replacements depends on the wallet, transaction and node policy. See the replacement and cancellation guide.
Also avoid applying the witness-only example to every possible input script. Traditional scriptSig data remains in the txid serialization. Mixed input types and signature modes need their actual rules analyzed. “SegWit fixed all malleability” is too broad.
An ID is a reference, not proof that you were paid
A sender can compute an identifier before broadcasting. A screenshot can display an identifier for an unrelated transaction. Even a real confirmed transaction can pay several destinations, or a different amount from the invoice. Identify the intended output and verify its chain and current status.
- Confirm the actual network and full identifier through a source you intend to use.
- Inspect the relevant recipient output, amount and index rather than the transaction's input total.
- Check current active-chain inclusion and depth, or the particular node's unconfirmed state.
- Check the receiver's required confirmations and account or invoice credit separately.
- Before retrying, preserve the first transaction's state so a second payment does not create a duplicate.
The duplicate-payment guide and transaction-state walkthrough explain those distinctions. Two identifiers for one transaction must not be entered as two independent receipts in an accounting ledger.
Why the ordinary recipe stops at MWEB
Litecoin's implementation explicitly handles MWEB-only transactions through a different identifier path involving a kernel hash. Its witness-hash path also excludes MWEB serialization where specified. Therefore “double-hash all bytes I downloaded” is not a universal Litecoin identifier recipe.
The offline parser supplied here deliberately accepts only the ordinary transparent SegWit form used by the archived study. It is not a general Litecoin transaction decoder, a block validator or a tool for interpreting arbitrary MWEB records. Use a compatible current implementation for those structures.
Reproduce the demonstration without wallet secrets
Download the three full identifier cases and offline script. Save the script as a Python file and run it against the original archive:
python transaction-id-checks.py /path/to/batch-results.jsonThe script uses the Python standard library, reads only the specified study file and prints calculations. It makes no network connection or wallet operation. It checks hashes and serialization weights, not cryptographic signature validity or current spendability. The method notes and checksums identify the evidence and downloadable files.
Frequently asked questions
Are txid and wtxid two payments?
No. They are identifiers covering different serialized views of a transaction. Do not count them as separate receipts.
What does Core's hash field mean here?
For the ordinary transparent transaction JSON described here, it is the witness hash. The txid field is the traditional transaction identifier.
Can a witness change leave txid unchanged?
Yes under the ordinary SegWit hash path. That does not establish that the altered witness is a valid signature or spend.
Does decoding prove a transaction is valid?
No. Parsing and calculating identifiers do not check all signatures, input availability, policy, broadcast or inclusion.
Does a fee replacement keep the same txid?
Not generally. Changes to covered transaction data can produce a new identifier. Wallet and relay support for replacement are separate questions.
Does this script handle MWEB-only transactions?
No. It is deliberately limited to the ordinary transparent SegWit serialization in the archived study. MWEB has separate implementation paths.
