Bitcoin blocks group transactions and secure them using proof of work. Each block includes an 80‑byte header plus a list of transactions. Despite the heavy energy cost of producing a valid block, verifying one is cheap: storing all ~900k headers requires only ~72 MB, allowing even small devices to verify the chain’s proof of work efficiently.

Each block begins with exactly one Coinbase transaction—the only way new bitcoin enter circulation. It has a zeroed prev-tx hash and an index of 0xffffffff, uniquely identifying it. The subsidy started at 50 BTC and halves every 210,000 blocks (50, 25, 12.5, 6.25, 3.125, …). Miners also include transaction fees. Because the 4‑byte nonce is too small for modern ASICs, miners modify data in the Coinbase transaction to change the Merkle root and create additional search space. BIP34 requires embedding the block height in the Coinbase scriptSig to ensure every Coinbase txid is unique.

The 80‑byte header contains:

Version numbers evolved into a bit‑field signaling system via BIP9, allowing miners to coordinate soft-fork readiness. The timestamp is a 32‑bit Unix time value and will need updating around the year 2106.

The bits field encodes the target in compact form: target = coefficient × 256^(exponent−3). Valid block hashes must be numerically below this target. Because hashes are interpreted as little-endian integers, valid hashes often appear with many trailing zeros when displayed in hex.

Difficulty is defined as lowest_target / current_target, expressing how much harder mining is today compared to the easiest possible difficulty. Validation requires only comparing the hash of the header to the target—extremely cheap relative to mining.

Every 2016 blocks, Bitcoin adjusts difficulty to target ~10‑minute block intervals. The adjustment compares the actual time for the previous 2016 blocks with the expected two weeks. Limits constrain adjustments to within a factor of four. Major real‑world events—such as China’s mining ban—demonstrated this mechanism’s resilience when hash rate dropped sharply and difficulty adjusted downward to compensate.

The subsidy at height h is computed as: subsidy = 5_000_000_000 >> (h // 210_000). This yields the halving schedule that converges toward a total supply of ~21 million BTC. Summing the geometric series (50 + 25 + 12.5 + …) × 210,000 explains the cap. Miners may claim less than the allowed subsidy but never more, or the block becomes invalid. As subsidies shrink over successive halvings, transaction fees become an increasingly important component of miner revenue and long‑term network security.