Merkle root

Change one satoshi in one payment, reorder two transactions, or add one more, and the root changes completely. Miners rely on that: the 32 bit nonce offers only about 4.3 billion attempts, so mining software edits the coinbase transaction to mint a fresh root and keep searching. For anyone holding coins, that one field is why a block cannot quietly gain or lose a payment after it is mined.

How it works

The merkle root is computed rather than chosen, which is what makes it worth anything.

It occupies 32 of the 80 bytes in the header, and a miner writes whatever value the transactions produce. Every node that receives the block rebuilds the tree from the transaction list it was sent and compares its own answer with the header. A mismatch means rejection, immediately and without argument. There is no version of the protocol in which a header says one thing and the block body says another.

That check makes the root the hinge of the mining loop. The nonce is only four bytes wide, which is 4,294,967,296 possible values; a machine running at 200 trillion hashes per second exhausts every one of them in roughly twenty millionths of a second. Miners therefore need a way to generate fresh candidates, and the cheapest one is to alter the coinbase transaction. Pools send each machine the coinbase split into two halves with a gap between them, the machine writes its own bytes into the gap, the coinbase transaction id changes, the merkle root changes, and 4.3 billion new nonces become available. Rolling the timestamp and the 16 version bits reserved by BIP320 provide additional room.

Segregated witness added a second root without touching the header, because touching the header would have been a hard fork. BIP141 defines a separate tree over witness transaction ids whose root is written into an output of the coinbase transaction, marked by the four byte prefix 0xaa21a9ed. Because the coinbase is itself a leaf of the ordinary tree, that witness commitment ends up folded into the header's merkle root anyway, one level removed.

Where you see it

The merkle root is one of the fields any block explorer will show you, and one of the few you can verify by hand.

Bitcoin Core reports it as merkleroot in the output of getblockheader and getblock. The genesis block's value, beginning 4a5e1e4b, is a good place to start, because that block holds a single transaction: a tree with one leaf is its own root, so the merkle root and the transaction id are identical. Any block containing only a coinbase transaction has the same property.

You also see it in mining protocols rather than in blocks. A Stratum job notification does not send a miner the transactions at all. It sends the coinbase halves plus the short list of hashes needed to walk from the coinbase up to the top, so the machine can compute the root itself for every extranonce it tries. Stratum V2 changes who selects the transactions in the first place, but the root is still assembled the same way.

Merkle root vs previous block header hash

The merkle root and the previous block header hash are both 32 byte hashes sitting side by side in the same 80 byte header, and they commit in different directions. The merkle root points inward, to the contents of this block: the transactions, their order, and nothing else. The previous block header hash points backward, to the entire history behind it. Edit a payment and only the merkle root breaks. Edit a block from last year and the previous block header hash of every block since is wrong, which is the difference between tampering with one block and tampering with a chain.