Skip to content
Financial Context Wiki

Bitcoin Mining: Block Templates, Proof of Work, Pools, and Economics

Bitcoin mining constructs candidate blocks and searches SHA-256d header space for proof of work below the network target. Analyze template identity, transaction and coinbase validity, nonce and extranonce search, full-node validation, propagation, stale-block risk, pool shares, payout rules, difficulty, energy and operating economics separately.

Updated

Educational protocol and mining analysis only; not investment or operating advice. Mining outcomes are random and depend on network rules, difficulty, fees, pool terms, uptime, hardware, energy, financing, tax and market prices; projected revenue or hash share does not guarantee blocks, payouts or profit.

Direct answer

Bitcoin mining is the process of constructing valid candidate blocks and repeatedly hashing their 80-byte headers with SHA-256d until a result is numerically at or below the consensus target. A successful miner proposes the block to the network. Mining does not make invalid transactions valid, decide truth outside the protocol or give the miner authority over other users’ coins: every full node independently checks the proof of work, header, transactions, scripts, spent outputs, block limits and permitted coinbase amount.

A mining node or pool obtains candidate data through interfaces such as getblocktemplate. Relevant fields include version, previousblockhash, transactions, coinbasevalue, target, bits, height, weightlimit and sigoplimit. The template is a policy-selected starting point, not a promise that every listed transaction must be included or that a modified block will be accepted. Consensus validity, local mempool policy, fee selection and pool rules are distinct layers.

Mining hardware searches header variations. After the 32-bit nonce range is exhausted, mining software changes coinbase extranonce data, rebuilds the Merkle root and may update allowed time or version fields to create new header space. Each hash is an independent trial. More compatible hashrate increases expected success frequency but does not schedule a particular block or guarantee a result within any deadline.

Solo mining assigns the entire valid block’s permitted coinbase output to the solo miner but has high payout variance. Pool mining aggregates work and uses easier share targets to estimate contributions; only a share that also meets the network target can become a block. A pool can reduce payout variance, not increase the network’s total expected issuance. Pool custody, template control, share validation and PPS, PPLNS or other payout liabilities introduce separate counterparty and concentration risks.

How to analyze mining

  1. Fix identity and authority. Record chain, network, client version, rule set, bestblockhash, template provider, pool endpoint, payout identity and observation time. Distinguish the node, template builder, pool operator, firmware, facility and equipment owner.
  2. Reproduce candidate selection. Snapshot the mempool and UTXO set; verify transaction validity, dependencies, fees, weight, signature-operation cost, locktime and witness commitments. Rebuild the candidate and explain policy choices rather than treating fee rate alone as consensus.
  3. Reconcile the coinbase and header. Verify subsidy height, total included fees, outputs, commitments, previous hash and Merkle tree. Track mutable nonce, coinbase extranonce, Merkle root, time and version bits, and reject any template exceeding consensus limits.
  4. Verify proof search and submission. Decode the compact target and test block_hash <= target using the network’s byte-order and hashing rules. On a solution, reconstruct the full block, submit it through submitblock or the deployed protocol and retain acceptance or rejection evidence.
  5. Trace independent validation and propagation. Compare multiple full nodes for header, transaction, script, coinbase and chainwork validation. Measure propagation, competing tips, stale or orphan outcomes and reorganization handling; finding a proof is not the same as remaining canonical.
  6. Reconcile reward and pool accounting. Separate coinbase, subsidy + transaction fees, pool fees, pool reserves, pool target, network target, accepted share, stale shares, payout method, maturity, minimum payout, custody and counterparty exposure.
  7. Model economics and security under stress. State effective hashrate, uptime, efficiency, power price, cooling, labor, hosting, maintenance, depreciation, financing, tax, curtailment, subsidy, fees, price and difficulty. Stress block variance, hardware failure, price and fee shocks, difficulty lag, pool default, censorship, concentration and reorganization risk.

The work product is a block proposal plus evidence of computational search. Nodes decide validity; the fork-choice rule decides which valid branch is active; the difficulty rule changes the target only at its defined boundary; and applications decide how much confirmation depth they require. Mining participates in all of these processes but is not a substitute for any of them.

Worked examples

1. Nonce space is not the whole search space

An 80-byte Bitcoin header has a 32-bit nonce, giving 2^32 = 4,294,967,296 values. At 200 TH/s, hardware could test that many headers in approximately:

4,294,967,296 / 200,000,000,000,000 = 0.0000214748 seconds

This does not end the job. Mining software changes the coinbase extranonce, derives a new Merkle root and may update other permitted fields, producing another nonce space. Treating the header nonce as a machine’s total search capacity is therefore a category error.

2. Solo variance and electricity

