Block

You send a bitcoin payment and your wallet initially says it is awaiting confirmation. The transaction spreads among nodes and may enter their mempools, local lists of unconfirmed transactions. A miner selects some transactions for a candidate block. If the miner finds the required Proof of Work (a mining result that meets the network’s rules) and nodes accept the block into the active chain, a payment inside it receives its first confirmation. The next block built on top raises the count to two. The average target is roughly ten minutes between blocks, not a promise that every payment will go through within ten minutes. [1] [3]

Every block has a short header and its transactions. Among other things, the header contains a cryptographic fingerprint of the preceding block—a reference that changes if that block’s data changes. Blocks therefore form a linked history rather than a loose pile of payments. Another fingerprint in the header summarizes that block’s transactions and is called the Merkle root. A miner repeatedly tries header variants until the hash, a numerical fingerprint, meets the difficulty target. This alone does not prove the payments are correct. A full node also checks signatures, spending authorization and other rules; valid Proof of Work cannot fix an invalid transaction. [1] [3]

The first transaction is called the Coinbase Transaction. In it, the miner may claim no more than the permitted new issuance plus fees from transactions included in the block. The node then checks ordinary transactions in order: existing unspent amounts leave the available funds and new ones are created. These separate amounts are called UTXOs. A payment may spend an earlier payment’s output in the same block if it meets all other conditions. The same output cannot be spent twice. The new coinbase reward cannot be spent immediately in this block: a special 100-block waiting rule applies. [1]

A block has no fixed number of payment slots. A simple transaction needs less data than a complex one, so different transaction counts can fill the same capacity. Since SegWit (an upgrade that changed how transaction data is stored and counted), capacity has been accounted for by weight, limited to 4,000,000 units—a technical way of counting data, not physical mass. Other rules apply as well. A miner need not fill all the capacity. A so-called empty block may omit ordinary payments, but still contains a coinbase. Empty therefore means neither transaction-free nor automatically invalid. [1] [2]

Sometimes two miners find blocks almost simultaneously, both extending the same predecessor. Both blocks may be valid but create competing branches. A node chooses among valid branches by total proven work, not by a simple vote or block count alone. Switching to another branch is a reorganization. A payment in the abandoned block may lose confirmations; if still valid and absent from the new branch, it may await inclusion again. Further confirmations generally increase confidence, but are no mathematical promise of irreversibility. For technical reference, a header is 80 bytes. The Merkle root is a fingerprint calculated from the transaction identifiers, called txids, in their block order. SegWit witness data, such as signatures needed to verify spending, has an additional cryptographic fingerprint recorded through the coinbase. These links let a node check that the supplied data belongs to the block. [1] [2]