RPC byte order

The 64 character string your wallet calls a transaction ID is not the order those bytes take anywhere else. Bitcoin Core keeps a hash in a type that prints it most significant byte first, every explorer copied the habit, and the convention is now permanent. It is harmless when you paste an identifier into a search box and expensive when you paste it into code.

How it works

RPC byte order is a display transformation applied on the way out of a node, not a different hash.

A digest leaves SHA-256 as 32 bytes with no inherent direction. Bitcoin Core holds it in a container that models those bytes as a single very large number, and printing a number puts the most significant part on the left, which reverses the array. Every JSON field naming a block or a transaction comes out that way: the hash from getblockhash, the txid from getrawtransaction, the merkleroot from getblock, the previousblockhash that ties a block to its parent.

One consequence shows on every explorer's front page. Proof of work produces digests that begin, in this printed direction, with a long run of zeros. Those zeros sit at the far end of the raw bytes. Mining targets are easier to reason about in the printed form, which is part of why the convention stuck rather than being cleaned up.

The flip applies to hashes only. Public keys, signatures, scripts and witness items are all printed in their true order, so a script from decodescript can be compared directly against the raw transaction while a txid cannot. Mixing those two rules is where working code usually goes wrong.

A single response can even contain both conventions at once. Ask for a transaction with verbose output and the txid field is reversed, while the hex field sitting beside it is the untouched serialization holding the same hash the other way round.

Where you see it

RPC byte order is the only form of a hash that most people ever handle.

It is what an exchange puts in a withdrawal confirmation email, what a block explorer expects in a URL, what a support agent asks you to send, and what bitcoin-cli prints. Asking a node for the very first block with getblockhash 0 returns 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, and pasting that string into any explorer resolves to the block mined on January 3, 2009.

The failure mode is narrow and consistent. Someone computes a transaction identifier themselves, hashing the serialization twice with SHA-256, compares the result against an explorer and finds no resemblance at all. Both strings are the same 32 bytes and one of them needs reversing. The identical fix applies when a script pulls a txid out of a raw input and looks for it in a table of identifiers collected from an API.

There is a two second habit worth adopting. If a hash somebody sent you resolves nowhere, try it backwards before concluding that the transaction does not exist. Support threads are full of hashes that were copied out of raw data rather than out of a wallet, and they look completely valid until you reverse them.