Mining and Consensus in Bitcoin

Overview

The term "mining" can be misleading. By analogy to precious metal extraction, it draws attention to the reward—the creation of new bitcoins with each block. While this reward incentivizes mining, its primary purpose isn't the issuance of new coins. Viewing mining solely as a currency creation process misidentifies the incentive as the goal. Instead, mining is the foundational mechanism enabling decentralized transaction validation and settlement. It's the security innovation that makes Bitcoin unique—a trustless, peer-to-peer digital cash system secured through decentralized consensus.

Newly minted coins and transaction fees serve as incentives aligning miner behavior with network security while managing monetary supply. Miners confirm transactions and record them on the global ledger. On average, a new block containing recent transactions is added to the blockchain every 10 minutes, confirming those transactions and allowing recipients to spend the received bitcoins.

Miners earn two types of rewards for securing the network: newly created bitcoins per block and transaction fees from all transactions included in that block. To claim these rewards, miners compete to solve a cryptographic puzzle based on a hash algorithm—this solution is called Proof-of-Work (PoW). The successful miner gains the right to add the block and receive the reward. This competitive process forms the core of Bitcoin's security model.

👉 Discover how blockchain security works and how you can participate

Mining mimics diminishing returns, similar to precious metal extraction. Bitcoin's supply is created through mining, much like central banks issue currency by printing money. Approximately every four years—or precisely every 210,000 blocks—the number of new bitcoins a miner can earn per block halves. Starting at 50 BTC per block in January 2009, it halved to 25 BTC in November 2012, then to 12.5 BTC in July 2016. This halving continues exponentially until around 2140, when all 21 million bitcoins will have been issued. After that point, no new bitcoins will be created.

Miners also earn transaction fees. Each transaction may include a fee, calculated as the difference between input and output values. The winning miner collects these fees as "change." Currently, fees represent less than 0.5% of miner revenue, with most income coming from block rewards. However, as block rewards decrease over time and transaction volume increases, fees will gradually become the dominant source of miner income. By 2140, when no new bitcoins are issued, mining will be sustained entirely by transaction fees.

This chapter first examines mining as a monetary policy mechanism, then explores its most crucial function: enabling decentralized consensus that secures Bitcoin.

Bitcoin Economics and Coin Creation

New bitcoins are issued at a fixed and decreasing rate with each block creation—approximately one block every 10 minutes generates new coins from nothing. Every 210,000 blocks (roughly four years), the issuance rate drops by 50%. During the first four years of operation, each block contained 50 new bitcoins.

In November 2012, issuance dropped to 25 BTC per block. In July 2016, it decreased again to 12.5 BTC. It halved once more to 6.25 BTC around 2020 at block 630,000. This halving process will repeat 32 times until reaching the smallest unit—a satoshi—at around block 6,720,000 (approximately 2137). By 2140, nearly 21 million bitcoins (2,099,999,997,690,000 satoshis) will be in circulation. Beyond this point, blocks will contain no new coins, and miners will rely solely on transaction fees.

This geometrically decreasing supply ensures a fixed monetary cap resistant to inflation. Unlike fiat currencies where central banks can print unlimited money, Bitcoin’s supply cannot be inflated by design.

Decentralized Consensus

Bitcoin’s blockchain serves as a global public ledger—a universally recognized record of ownership across the network. But how do participants reach agreement on this "truth" without trusting any central authority?

Traditional payment systems rely on trusted third parties to validate and clear transactions. Bitcoin eliminates central control: every full node maintains an authoritative copy of the ledger independently. The blockchain isn’t created by a central entity but assembled autonomously by each node across the network. Despite receiving messages over an untrusted network, all nodes arrive at identical conclusions and build matching ledgers.

Satoshi Nakamoto’s key invention was emergent consensus—a decentralized mechanism where agreement arises organically rather than being explicitly negotiated or voted upon. This spontaneous outcome emerges from thousands of independent nodes interacting asynchronously under simple rules.

Bitcoin’s defining properties—digital currency, secure transactions, trustless payments—are all rooted in this innovation.

Decentralized consensus results from four processes operating independently across network nodes:

• Independent transaction verification based on comprehensive validity criteria
• Aggregation of transactions into candidate blocks by miners using PoW
• Independent validation of new blocks and integration into local blockchain copies
• Selection of the chain with the greatest cumulative work via PoW

These processes collectively enable spontaneous network-wide agreement, allowing each node to construct its own trusted version of the global ledger.

Independent Transaction Validation

Before propagation, every node verifies incoming transactions against strict criteria to prevent invalid data from spreading. Only valid transactions are forwarded; others are discarded immediately.

Each node checks multiple conditions:

