Timechain Wiki

Blocks and the blockchain

13 min read

A Bitcoin block is the unit of consensus: a batch of transactions plus an 80-byte header that commits to them and links to the prior block. The blockchain is the chain of these headers, each pointing to its predecessor by hash — a tamper-evident ledger that grows by one block roughly every 10 minutes. Block headers contain six fields (version, previous-block hash, Merkle root, timestamp, difficulty target, nonce); the Merkle root commits to the entire transaction set via a tree-of-hashes (see Merkle trees); the previous-block hash is what links blocks into a chain. The header is also what miners actually hash when searching for valid Proof of Work — modifying any field changes the hash. Pre-SegWit, blocks were limited to 1 megabyte by raw byte count; the November 2017 SegWit upgrade replaced this with a weight-based limit (4 million weight units per block) that gives witness data a structural discount. The 10-minute average block interval is enforced by the Difficulty adjustment mechanism; the chain's first block (the The Genesis Block) was mined January 3, 2009.

Why this note matters

Blocks are the structural unit of Bitcoin consensus. Everything else in the protocol — transaction confirmation, the Proof of Work competition, the Difficulty adjustment mechanism, the Consensus rules that nodes enforce, the chain-reorganization handling — is built around the block as the atomic step.

This note is the structural reference for the block as data: what it contains, how it’s formed, how it commits to its contents. The dynamics around blocks (how nodes agree on which is canonical, what happens at forks) live in Chain reorganizations; the consensus enforcement lives in Consensus rules; the historical event chronicle of block-size disputes lives in Block Size Wars - History.

Block structure

A modern Bitcoin block consists of:

- Block header (80 bytes, fixed)
  - Version (4 bytes)
  - Previous block hash (32 bytes)
  - Merkle root (32 bytes)
  - Timestamp (4 bytes)
  - Difficulty target / bits (4 bytes, compact format)
  - Nonce (4 bytes)
- Transaction count (variable-length integer)
- Transactions
  - First: coinbase transaction (creates new BTC + collects fees)
  - Remaining: user transactions in mempool-fee-priority order (typically)
- (SegWit) Witness commitment in coinbase output

The header is the load-bearing part. It’s:

  • Tiny (80 bytes) — easy to ship around, easy to validate, easy to store. Full archive of all headers since 2009 is roughly 70 MB.
  • Self-contained for Proof of Work verification — the difficulty-target field plus the resulting hash are everything needed to check the work.
  • Committing to the transaction set via the Merkle root — any change to any transaction changes the root, which changes the header hash, which would invalidate the PoW.

This separation — header carries the consensus weight, transactions carry the volume — is what makes SPV light clients viable (see Full nodes vs pruned vs SPV).

Block header fields in detail

Version (4 bytes). Originally a simple version number (1, 2, etc.). After BIP-9 (versionbits, 2015), the field became a bit-field for signaling soft-fork support — each bit represents a specific upgrade proposal. Miners signal readiness by setting the bit; activation thresholds determine when the proposal locks in. See Soft forks and hard forks.

Previous block hash (32 bytes). Double-SHA-256 of the previous block’s header. This is what makes the chain a chain — every header points backward by hash. Modifying any historical block changes its hash, which would require re-computing all subsequent block hashes (and re-doing all their Proof of Work). This is the structural source of Bitcoin’s tamper-evidence.

Merkle root (32 bytes). The root of the Merkle tree over all transactions in the block. See Merkle trees for the construction. Commits to the exact transaction set; any change to any transaction (including transaction ordering) changes the root. The miner that finds a valid PoW has implicitly committed to the specific transaction set their root represents.

Timestamp (4 bytes). Unix epoch time, claimed by the miner. Loose validation: the timestamp must be greater than the median of the past 11 blocks’ timestamps and less than 2 hours in the future from the validating node’s local time. Miners can lie by a few hours within these bounds; this is allowed so that small clock skews don’t invalidate blocks, but it caps how much manipulation is possible.

Difficulty target / bits (4 bytes, compact format). The target value the block hash must be ≤ to constitute valid Proof of Work. Stored in a compact “bits” encoding for size efficiency. The target adjusts every 2016 blocks; see Difficulty adjustment.

Nonce (4 bytes). The 32-bit field miners increment in their PoW search. With only 4 billion possible nonces, modern mining ASICs exhaust the nonce range in microseconds — so miners also vary the coinbase transaction (which changes the Merkle root) to obtain fresh hashing material. The conventional name “nonce” persists, but practical mining uses the coinbase extra-nonce as the primary search dimension. See Proof of Work.

The coinbase transaction