With network rate 600 EH/s and effective miner rate 200 TH/s, the simplified share is 200 TH/s / 600 EH/s = 0.0000333333%. At an illustrative 144 blocks per day, expected solo blocks are lambda = 144 * 0.000000333333 = 0.000048 blocks/day, or a mean wait of 1 / 0.000048 = 20,833.33 days. A Poisson approximation gives a daily zero-block probability of P(0) = exp(-0.000048) = 99.9952001152%.

A 3.5-kW machine at USD 0.06 per kWh costs 3.5 kW * 24 * USD 0.06/kWh = USD 5.04/day in direct electricity. That excludes cooling, hosting, downtime, repairs, depreciation, financing and tax. Expected value is not cash-flow timing, and a low-probability solo win must not be presented as a daily receivable.

3. Coinbase accounting and maturity

Suppose the height-specific subsidy is 3.125 BTC and valid included transaction fees total 0.42 BTC. The maximum value created by the coinbase transaction in this simplified example is 3.125 + 0.42 = 3.545 BTC; claiming more makes the block invalid, while claiming less is permitted but forfeits value.

Coinbase output is subject to a consensus maturity of 100 blocks before it can be spent. The block can also become stale or later be reorganized before maturity. A pool dashboard balance, an immature coinbase output and a final external payout are therefore different claims with different custody and settlement risks.

4. Pool shares and payout assumptions

Assume equal-difficulty accepted shares: the pool records 2,000,000 total and one miner contributes 50,000, so the credited fraction is 50,000 / 2,000,000 = 2.5%. If the block value is 3.545 BTC and the pool fee is 2%, the illustrative distributable amount is 3.545 * (1 - 0.02) = 3.4741 BTC, and a proportional allocation is 3.4741 * 2.5% = 0.0868525 BTC.

If the pool target is 1,000 times easier than the network target, an accepted share has a simplified 1 / 1,000 chance of also meeting the network target. Real accounting must normalize variable share difficulty, reject duplicates and stale work, apply the named PPS, FPPS, PPLNS or other contract, and distinguish pool-paid expected value from block-contingent revenue.

Risks and review failures

Protocol and template errors

  • Saying miners make transactions valid rather than select candidates that full nodes independently validate.
  • Mixing chain, network, fork, tip, client, template-provider or pool identities.
  • Treating a mempool or template as consensus state, a complete transaction set or a guaranteed future block.
  • Selecting transactions by individual fee rate while ignoring ancestors, descendants, weight, signature operations, locks and commitments.
  • Miscomputing the subsidy height, included fees, coinbase outputs, witness commitment or Merkle root.
  • Searching the wrong previous hash, stale target or unauthorized time and version ranges after a new tip arrives.
  • Comparing a header hash to the displayed target with incorrect encoding, endianness or algorithm.

Pool and operational errors

  • Equating an accepted pool share with a network-valid block or using share counts without normalizing difficulty.
  • Converting expected hash share into guaranteed blocks, revenue or payout dates while ignoring variance.
  • Treating pool block share as permanent hardware ownership or ignoring template and payout concentration.
  • Omitting stale and rejected shares, latency, firmware, temperature, uptime, curtailment and hardware failures.
  • Ignoring payout method, fee basis, reserves, minimums, maturity, custody, withdrawal and pool-default terms.
  • Treating a found block as final before independent acceptance, propagation, canonical selection and reorganization review.
  • Reusing credentials, payout addresses or remote firmware without authentication, change control and incident response.

Economic and security errors

  • Calling gross BTC expected value fiat profit without price, difficulty, fees, power, cooling, labor, depreciation, financing and tax.
  • Inferring electricity or emissions from hashrate alone without device efficiency, utilization, cooling, location, time and energy mix.
  • Assuming difficulty responds immediately to hashrate or that ten-minute blocks arrive on a schedule.
  • Claiming a halving guarantees price appreciation, miner capitulation or unchanged security spending.
  • Claiming majority hash power can forge signatures, seize arbitrary coins or make full nodes accept invalid inflation.
  • Treating high aggregate hashrate as proof against pool, manufacturer, firmware, geography, energy, network or software concentration.

Common misconceptions

  • Miners approve whatever transactions they want as valid. They choose and order candidates, but honest full nodes reject blocks that violate consensus.
  • The nonce is the only value miners can change. Extranonce changes the coinbase and Merkle root, while time and permitted version fields can also expand search space.
  • A pool share is a fraction of a block. It is evidence meeting an easier pool target; most shares do not meet the network target and never become blocks.
  • Expected daily revenue is a guaranteed payment. Block discovery is random, and payout timing also depends on the pool contract, maturity and counterparty performance.
  • More hashrate automatically means more profit. A miner’s share, difficulty, fees, price, efficiency, power and full cost structure determine the result.

Sources

Navigation

Search the wiki...