Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£857.29
EST. MONTHLY
206
DAYS
EST. ROI
A Bitcoin block is a package of transactions plus a compact header that links it to earlier Bitcoin history. Miners compete to produce proof of work for a candidate block. Full nodes then check every transaction and rule before accepting it.
Blocks give Bitcoin an order. Without them, two valid-looking payments could try to spend the same funds and different computers might disagree about which came first. A block is not just a box of payments; it is a checked step in a chain of accumulated work.
Estimated reading time: 7 minutes
TL;DR
- A block contains a header and one or more transactions, starting with a coinbase transaction.
- Its header commits to the previous block and a Merkle root representing the included transactions.
- A payment gains confirmations when later valid blocks build on the block containing it.
What This Means in Simple English
A Bitcoin block is one numbered page in a shared ledger. It lists a batch of valid payments, points back to the previous page and carries proof that a miner performed difficult work. Nodes check the whole page before adding it to their copy.
Simple Example
A cashier closes a till period, seals its receipts in a numbered box and writes the previous box's seal number on the new lid. Changing an old receipt would break that box's seal and every later reference.
Key Terms in Plain English
| Block Header: | The compact set of fields hashed by miners. |
|---|---|
| Previous Block Hash: | The link to the preceding accepted block. |
| Merkle Root: | One hash committing to all transactions in the block. |
| Coinbase Transaction: | The first transaction, which claims permitted subsidy and fees. |
| Confirmation: | A block added at or after the block containing a payment. |
What a Bitcoin Block Contains
The block header is 80 bytes and includes a version, previous block hash, Merkle root, time, difficulty target representation and nonce. The body contains transactions encoded under the protocol rules.
The first transaction is special. It creates the allowed subsidy and claims fees from the other transactions. Its spendable output must mature for 100 further blocks before it can be used.
How Transactions Enter a Block
Nodes receive transactions, check policy and consensus conditions, then may hold them in a mempool. A mining pool or template provider selects valid transactions, commonly considering fees and dependency order.
A miner is not required to include every waiting transaction. Capacity, fee rate, relationships between transactions and local policy affect selection. A payment can remain unconfirmed even though nodes have seen it.
How the Header Links History
The previous block hash makes each accepted header point to its parent. Changing the earlier header produces a different hash, so the next block's stored link would no longer match.
An attacker trying to replace an old transaction must build an alternative valid history and catch the honest chain's accumulated proof of work. Each later block raises the work barrier.
What the Merkle Root Proves
Transaction identifiers are paired and hashed repeatedly until one Merkle root remains. That root goes into the header miners hash. Changing an included transaction changes its path and normally changes the root.
A Merkle proof can show that a particular transaction is included without sending every transaction in the block. Full nodes still validate the complete block they accept.
Why Blocks Do Not Arrive on a Timer
Bitcoin targets an average interval of about ten minutes, but proof of work is probabilistic. Two blocks can appear close together or the network can wait much longer than ten minutes.
Difficulty adjusts every 2,016 blocks to respond to changing network hashrate. The target concerns long-run network timing, not a personal miner's payout schedule.
What a Confirmation Means
A transaction has one confirmation when it sits in an accepted block. Each valid block built after it adds another confirmation. More accumulated work generally makes replacement harder.
There is no universal safe number for every payment. Value, risk, service policy and unusual network conditions matter. A receiver should not call an unconfirmed display final merely because a wallet has seen it.
What Happens When Two Blocks Compete
Two miners can find valid blocks at nearly the same time. Nodes may initially see different tips. Miners build on one branch, and the chain with the most accumulated proof of work normally becomes the accepted history.
Transactions from a stale block may return to mempools if they remain valid and were not included elsewhere. The stale miner's coinbase reward does not survive on the accepted chain.
How to Inspect a Block Carefully
Use a node or reputable explorer to check block height, header hash, previous hash, transaction count, timestamp, weight, reward and fees. Explorer labels are a presentation of data rather than consensus authority.
For operational decisions, compare more than one source and record the block hash, not only its height. Competing blocks can briefly share a height, while the header hash uniquely identifies the block.
Save the time and source of an observation when it supports a payment or mining decision. A later chain tip can add confirmations or replace a short competing branch, so an undated screenshot is weak evidence.
What the Current Data Can and Cannot Tell You
Block explorers update continuously and may differ briefly around a new tip. A local fully validated node provides the operator's own view.
A block timestamp is miner supplied within rule limits and is not a precision clock for a payment or legal event.
Fee totals and block fullness change with demand. One unusually large or small block should not be treated as a lasting network pattern.
Decision Table
| Block Part | Purpose |
|---|---|
| Header | Carries the fields committed by proof of work |
| Previous Hash | Links the block to its parent |
| Merkle Root | Commits to included transactions |
| Transactions | Record valid spends and new outputs |
A table is a starting point, not a promise. Verify current official sources and apply each detail to the decision you are actually making.
Frequently Asked Questions
How Big Is a Bitcoin Block?
Bitcoin applies weight rules rather than one simple file-size number. Transaction composition changes the byte size.
Is a Block Produced Every Ten Minutes?
Ten minutes is a long-run target, not a fixed schedule.
Can a Miner Put an Invalid Payment in a Block?
It can propose one, but full nodes enforcing the rules reject the block.
What Is the First Transaction in a Block?
The coinbase transaction claims the allowed subsidy and transaction fees.
Are Block Height and Block Hash the Same?
No. Height is a position; the hash uniquely identifies a particular header.
Conclusion
A Bitcoin block is a checked batch of transactions joined to earlier history by hashes and proof of work. Miners propose it, but full nodes decide whether it follows the rules. Understanding headers, Merkle roots, competition and confirmations makes wallet and mining information much easier to judge.
Sources and Further Reading
Continue with our Bitcoin mining beginner guide, Bitcoin Core and node articles and Bitcoin and SHA-256 mining library.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.