The first transaction in every block is special — the coinbase transaction. Its job:

  • Issue new BTC at the current block-subsidy rate (50 → 25 → 12.5 → 6.25 → 3.125 BTC per block, halving every 210,000 blocks). See The halving - Mechanism.
  • Collect fees — the input total in the coinbase equals the block subsidy plus the sum of all fees from the other transactions.
  • Pay the miner — the coinbase’s outputs typically pay the miner’s address(es).
  • Allow extra-nonce variation — the coinbase’s input has an “arbitrary data” field (up to 100 bytes) that miners use to search additional nonce-space beyond the header’s 4-byte nonce.

The coinbase transaction has no inputs in the normal sense — its input field references the all-zeros “previous output” (32 bytes of zeros plus output index 0xFFFFFFFF). The arbitrary input data is the “scriptSig” of this fake input.

Post-SegWit blocks also include a witness commitment in one of the coinbase’s outputs — the Merkle root over the witness data of all transactions in the block. This is what enables witness-data validation without putting witness commitments in the header (which would have required a hard fork).

The chain structure

A blockchain is a sequence of block headers where each header’s “previous block hash” field is the hash of its predecessor:

Genesis (block 0) ← Block 1 ← Block 2 ← ... ← Block 958000

The chain is unidirectional — each block knows its parent; the parent doesn’t know its children. New blocks extend the chain by referencing the current tip.

No fixed pointer to a “current tip” exists at the protocol level. Each node decides what the current tip is by applying the longest-chain rule (more precisely, most-cumulative-work) to the blocks it knows about. Different nodes can briefly disagree about the tip during chain reorganizations; see Chain reorganizations.

Block height. A block’s height is its position in the chain — Genesis is height 0, the block after it is height 1, and so on. As of mid-2026, the chain is at roughly block 958,000 — the April 2024 halving occurred at block 840,000, with roughly 118,000 blocks (~27 months) mined since.

The cumulative-work metric. Each block contributes “work” proportional to its difficulty target’s inverse (a harder target represents more expected hash trials). The “main chain” is the one with the most cumulative work, not necessarily the most blocks (though in practice these usually coincide — see Chain reorganizations).

Block size, block weight, and SegWit

Bitcoin’s original block size limit (introduced by Satoshi as an anti-spam measure) was 1 megabyte by raw byte count. The November 2017 Block Size Wars - History dispute culminated in SegWit (Segregated Witness, BIP-141) replacing the byte-based limit with a weight-based limit:

  • Non-witness data: 4 weight units per byte
  • Witness data (signatures): 1 weight unit per byte
  • Maximum block weight: 4,000,000 weight units

Equivalently: a block with no witness data is limited to 1 million bytes (same as before SegWit). A block whose entire contents is witness data could theoretically be up to 4 megabytes. Real blocks fall somewhere in between — empirical post-SegWit blocks tend to be 1.5-2 megabytes in raw bytes, with witness data benefiting from the 4x discount.

Why the weight discount? Witness data (signatures) is needed for validation but doesn’t need to be retained forever — it could in principle be pruned post-validation. The discount incentivizes wallets to use witness-bearing address types (P2WPKH, P2WSH, P2TR), which segregate signatures into the witness and benefit from the lower per-byte weight cost.

The 1 MB constant remains for compatibility. Old non-SegWit nodes see only the non-witness portion of blocks (the witness is stripped from their view) and continue to enforce a 1 MB limit on what they see. New nodes enforce the 4 MWU weight limit. The two views are consistent — the protocol upgrade was a soft fork.

For substantive engagement with whether the 4 MWU limit should be increased, see Network capacity and fee-market critiques (Criticisms section).

Block validation

When a node receives a new block, it validates:

  1. Header well-formed. 80 bytes; all fields parseable.
  2. PoW valid. Block header double-SHA-256 hash ≤ the difficulty target encoded in the header’s bits field.
  3. Previous block known. The previous-block-hash field references a block the node already has.
  4. Timestamp plausible. Greater than median-of-past-11 and less than 2-hours-in-future.
  5. Difficulty correct. The difficulty target matches what the difficulty-adjustment algorithm predicts for this block height.
  6. Block weight valid. ≤ 4 million weight units.
  7. Merkle root correct. Recomputing the Merkle root over the included transactions yields the value in the header.
  8. All transactions valid. Each transaction satisfies the per-transaction consensus rules (inputs unspent, signatures valid, scripts execute correctly, no negative output values, etc.).
  9. Coinbase valid. First transaction; correct subsidy amount; coinbase scripts correctly formed.
  10. Witness commitment matches. Post-SegWit: the witness commitment in the coinbase matches the actual witness data.