• Correct syntax and data structure
• Non-empty input/output lists
• Size under MAX_BLOCK_SIZE
• Output values within acceptable range (greater than dust threshold, less than 21 million BTC)
• Input hash ≠ 0 and index ≠ -1 (excluding coinbase)
• Valid nLocktime relative to median past time
• Minimum transaction size ≥ 100 bytes
• Signature operations below limit
• Script compliance with standard formats
• Presence in mempool or main chain
• No double-spending conflicts
• Confirmation depth requirements for coinbase inputs
• Unspent output references
• Valid input/output value calculations
• Sufficient transaction fees (minRelayTxFee)
• Correct unlocking scripts matching output conditions

These rules are implemented in Bitcoin Core functions like AcceptToMemoryPool, CheckTransaction, and CheckInputs. They evolve over time to defend against new attack vectors or expand supported transaction types.

Through this process, each node maintains a pool of valid but unconfirmed transactions—the mempool or transaction pool.

Mining Nodes

Jing, a computer engineering student in Shanghai, participates in Bitcoin mining using specialized hardware designed specifically for SHA256 computations—essentially a "drilling rig" for digital currency extraction. His setup connects to a full Bitcoin node that receives and broadcasts unconfirmed transactions like any other node.

Unlike regular nodes, Jing’s system aggregates these transactions into candidate blocks for mining. While some miners operate without full nodes (often joining pools), Jing runs both for maximum control.

When new blocks appear on the network, they signal both the end of one mining round and the start of the next. For miners, receiving a new valid block means someone else won—but it also triggers immediate preparation for the following round.

Aggregating Transactions into Blocks

After validation, nodes store unconfirmed transactions in their mempool until included in a block. Jing’s node collects hundreds of such transactions while awaiting confirmation that block 277,315 has been mined—marking the official start of competition for block 277,316.

Upon verifying block 277,315, Jing removes its transactions from his mempool. The remaining ones form the basis of his candidate block—a placeholder not yet valid due to missing PoW.

This candidate contains 418 transactions generating total fees of 0.09094928 BTC. Using Bitcoin Core command-line tools:

$ bitcoin-cli getblockhash 277316
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
$ bitcoin-cli getblock 0000000...dc4

The resulting JSON shows details including size (218,629 bytes), timestamp (Dec 27, 2013), nonce (924591752), difficulty (~1.18 billion), and previous block hash.

Coinbase Transactions

The first transaction in any block is special: the coinbase transaction, which awards mining rewards.

At block height 277,316, the base reward was 25 BTC, later reduced after a halving event. Jing constructs this transaction paying himself 25.09094928 BTC—the sum of the base subsidy (25 BTC) and collected fees (0.09094928 BTC).

Unlike regular transactions, coinbase inputs don’t reference prior UTXOs. Instead, they use a special coinbase field creating value from nothing.

👉 Learn how miners earn rewards and secure the network

Example:

{
 "vin": [{ "coinbase": "03443b04..." }],
 "vout": [{
   "value": 25.09094928,
   "scriptPubKey": { "addresses": ["1MxTkeEP..."] }
 }]
}

This outputs 25.09094928 BTC to address 1MxTkeEP....

Calculating Block Rewards

To determine eligibility:

CAmount GetBlockSubsidy(int nHeight) {
    int halvings = nHeight / 210000;
    if (halvings >= 64) return 0;
    CAmount nSubsidy = 50 * COIN; // Initial = 5 billion satoshis
    nSubsidy >>= halvings;       // Right-shift halves value
    return nSubsidy;
}

At height 277,316: halvings = 1 → reward = 25 BTC.

Total reward = subsidy + fees = 25 + 0.09094928 = 25.09094928 BTC

⚠️ Can Jing award himself 100 BTC? No—such manipulation would invalidate the entire block across all nodes, wasting electricity and effort.

Coinbase Data Structure

Coinbase inputs differ significantly from standard ones:

This flexibility allows miners to embed arbitrary messages or metadata.

Coinbase Data Usage

Miners use coinbase data for extra randomness and identification tags.

Satoshi embedded: "The Times 03/Jan/2009 Chancellor on brink..."—a timestamped message proving genesis timing.

Today, data includes:

• Extra nonce space for PoW variation
• Version bits signaling protocol support (e.g., /P2SH/ indicates BIP-16 compatibility)

Parsing hex 03443b04...:

• 03: Push next 3 bytes onto stack
• 443b04 (little-endian): Block height = 277316
• 8584...: Extra nonce
• /P2SH/: ASCII tag showing BIP-16 support

