Bitcoin Core decoderawtransaction RPC: Transaction Inspection Guide

This guide explains Bitcoin Core decoderawtransaction RPC in plain English. It shows what the command does, what its result means and what it cannot prove.

Hex and witness mode

The required input is serialised transaction hex. Iswitness can state whether the serialisation includes witness; if omitted, the node uses heuristics. Ambiguous or adversarial data should be decoded under both explicit interpretations where relevant, then compared against the expected source format rather than accepting a heuristic result as provenance.

Transaction identifiers

txid excludes witness commitment details under SegWit rules, while the returned hash represents the witness transaction identifier and can differ. Monitoring, hardware signers and exchange APIs must label these identifiers correctly. Do not use equality as a universal validity check and never substitute one identifier in a system that expects the other.

Size and virtual size

size is serialised bytes, while vsize reflects transaction weight for fee-rate accounting. For witness transactions they can differ materially. Calculate fee rate from known input and output values divided by virtual size, not raw byte size, and preserve integer arithmetic and explicit units in logs and approval screens.

Inputs and previous outputs

vin exposes outpoints, scriptSig, witness items and sequence, but not the values of spent outputs. Fetch each previous output from a validating node or trusted UTXO snapshot, verify its script and confirmation state, and detect duplicate inputs. Without that external data the decoder cannot calculate fee or determine ownership.

Outputs and scripts

Each vout includes BTC value, index and a decoded scriptPubKey with type and possible addresses. Treat addresses as a presentation derived from script, not the authoritative output. Compare the raw script hex, exact satoshi value and network expectations; unusual scripts may not have meaningful addresses or a reliable reqSigs summary.

Parsing is not validation

Successful JSON output does not establish consensus validity, standardness, signature correctness, mempool acceptance or business approval. Run script verification and policy checks in the appropriate environment, and use testmempoolaccept in versions that support the required flow. Keep decoding services read-only and bounded against oversized input.

How specialists test it

Operators test the command on a non-production node first. They check a normal reply, an invalid request, a timeout and a restart. This shows what the response means and prevents one local result from being mistaken for a network-wide outcome.

Conclusion

decoderawtransaction is a powerful inspection boundary, but readable JSON is only a description of supplied bytes. Complete analysis still needs previous outputs, exact value accounting, script validation and policy or business approval.