Inside a Bitcoin Block: Header, Coinbase and Why the Longest Chain Is the Heaviest

Bitcoin’s transaction data is permanently recorded in files called blocks, organised into a linear sequence over time. The wiki’s analogy is a city recorder’s book of property titles or a stock ledger: a record of changes, in order, that becomes harder to alter the further back it sits.

That hardness is not a policy. It is a consequence of the chain: each block references the one before it, so editing an old block means redoing the work on every block that came after.

The five fields

The serialised format is compact, and the wiki lays it out field by field.

Two things stand out. The block size field is a length, not a rule about how much data can be in a block; the consensus limit is a separate matter. And the transaction list is explicitly non-empty: an empty block has no reason to exist.

The header is fixed at 80 bytes and made of six items. That fixed size is what makes the proof-of-work puzzle cheap to verify: a party checking a block hashes a small, constant-sized structure rather than the whole block body.

What every block carries

Beyond the field table, the wiki describes four things a block contains:

• The current time.
• A record of some or all recent transactions.
• A reference to the block that came immediately before it.
• An answer to a difficult-to-solve mathematical puzzle, unique to each block.

New blocks cannot be submitted without the correct answer, which is what mining is: competing to be the next to find it. The puzzle is extremely difficult to solve and very easy to confirm once solved, and there are multiple valid solutions for any given block — only one needs to be found.

The time field is worth a note because it is often read as a timestamp of truth. It is a value the miner puts in the block, bounded loosely by consensus rules, not a synchronised clock reading. Chain order, not the timestamp, is what establishes sequence.

The coinbase: where the reward is paid

Every block contains a record of which addresses or scripts are entitled to receive the reward for solving it. That record is the generation, or coinbase, transaction — always the first transaction in the block.

The reward started at 50 bitcoin per block and halves every 210,000 blocks, about four years. The coinbase is also where transaction fees land, which is why miners have an incentive to include transactions at all: the wiki notes that peers trying to solve blocks collect transaction records and add them to the block they are working on because of the attached fees.

The coinbase transaction is structurally different from an ordinary payment. It has no real input — it creates new coins under the schedule — and how much it may claim is bounded by the reward plus the fees of the included transactions. A miner who claims too much produces an invalid block.

When two blocks appear at once

Because miners compete independently, two miners can arrive at two different valid solutions for the same block at the same moment, each unaware of the other. Both blocks are valid. For a short period, the chain has two tips.

The peer-to-peer network is designed to resolve that quickly, so that only one branch survives. What decides the winner is the rule everyone runs:

The client accepts the ‘longest’ chain of blocks as valid. The ‘length’ of the chain refers to the chain with the most combined difficulty, not the one with the most blocks.

The wiki gives the reason directly. Counting blocks would let someone fork the chain, create a large number of low-difficulty blocks and have that accepted as “longest”. Counting accumulated work makes each competing block cost its producer the same as it costs anyone else. The rule turns “longest” into a measure of energy spent rather than a count of records.

Height, depth and the word “confirmation”

The block height is the total number of blocks mined so far. A transaction included in a block is one block deep; each subsequent block buries it one deeper.

The wiki’s framing of what depth does is the useful part: as blocks are buried deeper and deeper into the chain, they become harder and harder to change or remove, which is what gives rise to the idea of irreversible transactions. Irreversibility is not a switch — it is a cost curve. Rewriting a transaction that is one block deep requires outcompeting the network for one block; rewriting one that is a thousand blocks deep requires redoing all of that work.

That also explains why blocks never stop. The wiki addresses it directly: transactions will still occur once all the coins have been generated, and blocks are for proving that transactions existed at a particular time. Issuance is a phase. Record-keeping is the product.

What a block does not tell you

Three limits that matter when reading an explorer.

The block does not say whether a payment is “final”. It provides the evidence; finality is a judgement about how expensive reversal would be, which is why different recipients ask for different depths.

The block does not establish intent. It records that a script was satisfied. Whether the sender meant to send to that address, and who controlled it, is not in the record.

The block does not contain a wallet balance. Balances are a derived view — a running total computed from the transaction history. The chain stores outputs, not accounts, which is why an interface’s “balance” and an explorer’s “balance” can disagree without either being wrong about the blocks themselves.