A Bitcoin block groups transactions with the information needed to verify them. Its header references the previous block, creating a historical record whose rules are enforced by network nodes.
Mining proposes new blocks; it does not give miners the power to invent valid transactions. To understand a confirmation, it is important to distinguish inclusion, verification and the accumulation of work on the chain.
In brief
- A block contains transactions and a header linking it to the historical record.
- A transaction in the mempool is not yet confirmed; its inclusion must comply with the network’s rules.
- Since SegWit, the relevant limit is four million weight units, not a uniform 1 MB size for every block.
What does a Bitcoin block contain?
To inspect the data actually recorded, a Bitcoin block explorer can display the block height, transactions and confirmations. However, it shows results provided by its operator and does not replace your own node.
Bitcoin’s technical documentation describes the header: version, hash of the previous block, Merkle root, timestamp, difficulty target and nonce. Transactions are linked to this header through a cryptographic structure.
The timestamp is not proof of the exact time of each payment. It is supplied by the block producer within the limits set by the protocol. A confirmation indicates inclusion in an accepted block, not independent certification of every economic fact that a transaction might refer to.
From the mempool to the first confirmation
A broadcast transaction may enter a node’s mempool, its local pool of pending transactions. There is no single global queue that all participants see in exactly the same way.
Miners build a candidate block, generally taking fees and their selection policies into account. The mining process then involves searching for a hash that meets the difficulty target.
This search proceeds through repeated hashing attempts, not by solving an equation with a magical result. Finding a proof of work does not exempt the block from the other rules: nodes reject a block containing an invalid spend.
Why blocks follow one another
Each header references the previous one. Changing data committed to an earlier block changes its hash, along with the references required by subsequent blocks. The historical record and accumulated work make such substitution costly.
Bitcoin’s original paper describes this construction and the competition between histories. Nodes select a valid chain according to cumulative work, not simply the one displaying the largest number of blocks without further verification.
Two blocks can occasionally be found almost simultaneously. One branch eventually receives more work and becomes the reference chain. This phenomenon, by itself, does not create a new cryptocurrency.
Confirmations reduce risk, but do not eliminate it
The first confirmation corresponds to a transaction’s inclusion in a block. Subsequent blocks increase the depth of that inclusion and the amount of work a competing history would have to catch up with.
The relevant number depends on the amount, the context and the recipient’s policy. A six-confirmation rule can serve as a convention, but it is neither a contractual assurance nor an absolute mathematical guarantee.
Significant computing power can be used to attempt reorganizations or censor certain transactions. It cannot be used to arbitrarily spend someone else’s bitcoins without satisfying their signature conditions. The distribution of participants and verification processes therefore remains important beyond hashing alone.
Since SegWit, capacity is measured in weight
Claiming that every Bitcoin block is uniformly limited to 1 MB oversimplifies the current rules. BIP 141 defines a maximum weight of four million units, with base data and witness data treated differently.
Effective size depends on the block’s composition. Four million weight units therefore do not mean that every block contains four million interchangeable bytes of ordinary transaction data.
Space remains limited, and fees reflect competition for that space in particular. A simple payment and a more complex operation do not necessarily occupy the same weight. The price of BTC does not, by itself, determine network capacity.
How to verify a payment without confusing speed with finality
Check the transaction ID, destination and amount, then determine whether the transaction is still pending or has already been included in a block. Follow the recipient service’s requirements before considering the settlement available.
The roughly ten-minute interval between blocks is an average, not a guaranteed appointment. Shorter or longer intervals are possible. The Lightning Network processes payments through a different architecture; a Lightning operation does not necessarily correspond to a new transaction being immediately recorded in a block.
A block therefore provides verifiable context for a transaction. Understanding its rules helps avoid two common mistakes: assuming that a broadcast payment is already settled, or treating every confirmation as an irreversible guarantee.