// Extracting Satoshi's message from genesis block
#include <bitcoin/bitcoin.hpp>
int main() {
    bc::block genesis = bc::genesis_block();
    std::cout << genesis.transactions[0].inputs[0].script.data() << std::endl;
}

Output:

The Times 03/Jan/2009 Chancellor on brink...

Constructing the Block Header

Six fields make up the block header:

The merkle root aggregates all 419 transactions (including coinbase). Since merkle trees require even leaf counts, the last transaction is duplicated—forming a binary hash tree culminating in one root hash.

Target bits (1903a30c) encode difficulty: exponent (19) and coefficient (03a30c). This translates to:

Target = 0x3a30c × 2^(8×(25−3)) ≈ 2²⁷⁶

Only hashes below this threshold are valid.

Mining the Block

Mining involves repeatedly hashing the block header while varying parameters—mainly the nonce—until producing a hash below target.

SHA-256 guarantees unpredictable output: changing input by one bit drastically alters output.

Example:

"I am Satoshi Nakamoto" → a8f...
"I am Satoshi Nakamoto1" → f7b...
...
"I am Satoshi Nakamoto13" → 7d8... (starts with '7')

To find a hash starting with 'zero', we keep incrementing until success—demonstrating how PoW works: brute-force search with verifiable results.

🔑 PoW proves computational effort because verifying takes one step but finding requires many attempts.

Bitcoin’s current target:

Target:  ≤ ₀₀₀₀₀₀₀₀₀₀₀₀₀₀₀₀₀₂₉ₐᵦ₉₀₀₀₀₀₀₀...

With ~3 exahashes/sec global hashrate, finding valid solutions averages every 10 minutes despite astronomical odds.

Difficulty Adjustment

To maintain ~6 blocks per hour regardless of changing hardware capabilities, difficulty adjusts every 2,016 blocks (~two weeks) based on actual mining speed:

new_target = old_target × (actual_time / expected_time)

If blocks took less than 2 weeks → increase difficulty
If blocks took longer → decrease difficulty

Adjustments are capped at ±4× per cycle to prevent volatility.

👉 Explore how mining difficulty adapts to network changes

Successful Block Discovery

After ~11 minutes of computation using ASIC hardware processing trillions of hashes per second:

Nonce: 924591752
Hash:
₀₀₀₀₀₀₀₀₀₀₀₀₀₀₀₁ᵦ₆ᵦ₉ₐ₁₃ᵦ... < Target
→ Valid!

Jing broadcasts immediately. Nodes verify and propagate it globally. All miners abandon current efforts and begin building on top of this new block—effectively voting for its inclusion via their hash power.

Validating New Blocks

Each node performs rigorous checks before accepting a new block:

• Valid structure and syntax
• Hash < target
• Timestamp within ±2 hours
• Size within limits
• First transaction is coinbase-only
• All internal transactions valid per earlier rules

This ensures only honest miners receive rewards; cheaters waste resources.

Chain Selection: Longest Chain Rule

Nodes maintain three categories:

• Main chain blocks
• Side chains (valid but not longest)
• Orphan blocks (missing parent)

The main chain always represents the path with greatest cumulative work, not necessarily most blocks.

When receiving a new block:

• Link via prevHash
• If parent is tip → extend main chain
• Else attach as side branch
• Compare accumulated work → reorganize if needed

Orphan blocks wait in memory until parent arrives.

Eventually, temporary forks resolve as one chain grows longer—demonstrating emergent consensus in action.

Blockchain Forks

Due to network latency, different nodes may see competing blocks simultaneously—creating temporary forks.

Two miners solving PoW nearly simultaneously broadcast their blocks:

• Some nodes receive Block A first → accept as main chain
• Others receive Block B → treat A as side chain

Both chains are valid temporarily.

Resolution occurs when next block extends one branch:

• Chain with more work becomes dominant
• Other becomes orphaned
• Transactions not confirmed return to mempool

This natural fork resolution ensures eventual consistency across nodes.

Mining Hash Rate Competition

Bitcoin mining has evolved dramatically:

• CPU → GPU → FPGA → ASIC era (massive efficiency gains)
• Early networks: <8 MH/s → Today: >3 EH/s globally

ASIC chips now approach physical limits (~7nm fabrication), focusing on density and cooling optimization.

Hardware example:

• Hashrate: 14 TH/s
• Power: 1.3 kW/day
• Cost: ~$2,500 (in 2017)

Solo mining probability: ~once every 4 years
Pool mining return: ~$55/week → predictable income despite lower margins

Mining Pools

Individual miners face near-zero odds of solo success—like lottery tickets. Thus, most join mining pools, combining hash power for shared rewards.

Managed Pools

Operated by companies charging ~1–3% fee:

