Block Header

Think of a block as a package of transactions and its header as the accompanying record. The header does not list recipients or amounts. Instead it carries cryptographic fingerprints: short values calculated from data that make changes detectable. One points to the previous block. Another, called the Merkle root, summarizes the identifiers of this block’s transactions. The header thus connects particular contents to a particular place in history. It is not a miniature copy of the transactions: their original contents cannot be read back from the fingerprint. [1] [4]

A miner assembles a candidate block and searches for a suitable hash, a fingerprint interpreted as a number. It must be less than or equal to the required target. This search is Proof of Work: the miner repeatedly changes data and tries another calculation because a suitable result cannot simply be predicted. The most visible variable is the nonce, an auxiliary number in the header. For more possibilities, the miner can change data in the special Coinbase Transaction created at the start of the block. That also changes the Merkle root and produces a different header. Other nodes can quickly repeat the calculation to check the result. [1] [3] [4]

A chain of headers lets you follow the links between blocks and verify their associated work without downloading every transaction. But imagine a block with valid Proof of Work in which someone tries to spend another person’s funds without the necessary signature. Checking its header alone will not reveal that problem. A Full Node therefore also checks transactions, their signatures, available unspent outputs and the permitted reward. A valid header does not guarantee that the whole block is valid. [2]

The nBits field specifies the target the hash must meet. It is a compact encoding of that target, not the “difficulty” figure displayed by a block explorer. The node also checks that the target follows the rules for this position in the chain. Similarly, a miner cannot choose an arbitrary time. It must be later than the median of the previous 11 blocks—the middle value when their times are sorted—and must not be too far in the future. Even so, it is neither the exact time of each payment nor a stopwatch measuring mining time. [2] [3]

The order and field sizes are fixed: version takes 4 bytes, the previous header’s hash 32, the Merkle root 32, time 4, nBits 4 and nonce 4. That is 80 bytes regardless of the number of transactions. The block identifier is produced by applying SHA-256 twice to this precisely encoded header. Numeric fields use little-endian order, placing the least significant byte first; hashes use an internal byte order different from the usual display of an identifier. To reproduce the calculation, you cannot simply join the values as a block explorer displays them. [1] [4]