How Bitcoin Blocks Work

Bitcoin processes transactions through blocks, but a block is more than a container filled by a miner.

It is a structured proposal with proof of work, a link to prior history, a commitment to its transactions, and a set of transactions that must satisfy Bitcoin's rules together. A miner can construct and hash a candidate. The candidate becomes part of a node's selected chain only after the node validates it and chain selection places it on the active history.

Understanding that sequence prevents several common mistakes. Miners do not vote transactions valid. A block hash does not excuse invalid contents. A transaction does not become confirmed merely because it appeared in a template.

Candidate blocks, mined blocks, and accepted blocks are different stages

A mining system begins with a candidate block.

The candidate usually contains:

• A header linked to a chosen previous block.
• A coinbase transaction created for the candidate.
• A selected set of additional transactions.
• A Merkle root committing to the transaction identifiers.
• Any required witness commitment.
• A target encoded in the header's nBits field.
• A timestamp and version.
• A nonce plus other changeable data used while searching.

The miner repeatedly hashes block headers or related header variants while changing fields that alter the header commitment. Most results do not satisfy the target.

When a hash is at or below the required target, the miner can submit the resulting block to the network. That does not guarantee acceptance. Each receiving node checks proof of work, header context, transaction validity, block limits, coinbase rules, commitments, and other consensus conditions.

A block is valid only if the complete object passes those checks. A valid block may still compete with another valid branch before one chain becomes selected.

The block header is 80 bytes

The serialized Bitcoin block header contains six fields:

• Version, 4 bytes.
• Previous block hash, 32 bytes.
• Merkle root, 32 bytes.
• Timestamp, 4 bytes.
• Encoded target, commonly called nBits, 4 bytes.
• Nonce, 4 bytes.

Together they form an 80-byte header.

The block hash is the double-SHA-256 hash of this serialized header, interpreted under Bitcoin's proof-of-work rules. The hash must satisfy the target represented by nBits.

Only the header is repeatedly hashed in the basic proof-of-work loop. The transaction list affects that loop through the Merkle root and, for witness data, through the witness commitment included in the coinbase transaction.

Changing a transaction, its order, the coinbase data, or a witness commitment changes a commitment and ultimately changes the header being hashed.

The previous-block field links history

The previous block hash points to the block the candidate seeks to extend.

That link creates a chain of headers. Altering an earlier block changes its hash, which breaks the next block's previous-hash reference and every later link built from it.

The link alone does not select the active chain. Nodes can know about multiple valid branches. They compare accumulated proof of work among valid candidates and activate the chain their rules select.

A miner cannot point to an invalid parent and make it acceptable through additional hashing. The branch must remain valid under the node's consensus rules.

The Merkle root commits to transaction identifiers

Bitcoin arranges the block's transaction identifiers into a Merkle tree and places the resulting Merkle root in the header.

The root is a compact commitment to the ordered transaction list. A node can recompute it from the block and reject the block if it does not match the header.

The root does not store every transaction inside the header. The full transactions still travel with the block or are reconstructed through a relay protocol. The root lets a verifier detect a mismatch between the header commitment and the supplied transaction set.

Transaction order matters. Reordering transactions changes the Merkle tree and therefore the root.

A Merkle branch can later prove that a transaction identifier is included in a particular block without listing every other transaction identifier. That proof addresses inclusion in the committed set. It does not by itself prove that the block is valid, selected, or deeply confirmed.

SegWit adds a witness commitment

The ordinary Merkle root commits to transaction identifiers that exclude segregated witness data.

BIP 141 therefore defines a separate witness commitment. The commitment is placed in an output of the coinbase transaction and commits to a witness Merkle root together with a reserved value from the coinbase witness.

Nodes enforcing SegWit rules verify this commitment when the block contains witness data under the applicable conditions.

This is why saying "the header Merkle root commits to every byte in the block" is inaccurate. The transaction-id Merkle root and the coinbase witness commitment cover different parts of the transaction data.

The coinbase transaction comes first

The first transaction in a Bitcoin block is the coinbase transaction.

It does not spend an earlier UTXO through ordinary inputs. Instead, its special input identifies it as coinbase and includes required or miner-chosen data. Under BIP 34, the block height is encoded at the beginning of the coinbase input's script data for applicable blocks.

The coinbase transaction can create outputs paying the block subsidy and collected transaction fees. The total output value may not exceed the amount allowed under the consensus rules for that block.

A miner may divide the permitted value among several outputs or use a template with particular destinations. The consensus rule concerns the allowed total and transaction validity, not one mandatory payout address.

Coinbase outputs are subject to a maturity rule. They can be spent only in a block whose height is at least 100 greater than the height of the block that created them.

Transaction fees are not separate block objects

Every non-coinbase transaction consumes input value and creates output value. When input value exceeds output value, the difference is the transaction fee.

The block's total fees are the sum of those differences for its included transactions. The coinbase transaction may claim up to the current block subsidy plus those fees.

There is no separate fee transaction added after the block. Fees are implicit in the included transactions and become claimable through the coinbase transaction.

