Bitcoin mining is often reduced to a picture of machines racing to solve a puzzle. That image captures the competition, but it hides the actual workflow.
Mining brings together several distinct jobs. Software gathers transaction information, constructs a candidate block, creates a coinbase transaction, and prepares a block header. Hashing hardware repeatedly evaluates versions of that header. When a result satisfies the target, the block is broadcast. Nodes then validate the block independently.
The miner proposes the next block. The network does not accept that proposal merely because energy was spent producing it.
Mining begins with a candidate block
A candidate block is a proposed batch of transactions linked to the current chain tip.
A block assembler may begin with transactions available in a node's local mempool. That mempool is not a universal network queue. Different nodes receive transactions at different times, apply different policy settings, and may store different sets of unconfirmed transactions.
A mining operator can also receive valid transactions through direct submission, private relay, or another permitted source. A transaction absent from one public node's mempool can still be included in a valid block if it satisfies the consensus rules and all required dependencies are available.
Block construction therefore starts from the operator's available information, not from one official list maintained by the protocol.
Transaction selection follows several constraints
A block assembler chooses transactions subject to more than one consideration.
Every included transaction must be valid in the candidate block's context. Inputs must refer to spendable outputs, required scripts and signatures must verify, locktime and sequence conditions must be satisfied, and dependencies must appear in a usable order. The completed block must also respect weight, signature-operation, and other consensus limits.
Fees matter because the miner can claim transaction fees from included transactions. Selection can also reflect ancestor and descendant relationships, operator policy, direct agreements, block-template software, transaction ordering preferences, or a decision to leave some block space unused.
Bitcoin Core's block assembler normally works from its local mempool and evaluates groups of related transactions under configured limits and fee settings. Other mining systems can construct templates differently. Bitcoin does not require every miner to use one implementation or identical transaction-selection policy.
The coinbase transaction comes first
The first transaction in a valid block is the coinbase transaction.
Its input does not spend a previous UTXO. Instead, the coinbase transaction can create outputs whose total value is no greater than the permitted block subsidy plus the transaction fees available from the other transactions in the block.
The subsidy and fees are separate components. The subsidy creates new bitcoin under the issuance schedule. Fees are existing input value not reassigned to ordinary transaction outputs.
A miner may claim less than the maximum allowed amount, but claiming more makes the block invalid to nodes enforcing the rule. Proof of work cannot repair an excessive coinbase claim.
Coinbase outputs also have a consensus maturity requirement. They cannot be spent until a transaction using them appears in a block whose height is at least 100 greater than the height of the block that created them. A reorganization can change active-chain depth and therefore change whether a wallet currently treats a coinbase output as mature.
The transaction set produces a Merkle root
The candidate block's transactions are organized into a Merkle tree. The Merkle root is a compact commitment to the transaction set inside the block.
If any transaction changes, the Merkle root changes. The coinbase transaction is part of that set, so changing coinbase data also produces a different Merkle root.
This property is useful for mining. The 32-bit nonce field in the block header provides a limited search space. High-speed hardware can exhaust that space quickly. Mining software can change data in the coinbase transaction, including an extranonce area used by many mining systems, rebuild the Merkle root, and create a fresh range of candidate headers.
Changing the selected transactions can do the same. The candidate block remains subject to all block-validity rules after each change.
The block header has six serialized fields
Bitcoin proof of work is performed over the serialized 80-byte block header.
The header contains six fields:
- A version field.
- The hash of the previous block header.
- The Merkle root committing to the transaction set.
- A timestamp field.
- The proof-of-work target encoded in compact
nBitsform. - A nonce.
The previous-block hash links the candidate to prior chain history. The Merkle root commits to the block's transactions. The timestamp must satisfy applicable constraints. The compact target tells nodes which proof-of-work threshold applies. Version bits can communicate defined software or deployment information. The nonce is one value miners can vary during the search.
The header does not contain full transaction data, but its Merkle root binds the proof-of-work search to that candidate transaction set.
Mining hashes the header twice with SHA-256
Bitcoin proof of work applies SHA-256 twice to the serialized block header.
Mining hardware repeatedly evaluates candidate headers and compares the resulting 256-bit hash with the applicable network target. A valid result is numerically less than or equal to that target.
The hash does not decrypt transactions, approve ownership, or solve an equation with a reusable shortcut. For mining purposes, small changes to the header produce results that behave unpredictably. A miner cannot look at one failed result and learn which nearby nonce is closer to success.
Failed attempts do not accumulate partial progress toward a future valid hash. Each candidate either satisfies the target or it does not.
The work is easy for a node to verify after the fact. A node hashes the header and checks the result against the target. Producing a valid result may require an enormous number of attempts, but verifying that one result is straightforward.
Miners search more than the nonce field
The nonce is the most visible changing field, but it is not the only available source of search space.
Mining systems may vary:
- The nonce.
- Extranonce data in the coinbase transaction.
- Permitted timestamp values.
- Version-related fields where allowed.
- The transaction set or ordering.
- Other coinbase data that remains valid.
Changing coinbase data changes the coinbase transaction identifier and Merkle root. That creates a different header even when the previous-block hash and other fields remain the same.
Pools and mining proxies often divide this larger search space among many devices so they are less likely to duplicate work. Solo miners can use similar techniques through their own software stack.
The exact work-distribution design belongs to the mining system. Bitcoin consensus cares about the resulting block and header, not the internal method used to assign candidate hashes.
Block discovery is probabilistic
A valid hash can appear on the first attempt or after a long run of failures.
If a miner controls a given share of the total hashing work being applied to the network, its expected share of discovered blocks over a sufficiently long period is related to that hashrate share. Short periods can vary widely.
A miner with one percent of estimated network hashrate is not promised exactly one percent of blocks in each day, week, or difficulty period. Random variation can produce streaks and dry periods.
No individual miner receives a scheduled block time. Bitcoin targets an average block interval across the network over time. Actual block arrivals remain irregular.
This variance is one reason mining pools exist. Pools coordinate work and use internal accounting to distribute payouts more frequently than most small solo miners would discover blocks on their own. Pooling changes payout variance and dependencies. It does not change Bitcoin's block-validity rules.
Hashrate is estimated, not read from a global meter
Hashrate describes the rate of proof-of-work hash attempts.
An individual device can report its own measured or configured rate. Network hashrate is different. Bitcoin does not contain one global meter that counts every attempt performed by every miner.
Software estimates network hashrate from observed blocks, their proof-of-work requirements, and elapsed time. The estimate depends on the observation window and the irregular timing of block discovery. Short windows can be noisy. Longer windows smooth more variation but respond more slowly to change.
The estimate also does not reveal exactly how many machines, owners, facilities, or geographic locations produced the work. Different hardware can contribute different rates, and operational arrangements can separate equipment ownership from pool or template coordination.
A found block is a proposal
When a miner finds a header hash satisfying the target, the mining system assembles and broadcasts the corresponding full block.
Peers do not accept it automatically. A validating node checks matters such as:
- The proof-of-work target and header hash.
- The required target for that height.
- The link to known prior chain state.
- The Merkle root and transaction commitments.
- Block weight and structure.
- Every included transaction.
- Input availability and spending conditions.
- The coinbase amount and maturity-related rules.
- Applicable consensus deployments and script rules.
If any required rule fails, the node rejects the block. More proof of work cannot make an invalid block valid to that node.
A node only activates a candidate chain after validating the required blocks. Among valid candidate chains, accumulated proof of work guides chain selection under that node's rules. Mining contributes to chain ordering, but it does not give miners unilateral authority to redefine validity.
Mining is not transaction approval
Mining affects when valid transactions may be included and how chain history is extended.
It does not establish a person's legal ownership. It does not make an invalid signature valid. It does not permit miners to create arbitrary bitcoin. It does not encrypt transaction contents.
A miner can omit a valid transaction from one candidate block. Another miner may include it later. A miner can receive a transaction through a route other nodes did not see. That flexibility exists inside the boundary of block validity.
Mining is therefore best understood as competitive block production under rules that nodes independently enforce.
Hardware, software, pools, and nodes have separate roles
A mining operation can contain several components.
A full node validates chain and transaction data and can provide a candidate template. Block-assembly software chooses valid transactions and creates the coinbase and header fields. A pool coordinator may distribute jobs and account for contributed work. ASIC hardware performs high-rate header hashing.
One machine or software package can combine several roles, but the roles remain conceptually distinct.
An ASIC miner does not replace a full node merely because it produces hashes. A pool is not the Bitcoin consensus system merely because it coordinates substantial work. A node is not a hashing device merely because it can prepare a block template.
Separating the roles makes concentration and failure questions more precise. Hardware ownership, pool coordination, transaction-template control, node validation, and payout dependence are different dimensions.
Mining uses energy and produces heat
Hashing hardware consumes electrical energy. Almost all of the electrical power used by the equipment ultimately becomes heat that must be handled by the operating site.
The source of electricity, machine efficiency, cooling design, climate, utilization, curtailment, transmission conditions, and supporting infrastructure vary. Those differences affect cost and environmental outcomes.
It is inaccurate to claim that all Bitcoin mining uses one energy source or creates one universal environmental result. It is equally inaccurate to discuss hashrate as if it required no physical resources.
A responsible analysis states what is being measured, identifies system boundaries, and separates energy use from claims about emissions or benefits that require additional evidence.
Difficulty adjustment and halving are separate
If aggregate hashing conditions change, block intervals may become shorter or longer before the next difficulty boundary.
Bitcoin's difficulty adjustment later changes the proof-of-work target under its own consensus rules. The adjustment does not continuously poll miners or guarantee exact ten-minute blocks.
The halving is different. It changes the permitted block subsidy at 210,000-block intervals. It does not directly change the proof-of-work target.
Mining economics can respond to both mechanisms, along with fees, energy costs, hardware efficiency, and market conditions. Bitcoin does not guarantee a particular miner's profitability or response.
Solo and pooled mining use the same validity rules
A solo miner coordinates its own template construction, hashing, and block submission. A pooled miner contributes work through a coordination and payout system.
The payout experience can be very different. Solo discovery is highly variable for a small miner. A pool can distribute revenue according to submitted shares and its chosen payout rules.
The network-facing block must satisfy the same consensus rules either way. Nodes do not validate a block differently because it came from a pool, a company, or a solo operator.
The next guide explains how mining pools assign work, measure shares, submit blocks, and distribute payout risk without becoming Bitcoin consensus authorities.