What Is Bitcoin Mining?

In brief

Mining combines two related jobs:

1. Block construction: choose valid transactions, order them, create a coinbase transaction, and commit to the transaction set with a Merkle root.
2. Proof-of-work search: vary the 80-byte block header and double-SHA-256 it until the resulting number is at or below the current target.

Finding a qualifying hash does not bypass validation. Full nodes independently check the proof of work, every transaction, the coinbase amount, block limits, and other consensus rules. A valid block then competes to become part of the chain with the most accumulated work.

Solo miners can construct and submit their own blocks. In pooled mining, the pool operator, template provider, and hashing participant may perform different parts of the job. Traditional pool arrangements often let the operator select transactions and receive the coinbase, while participants prove contributed work with easier-to-find shares. Newer protocols can give individual participants more control over transaction selection.

The live Proof of work article explains the consensus algorithm and accumulated-work rule. This article focuses on the operational role, block-building pipeline, pool relationships, revenue, and limits on miner authority.

From transactions to a candidate block

A miner or pool usually obtains transactions from a full node’s mempool, private order flow, or both. It decides which valid transactions to include and in what order. Fee rate matters because block space is limited, but miners are not required to include every high-fee transaction or any non-coinbase transaction at all.

The candidate block contains:

• a coinbase transaction as its first transaction;
• zero or more ordinary transactions;
• a Merkle tree committing to those transactions;
• an 80-byte header containing the version, previous block hash, Merkle root, timestamp, compact target, and nonce.

The coinbase may create outputs up to the permitted subsidy plus the fees implicit in the included transactions. Fees are the difference between ordinary transaction inputs and outputs; they are not newly issued coins. A block that overclaims its available reward is invalid.

Bitcoin Core’s getblocktemplate RPC exposes the data needed to construct a block, including candidate transactions, their dependencies and fees, the previous block hash, target, height, and maximum coinbase value. BIP 22 deliberately leaves miners or mining software able to inspect and, within the rules, modify the candidate rather than treating a server-provided header as unquestionable.

Searching the header

Mining hardware hashes only the 80-byte header, not the full block on every attempt. The dedicated 32-bit nonce is one changeable field, but modern hardware exhausts that range quickly. Mining software changes extra-nonce data in the coinbase, rebuilds the affected Merkle root, and can update other permitted header fields to create fresh search space.

Each distinct header hash is effectively another random draw. A result is valid when interpreted as a number no greater than the target. More hash rate gives a miner more draws per second and therefore a larger expected share of future blocks; it never guarantees the next win.

Difficulty retargets every 2,016 blocks toward a two-week interval at the observed hash rate. Individual blocks remain irregular. Mining is a probabilistic race, not a ten-minute timer assigned to a specific machine.

When a miner finds a network-valid hash, it combines the header with the candidate block and submits or broadcasts the full block. Other nodes validate it. If two valid blocks appear near the same time, both may briefly have followers; miners then choose which valid tip to extend, and the branch that accumulates more work normally wins. A found block can therefore become stale, which is one reason mining income has variance.

Solo mining versus pooled mining

In solo mining, one operator bears the full variance. If it finds a block that survives, it receives the reward; if it finds none for a long period, it receives nothing from mining.

A mining pool coordinates work and distributes payouts. The pool gives participants a target that is easier than Bitcoin’s network target. A header below this pool target is a share: it is usually not a valid Bitcoin block, but it demonstrates a measurable amount of attempted proof of work. Occasionally a share also meets the harder network target and produces a block.

Roles in a conventional pool can include:

• Pool operator: runs coordination infrastructure, tracks shares, applies a payout method, and may bear short-term variance.
• Template provider: chooses the transactions and constructs the job participants hash.
• Hashing participant: operates ASIC hardware and submits shares.
• Full node: validates the chain tip and candidate data; it may be run by the pool, participant, or both.

These roles are often bundled, but they are not synonyms. Owning ASICs does not necessarily mean choosing transactions. Operating a pool does not mean owning all connected hash power.

Under commonly deployed Stratum v1 arrangements, the pool typically controls the template and coinbase, making it a potential transaction-selection and censorship bottleneck. Bitcoin Optech documents how Stratum v2 can allow individual pool members to choose transactions, although support for advanced features is not universal. Pool design therefore affects who exercises block-template power.

Payout methods also move risk around. Pay-per-share schemes can pay for submitted shares before the pool actually finds a block, placing variance and capital requirements on the operator. Pay-per-last-N-shares distributes actual found rewards and leaves more variance with participants. “The pool found the block” is operational shorthand; a particular participant’s hardware usually found the qualifying header.

What miners control

Within consensus and their chosen pool protocol, miners or template providers can:

• choose which valid transactions to include;
• order transactions;
• mine an otherwise valid empty block;
• choose which valid chain tip to extend;
• decide what fee rates and policies are economically acceptable;
• signal readiness for some proposed upgrades, where the activation design uses miner signaling.

This gives miners real censorship and ordering power, especially when template construction is concentrated. It is not unlimited: excluded transactions may be included by another miner, and users or node operators do not have to accept invalid blocks.

What miners cannot do alone

Hash power cannot make an invalid block valid to an unchanged full node. Miners cannot unilaterally:

• create more subsidy than the rules permit;
• spend a UTXO without satisfying its script;
• make a block exceed consensus limits;
• confiscate arbitrary coins;
• force full nodes to adopt new consensus rules.

A majority-hash-rate attacker can attempt to censor transactions, reorganize recent valid history, or double-spend its own coins. It still must produce blocks that the targeted nodes consider valid. This is why “miners secure Bitcoin” is incomplete: miners supply proof of work and order transactions, while full nodes enforce the rule set they run.

Revenue, cost, and the security budget

The successful block’s available reward is:

subsidy + transaction fees

The subsidy follows the halving schedule. Fees depend on demand for block space and the chosen transaction set. Pools then distribute proceeds according to their contracts and payout methods; a participant’s payout is not necessarily the coinbase amount.

ASICs, facilities, electricity, cooling, networking, financing, and maintenance are miner costs. The protocol does not prescribe a power budget or energy mix. “Security budget” usually refers to subsidy and fees available to reward block production, not electricity consumption itself. Competition links revenue to expenditure, but they are not the same measurement.

Mining, nodes, and wallets

• A wallet constructs and signs transactions and tracks keys.
• A full node independently validates and relays transactions and blocks.
• A miner constructs or hashes candidate blocks.
• A pool coordinates work and payouts across miners.

One organization may run all four, but Bitcoin does not require ordinary users to mine. A miner that does not independently validate can rely on a pool’s or another operator’s chain view; its resulting blocks are still accepted only if validating nodes consider them valid.