Bitcoin txid vs wtxid: Which Hash Should You Give Support?

For a normal Bitcoin payment lookup or support request, start with the field explicitly labelled txid in the sending wallet. A witness transaction can also have a different wtxid, which includes witness data in its hash calculation. Those two identifiers can describe one transaction rather than two payments. Preserve their labels instead of sending an unlabelled hash and hoping the receiving tool interprets it correctly.

Two identifiers arise from two serialized views

BIP141 defines txid using the traditional transaction serialization and wtxid using the serialization that includes witness. For an ordinary transaction with no witness inputs, the identifiers are equal. When witness is present, they generally differ. This distinction concerns the data being hashed, not a second transfer of your coins.

Avoid the shorthand that txid removes every possible signature. Traditional input data is still part of its serialization, and mixed input arrangements make that shortcut misleading. You do not need to reconstruct those bytes to contact support. You do need to retain the source field names so a developer or explorer knows which identifier it received.

Two different long strings are not automatically a txid/wtxid pair, either. A replacement transaction or another unrelated payment also has an identifier. Establish that both fields came from the same decoded transaction record before interpreting their difference as normal witness behavior. Similar timestamps, equal amounts or the same address are not sufficient by themselves.

Match the label to the job

For a concrete versioned example, Bitcoin Core 30.0's decoderawtransaction documentation returns both txid and hash and explains the witness distinction. A label called hash is therefore not always synonymous with txid. This is a schema example, not a claim that every wallet or the latest Core release displays identical fields.

A failed lookup may be an interface mismatch

If an explorer does not find the supplied wtxid, copy the txid from the original wallet record and try the appropriate Bitcoin network. Some services expose only a transaction-ID lookup; others may support additional search forms. Do not assume universal explorer support or reverse characters in the hash to make it look different.

The getrawtransaction reference also describes the scope of a node's lookup. Availability can depend on mempool data, an index or a specified block. Failure at one node is not proof that the transaction never existed. A wallet-specific record can likewise be absent from a different wallet that has no relevant history.

For wallet-owned records, Core's gettransaction reference explicitly describes an in-wallet transaction. Asking a random node for that view is a different operation from asking your own wallet. Keep these scopes separate when reporting a not-found error: the identifier type, network, method and data coverage each matter.

Do not convert one identifier by changing its text

There is no general text replacement that turns a txid into its witness-inclusive counterpart. The hashes are derived from transaction data. A tool needs the relevant serialized data or a record that already contains the relationship. Renaming a field, adding a prefix or deleting characters does not recover the missing witness information.

An ordinary user should copy the existing txid rather than paste a wallet backup into an online converter. A transaction lookup does not need recovery words. If a developer needs raw transaction data for diagnosis, first clarify whether the request is purely a decode operation and what information that data reveals. Reading serialized data and broadcasting a transaction are distinct actions.

A decoded record does not itself establish network acceptance. An offline decoder can explain fields before a transaction is ever broadcast. After identifying the correct lookup reference, still inspect the actual network result. The purpose of this distinction is to locate the record reliably, not to promote any correctly formatted string into proof of receipt.

For an export or support form

Keep separate fields for txid, wtxid and blockhash, even if they look similar. If a source omits one field, record it as unavailable rather than copying another value into the gap. Equal values are meaningful only when the source actually identifies them that way. Preserve the network and exporting application with the record, so a later importer can interpret its labels. A form that stores every reference under one generic hash heading loses information needed for a reliable lookup.

Build a small support note with explicit fields

1. Open the original payment entry and copy the value explicitly labelled txid.
2. If the entry also supplies wtxid, preserve it separately with its exact label.
3. Record the Bitcoin network and the wallet or service that supplied the fields.
4. Use the lookup form that accepts the relevant identifier and keep any exact error message.
5. If two records appear unrelated, compare the decoded transaction details before calling them a witness pair.
6. Share the minimum public references needed for the case; do not include wallet secrets.

Imagine a fictional wallet export with txid labelled T and wtxid labelled W. The explorer finds T and shows the intended recipient output; its search box does not recognize W. That result does not describe a second payment disappearing. The useful report says which field each value came from and what each lookup returned. In another case, a newly signed replacement might produce a different T; that requires transaction-history analysis rather than merely relabelling W.

Use the transaction-hash checking guide for the broader verification process, and Bitcoin transaction timing for an actually pending payment. For a no-account swap, include the order reference separately from the deposit txid. Correctly labelling the chain identifier lets support investigate the relevant transfer without confusing an order, a block and a witness hash.