Internal byte order

Two conventions travel under one name. Every integer field in a transaction or a block header is little endian, so a version number of 2 is written 02000000, and every 32 byte hash sits in the raw data exactly as the hash function emitted it. Human facing tools reverse those hashes before printing them, which is the commonest reason a hand written parser disagrees with a block explorer.

How it works

Internal byte order is best learned by taking the 80 byte genesis block header apart, since every field in it is small enough to check by eye.

It opens with 01000000, the version number 1 in four little endian bytes. Then 32 zero bytes, because the first block has no parent. Then the merkle root, stored as 3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a, which is the digest every explorer prints as 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b written backwards one byte at a time. Then 29ab5f49, the timestamp 1231006505, meaning 18:15:05 UTC on January 3, 2009. Then ffff001d, the difficulty field whose logical value is 0x1d00ffff. Then 1dac2b7c, the nonce 2083236893.

Amounts obey the same rule. One bitcoin is 100,000,000 satoshis, and an output paying exactly that carries the eight bytes 00e1f50500000000.

The reason is historical and fairly mundane. Bitcoin was written for x86 machines, which hold integers least significant byte first, and the earliest code wrote structures out in whatever arrangement the processor already had them in. Hashes were never reversed at all. What changed was the printing, because Bitcoin Core stores a digest in a class that treats it as one enormous number, and numbers are printed with the most significant part on the left.

Where you see it

Internal byte order is what you get whenever a tool hands you raw bytes instead of a formatted answer.

Fetch a transaction with getrawtransaction and no verbose flag, or a header with getblockheader and verbose set to false, and everything inside arrives in this order. The same holds for a PSBT exported by a hardware wallet, for the hex behind an explorer's raw tab, and for the block files sitting in a node's blocks directory.

The field that catches people out is the outpoint at the start of every input. It names the transaction being spent with 32 bytes that read as the reverse of the identifier the explorer displayed. Nothing is corrupt when those two strings fail to match: flip one and they agree.

Internal byte order vs RPC byte order

Internal byte order and RPC byte order describe the same 32 bytes running in opposite directions, and the rule for converting between them carries one important exception. Hash digests get reversed on the way out to a human and reversed again on the way back in. Integers do not. A block height, a timestamp and an amount in satoshis are all presented as ordinary decimal numbers, and flipping one of those on the way in or out simply yields a wrong value rather than a differently written one. Reverse hashes and nothing else, and most byte order bugs disappear.