• Use protocols like Stratum or GBT
• Handle full node operations
• Distribute shares based on partial solutions ("shares")

Lower difficulty targets allow small miners to contribute meaningfully.

P2Pool (Peer-to-Peer Pool)

Decentralized alternative using a parallel "sharechain":

• Miners run local full nodes + P2Pool software
• Share difficulty targets enforced via blockchain-like consensus
• Eliminates central operator risk

More technically demanding but enhances decentralization.

Consensus Attacks (e.g., 51% Attack)

With majority hash power (>51%), attackers could:

• Reverse recent transactions (double-spends)
• Censor specific addresses (DoS attacks)

However:

• Cannot steal funds without private keys
• Cannot alter past consensus rules
• Requires massive investment
• Likely fails due to exponential hashrate growth

Even ~30% hash power may enable limited attacks statistically.

Example: Mallory buys art worth $250K using BTC → Seller delivers after one confirmation → Coordinated pool mines competing chain reversing transaction → Art lost + no payment received.

✅ Prevention: Wait for 6+ confirmations before releasing high-value goods.

Consensus Rule Changes

Rules governing validity must evolve—but changes require coordination across miners, developers, users.

Hard Forks

Non-backward-compatible upgrades causing permanent chain splits unless universally adopted.

Example: Introducing new signature type ("Smores") accepted only by upgraded nodes → two parallel chains emerge—one with new rules, one without.

Four-phase evolution:

1. Software fork → development
2. Network fork → adoption split
3. Mining fork → hashrate division
4. Chain fork → permanent divergence

Difficulty adjusts independently on each chain based on available hash power.

Controversial due to risk of ecosystem fragmentation.

Soft Forks

Backward-compatible upgrades where old nodes still accept new blocks—even if unaware of enhanced rules.

Examples:

• BIP-65 (CHECKLOCKTIMEVERIFY) repurposes NOP opcode → old clients ignore; new ones enforce locktime
• SegWit implemented via soft fork using script malleability fixes

Advantages:

• No mandatory upgrade required
• Safer deployment path

Criticism:

• Increases technical debt
• Relaxes validation assumptions
• Often irreversible once deployed

BIP-34 vs BIP-9 Signaling

BIP-34 (Version-based)

Used block version numbers to signal readiness:

• v2 → signal BIP-34 activation
• Required >75% signaling before enforcement (>95% to disable old version)

Limitations:

• One change at a time only
• Finite version numbers

BIP-9 (Bitfield-based)

Interprets version as bitfield allowing up to 29 concurrent proposals:

Fields:

• name: e.g., “csv” for CHECKSEQUENCEVERIFY
• bit: position (0–28)
• starttime: when signaling begins (MTP-based)
• endtime: after which proposal fails if not activated

Activation requires >95% signaling during a retarget period (~two weeks).

State machine:
DEFINED → STARTED → LOCKED_IN → ACTIVE

Successfully enabled CSV/BIPs in July 2016.

Final Thoughts on Consensus Development

Changing consensus rules is inherently difficult due to distributed power among stakeholders:

• Miners
• Core developers
• Wallet providers
• Exchanges
• Users

No group can impose changes unilaterally. Hard forks risk splitting communities; soft forks introduce complexity. Both involve trade-offs.

Yet this friction is not weakness—it's strength through enforced collaboration. The high bar for change ensures stability and resilience over time.

Bitcoin’s greatest innovation isn't just decentralization—it's achieving global agreement without central authority through economic incentives and cryptographic proof.

Frequently Asked Questions (FAQ)

Q: What is the main purpose of Bitcoin mining?
A: While miners earn new bitcoins as rewards, the primary function is securing the network by validating transactions and maintaining decentralized consensus through Proof-of-Work.

Q: How often does Bitcoin halve its block reward?
A: Approximately every four years—or every 210,000 blocks—the reward per block is cut in half until all ~21 million bitcoins are issued around 2140.

Q: Can a miner create invalid blocks to steal money?
A: No—every node validates all blocks independently. Invalid blocks (e.g., excessive rewards) are rejected instantly across the network, rendering them worthless despite PoW effort.

Q: What happens during a blockchain fork?
A: Temporary splits occur when two valid blocks are mined simultaneously. Nodes follow the chain with most cumulative work; eventually one prevails and consensus re-converges.

Q: Is a 51% attack possible on Bitcoin?
A: Theoretically yes—but practically very difficult due to immense cost and rapidly growing global hashrate exceeding zettahashes per second today.

Q: What’s the difference between hard fork and soft fork?
A: A hard fork creates incompatible changes requiring all nodes to upgrade or split off; a soft fork introduces backward-compatible rules allowing older nodes to remain part of consensus without updating immediately.