Serialized block

Serialization is how an abstract block turns into something you can hash, send, and store. The genesis block serializes to 285 bytes: 80 for the header, 1 for the transaction count, and 204 for its single coinbase transaction. If you have ever pasted raw hex into a block explorer or run getblock with verbosity 0, this is the thing you were looking at.

How it works

Three pieces sit end to end in a serialized block, and only the first has a fixed length.

The header is always 80 bytes, in this order: a 4 byte version, the 32 byte hash of the previous header, the 32 byte merkle root, a 4 byte timestamp, the 4 byte nBits target encoding, and a 4 byte nonce. Next comes the number of transactions, written in compactSize, a variable length integer that occupies 1 byte for counts below 253 and up to 9 bytes for anything enormous. Then the transactions themselves, each fully serialized, coinbase first.

Since BIP144 the same block has two legal serializations. The stripped form leaves witnesses out entirely and is what pre 2017 software expects. The full form includes them, marking each witness carrying transaction with a 0x00 byte followed by a 0x01 flag where the input count would otherwise be. Both encode the identical block, and both produce the identical block hash, because the hash covers only those 80 header bytes and the merkle root inside them commits to transaction ids, which are computed from the stripped encoding. That separation is the literal meaning of segregated witness.

One habit catches everyone at least once: multi byte integers are written little endian, so the timestamp 0x495FAB29 appears on the wire as 29 ab 5f 49, and hashes are displayed in the reverse of their serialized byte order. A block hash you copy from an explorer is not the byte sequence sitting in the file.

Where you see it

Serialized blocks travel over the peer to peer network inside a block message. Each message carries a 24 byte envelope first: a 4 byte start string, f9beb4d9 on mainnet, a 12 byte command name, a 4 byte payload length, and a 4 byte checksum taken from the first four bytes of a double SHA-256 over the payload. Bitcoin Core caps any single message payload at 4,000,000 bytes, a network limit rather than a consensus one.

The same bytes land on your disk. Bitcoin Core appends blocks to files named blk00000.dat and upward, each capped at 128 MiB, with the identical start string and a length prefix before every block so the file can be scanned linearly. Genesis is the exception: it is compiled into the software as a constant rather than downloaded, which is what makes it the anchor a syncing node measures everything else against.

For everyday use, the serialization surfaces through the getblock RPC at verbosity 0, through the raw or hex tab on most explorers, and inside tools that let you decode a block by hand. Anyone verifying that an explorer told them the truth ends up here, because the hex is the only representation nobody has reformatted.

Serialized block vs block

A block is the object; a serialized block is one encoding of it. The distinction was cosmetic until 2017, when SegWit gave every block two valid encodings of different lengths, so the size of a block became a question that needs qualifying. Bitcoin Core answers it three ways in a single RPC response: size for the full serialization, strippedsize for the witness free one, and weight for the number the rules actually enforce.