A block can include transactions with different fee rates. Consensus does not require a miner to sort transactions from highest fee rate to lowest. Mining policy and dependencies determine practical selection.

Dependencies constrain transaction order

A transaction can spend an output created by an earlier transaction in the same block.

The parent must appear before the child so the output exists when the node validates the child. The coinbase transaction must be first, but other transaction ordering is largely shaped by these dependencies and the miner's chosen template policy.

A miner cannot include two transactions that spend the same output. It also cannot include a child before the in-block parent it depends on.

A candidate builder commonly selects related transactions as packages because a high-fee child may justify including a lower-fee parent. The final block still contains individually serialized transactions in a valid order.

Block weight limits the transaction set

SegWit introduced block weight as the main consensus accounting measure for block size.

Bitcoin's maximum block weight is 4,000,000 weight units. Witness bytes receive a lower weight than non-witness bytes under the defined formula.

The limit does not mean every valid block is four megabytes on disk or on the wire. Actual serialized size depends on the mix of witness and non-witness data. A block containing no discounted witness data reaches the weight limit at a much smaller serialized size than a witness-heavy block.

Candidate builders also reserve space and weight for the coinbase transaction, commitments, and safety margins. A template may remain below the theoretical maximum.

Weight is a consensus limit. Local mining policy may use additional limits, but nodes must accept a block that satisfies consensus even when its transaction mix would not match their own template policy.

Timestamps are constrained but not a precise clock

The block header contains a miner-selected timestamp measured in seconds.

Consensus applies contextual time rules. A block's timestamp must be greater than the median time of a defined set of previous blocks. Bitcoin Core also does not accept a header while its timestamp is more than two hours ahead of the node's current clock.

A block timestamp is not a trusted record of the exact moment the block was found. Miners have limited freedom within the valid range, and network arrival times differ.

Bitcoin's target spacing is ten minutes, but individual block intervals vary widely. The timestamp field does not turn that target into an exact schedule.

Proof of work covers the header commitment

Proof of work demonstrates that a valid header hash was found below the target.

Because the header includes the previous block hash and Merkle root, the proof is tied to a particular parent and committed transaction set. If the miner changes a transaction or coinbase field, the Merkle root or witness commitment path changes and the header work must be searched again.

Proof of work does not validate signatures, UTXO availability, block weight, coinbase value, or script execution. Nodes perform those checks separately.

An invalid block can have a hash below the target. Nodes enforcing the rules still reject it.

Nodes validate blocks independently

When a node receives a block, it checks multiple layers.

Header checks include:

• Proof of work satisfies the encoded target.
• The target is permitted for that height and network.
• The previous block is known or requested.
• Version and activation rules are satisfied.
• Time constraints are satisfied.

Block and transaction checks include:

• The transaction Merkle root matches.
• The coinbase transaction is present and first.
• No extra coinbase transaction appears.
• Transaction syntax and amounts are valid.
• Inputs exist and are unspent in the applicable state.
• Spending conditions and signatures are satisfied.
• Locktime and sequence rules are satisfied.
• Block weight and other consensus limits are respected.
• The coinbase claim does not exceed subsidy plus fees.
• Required witness commitments are valid.

The exact software path is more detailed, but the principle is stable: a miner proposes; a node verifies.

Relay can avoid sending every transaction again

A newly found block can be large enough that efficient propagation matters.

BIP 152 compact block relay lets peers announce a block using its header, short transaction identifiers, and a small set of prefetched transactions. A receiving node can reconstruct much of the block from transactions it already knows, then request what is missing.

Compact relay does not change block validity. It is a transport optimization. The reconstructed block must still pass the same checks as a fully transmitted block.

If reconstruction fails or transactions are missing, peers can request additional data or fall back to other relay behavior.

A valid block can still become stale

Two miners can find valid blocks that extend the same parent before either block has reached the entire network.

Different nodes may temporarily select different tips. As one branch gains more accumulated proof of work, nodes that learn about the stronger valid branch can reorganize to it.

A valid block that is not part of the ultimately selected chain is often called stale. Its coinbase outputs do not mature on the selected chain, and its transactions may return to unconfirmed status unless they also appear in the selected branch.

This does not mean the stale block was invalid. It means another valid branch became the selected history.

A block confirms transactions only on the selected chain

A transaction has one confirmation when it appears in a block on the node's selected chain. Each later block added to that chain increases its confirmation depth.

A reorganization can reduce or remove those confirmations. Bitcoin does not mark a transaction instantly immutable at first inclusion.

As depth grows, replacing that history generally requires more competing proof of work and becomes less practical under ordinary assumptions. The appropriate confirmation threshold remains contextual rather than universal.

A block is a validated link, not merely a batch

A concise block model has four parts:

1. A miner constructs a candidate linked to a parent.
2. The transaction set is committed through the Merkle root and, when required, a witness commitment.
3. Proof of work is searched over the header commitment.
4. Nodes independently validate the complete block and select among valid chains by accumulated work.

Blocks organize transaction settlement into verifiable steps. Their security does not come from trusting the miner, the pool, or a block explorer. It comes from commitments, proof of work, and independent validation under shared rules.