Failure on any rule causes the block to be rejected. The full set of validation rules lives in Consensus rules.

Block propagation

When a miner finds a valid block, it propagates across the peer-to-peer network. Modern propagation uses:

  • Compact block relay (BIP-152). Instead of sending the full block, send a header plus short transaction identifiers (6-byte truncated TXIDs). Recipients already have most transactions in their mempool and only need to request the missing ones. This dramatically reduces propagation bandwidth and latency.
  • FIBRE / Block-relay-only networks. Specialized relay networks operated by miners and large nodes for sub-second propagation between major mining operations.

Propagation latency matters for Chain reorganizations — slow propagation increases the rate of “orphan” or “stale” blocks (blocks built on a tip that’s been superseded by a competitor before the miner heard about it).

The peer-to-peer relay infrastructure is treated in The peer-to-peer network.

Tradeoffs and design choices

Why 10-minute average block time? Satoshi chose 10 minutes as a compromise between:

  • Confirmation latency — users want fast confirmations, suggesting short block intervals
  • Network propagation time — blocks need to reach the entire network before the next is found, or stale-block rates spike. With 2009-era internet bandwidth, propagating a block globally took several seconds at minimum.
  • Reorg frequency — shorter intervals increase the probability of competing blocks at the same height, raising reorg rates. 10 minutes gives roughly 60 seconds of propagation margin even for slow links.

The choice has held up. Faster block-time alternatives (Litecoin at 2.5 minutes, Ethereum at ~12 seconds) demonstrably have higher orphan rates and weaker single-confirmation security than Bitcoin.

Why 80-byte headers? Small enough to ship efficiently to light clients (a year of headers is ~4 MB total); large enough to carry all six required fields plus modest room. The size has been stable since 2009.

Why 4 weight units per byte (non-witness) and 1 per byte (witness)? Engineering compromise during SegWit design. The 4x ratio was chosen to (a) preserve backward compatibility with the 1 MB byte-count limit when no witness data is used, and (b) incentivize witness-bearing address types without overly inflating throughput. Stronger or weaker discounts were both possible; the chosen ratio is empirical.

The 4 MWU ceiling. Whether this should be raised has been the most contentious protocol-evolution debate in Bitcoin’s history (the Block Size Wars). The post-SegWit consensus is that Layer 2 scaling (Lightning Network) and witness-discount efficiency gains are the right paths forward; an explicit base-layer block-weight increase has not been proposed seriously since 2018. For analytical engagement, see Network capacity and fee-market critiques (Criticisms section).

Coinbase 100-block maturity. Coinbase outputs cannot be spent for 100 blocks after their creation. This protects against the most basic reorg-attack: if a miner could immediately spend their coinbase, and that block were then reorged out, the spent funds would be in the new chain (created by a coinbase that no longer exists in the canonical chain). The 100-block delay ensures coinbase outputs have substantial confirmation depth before they’re spendable.

For substantive engagement with throughput limits, see Network capacity and fee-market critiques (Criticisms). For the historical record of block-size dispute, see Block Size Wars - History.

Open questions for further development

  • Will another base-layer block-weight increase ever be proposed seriously? The 2017 Block Size Wars effectively foreclosed the discussion for the foreseeable future; the post-2017 consensus is firmly in favor of Layer 2 scaling.
  • How does block validation cost evolve as the UTXO set grows? Validation is bounded by block weight, but UTXO-set lookups can become more expensive as the set grows.
  • Are there reasons to expect changes to the block header format in the foreseeable future? Adding fields would require a hard fork; some proposals (covenant commitments, accumulator commitments) would benefit from new header fields.
  • How long until the 100-block coinbase maturity rule becomes operationally significant for any new protocol construction? Currently it’s a forgotten detail.

Canonical sources for this note

Bitcoin Improvement Proposals

  • BIP-141 — Segregated Witness (defines block weight).
  • BIP-152 — Compact block relay.
  • BIP-9 — versionbits soft-fork signaling in the version field.

Bitcoin engineering references

  • Mastering Bitcoin, Andreas Antonopoulos (chapter 7: “The Blockchain”; chapter 9: “Blocks”) — the canonical engineering treatment. See Mastering Bitcoin - Andreas Antonopoulos.
  • Programming Bitcoin, Jimmy Song (chapter 9: “Blocks”) — working-programmer treatment with block-header parsing.
  • Grokking Bitcoin, Kalle Rosenbaum (chapters 7-8) — accessible treatment.

Historical and analytical

Graph View

Backlinks