§ 2.6Module 2

Mining Difficulty, Pools, and Mining Methods

2.6 — Life of a Miner, Mining Difficulty, Pools, and Methods

Recall first. A miner does not “guess the answer once.” What does the miner repeatedly change while hashing a candidate block, and why must the network make the target difficult?

What a miner actually does

In a PoW blockchain such as Bitcoin, a miner is a participant that prepares candidate blocks and searches for a block header whose hash satisfies the current target. Mining is therefore both:

a validation/assembly task: select and check transactions; and
a proof-of-work task: spend computation searching for a valid header.

A successful miner does not get to force invalid transactions into the chain. Other nodes independently check the block, its transactions, its previous-block reference, its Merkle root, and its proof. [Book: Ch. 3 §3.5.2, lines 1998–2006; Ch. 4 §§4.4.2–4.4.4.1, lines 2688–2818]

The life of a miner: end to end

1. Obtain hardware, electricity, cooling, software, and network access
2. Receive transactions and validate candidate inputs/signatures
3. Choose transactions, often considering fee rate and block space
4. Build a candidate block and Merkle root
5. Vary nonce and other header data; hash repeatedly
6. If hash < target, broadcast the block and proof
7. Other nodes verify the block and relay it
8. If accepted on the best chain, receive protocol reward/fees
9. Repeat, while accounting for changing difficulty and costs

A miner may change the nonce, timestamp within protocol limits, transaction selection, or an extra nonce in the coinbase transaction when the ordinary nonce range is exhausted. The source describes the mempool as the staging area from which candidate transactions are selected, and describes the winning block being propagated through the peer network. [Book: Ch. 4 §4.4.4.4, lines 2840–2865]

Mining difficulty and the target

The network does not ask for a particular human-readable hash. It sets a target. A block is valid for PoW when:

H(block header) ≤ target

Because cryptographic hash outputs are treated as unpredictable, a smaller target means fewer acceptable outputs. The expected number of attempts rises as the target becomes smaller. A practical difficulty value is a relative measure of how hard the current target is compared with a reference target; it is not “the number of seconds” or “the number of zeros” in a universal sense.

Why difficulty changes

If total network hashpower rises, blocks would otherwise arrive faster. If hashpower falls, blocks would arrive slower. Bitcoin periodically retargets the difficulty so that the long-run block interval remains near the protocol’s target. The book describes a retarget after 2016 blocks, approximately two weeks at the intended ten-minute average. [Book: Ch. 4 §4.4.4.4, lines 2840–2865]

Do not confuse:

hash rate = attempts per second;
difficulty = relative hardness of finding an acceptable hash;
target = the threshold a hash must meet;
block interval = time between accepted blocks.

If hash rate increases before a retarget, blocks may temporarily arrive faster; after retargeting, the target becomes harder. If hash rate falls, the next adjustment makes the target easier within the protocol’s adjustment rules.

Solo, pool, and cloud mining

Solo mining

A solo miner operates independently and keeps the full block reward and fees if they find an accepted block. The disadvantage is high variance: a small miner may contribute work for a long time with no payout, even though the miner’s long-run probability reflects their share of total hashpower. [Book: Ch. 3 §3.5.2, lines 1998–2006]

Pool mining

A mining pool combines the hashpower of many miners. The pool operator gives participants work that avoids needless duplication, receives partial proofs called shares to measure contributed work, and submits a candidate block when one participant finds a valid network solution. The block reward and fees are then distributed under the pool’s agreed rules. [Book: Ch. 3 §3.5.2, lines 1998–2006; Ch. 4 §4.4.4.3, lines 2819–2839]

Pools trade:

lower payout variance for each small miner;
a fee and reduced individual reward; and
operational convenience for dependence on a pool operator.

Pool concentration can create a decentralisation risk. A pool or coordinated group with a large share of network hashpower may gain influence over transaction selection or chain reorganisation. A pool is not automatically an attacker, and hashpower concentration is not identical to a successful attack, but it is a security/governance warning.

Cloud mining

Cloud mining rents remote hashpower or mining capacity from a provider. The customer avoids buying and maintaining hardware, but pays through a subscription, contract, fee, or share of rewards. The customer must trust the provider’s equipment, measurements, contract, uptime, maintenance, and honesty. Cloud mining can also make fraud and unprofitable contracts difficult for a beginner to detect. [Book: Ch. 4 §4.4.3.1, lines 2720–2747; Ch. 3 §3.5.2, lines 1998–2006]

Important syllabus boundary: payout schemes

The primary extract explains solo, pool, and cloud methods, including proportional sharing by contributed processing power or pool terms. It does not cover PPS, FPPS, PPLNS, or other named pool payout schemes. Do not invent a textbook comparison for those methods from this note. If the examination explicitly asks them, consult a separate current mining-pool source.

Hardware methods

The book traces a progression from general-purpose to specialised hardware:

Method	What it uses	Strength	Limitation
CPU mining	General-purpose processor	Cheap and accessible; historically important	Very low efficiency for modern PoW difficulty
GPU mining	Graphics processor	Parallel computation; more flexible than ASIC	Power, heat, cost, and competition
FPGA mining	Reconfigurable specialised circuit	More efficient than general hardware for a chosen algorithm	Technical complexity and narrower use
ASIC mining	Application-specific integrated circuit	Highest efficiency for its designed algorithm	Little flexibility, obsolescence, capital and supply-chain risk

The extract discusses CPU, GPU, FPGA, and ASIC for Bitcoin hardware, and separately describes cloud arrangements. Hardware superiority does not guarantee profit: revenue depends on block reward, fees, price, uptime, pool terms, electricity, cooling, equipment cost, difficulty, and the miner’s share of total hashpower. [Book: Ch. 4 §4.4.3.1, lines 2713–2747]

Worked example — solo or pool?

Miner A owns 1% of the network’s total hashpower. Miner B owns the same hardware but joins a pool. Ignore fees and changing difficulty.

In the long run, what fraction of blocks should either miner’s hashpower find?
Why might Miner B receive smaller but more regular payments?
What does the pool not change?

Revealed answer

Each contributes about 1% of expected block-finding work over a sufficiently long period.
In solo mining, Miner A receives the whole reward only when their own search finds a block, so outcomes are highly variable. In a pool, Miner B receives shares of many successful pool outcomes according to the pool’s rules, reducing variance but also paying pool costs and sharing the reward.
The pool does not magically create more network hashpower or change the PoW target. It changes coordination and payout variance; concentration in the pool can add a decentralisation concern.

Exercise

Suppose many new ASIC miners join the network. Before the next difficulty adjustment, what tends to happen to block-finding time? After the adjustment, what is the intended effect? Explain using hash rate and target, not “the algorithm gets smarter.”

Revealed answer

The total hash rate rises, so blocks tend to be found faster before the next adjustment. The protocol then lowers the target (raises relative difficulty), reducing the fraction of hashes that qualify and restoring the average block interval toward its target. The adjustment changes the acceptance threshold; it does not make individual hash calculations less random.

Exam lens

For “life of a miner, mining difficulty, pool and methods,” use four headings:

Life of a miner: hardware/setup → transaction selection → candidate block → nonce/hash search → broadcast → verification → reward.
Difficulty: target threshold, hash rate, expected attempts, periodic retarget, intended block interval.
Pool: combined hashpower, assigned work, shares, reward sharing, lower variance, centralisation risk.
Methods: solo/pool/cloud and CPU/GPU/FPGA/ASIC, each with one advantage and limitation.

Common traps:

A miner validates transactions but does not have unilateral authority to accept invalid ones.
Higher hash rate does not permanently make blocks faster because difficulty retargets.
A pool reduces payout variance; it does not guarantee profit.
Cloud mining removes hardware ownership, not economic or counterparty risk.
“Difficulty” is not the same as hash rate, target, or number of leading zeroes.
The source does not provide PPS/FPPS/PPLNS details; do not attribute them to the book.

Rapid revision

Can I draw the miner lifecycle from mempool to accepted block?
Can I explain hash ≤ target and why a lower target is harder?
Can I distinguish hash rate, difficulty, target, and block interval?
Can I compare solo, pool, and cloud mining?
Can I compare CPU, GPU, FPGA, and ASIC without claiming hardware alone determines profit?
Can I state the source gap about payout schemes?

Key takeaways

Mining combines transaction/block preparation with a PoW search.
Difficulty is controlled through a target and retargeted to stabilise the intended block interval.
Solo mining keeps a successful reward but has high variance; pools smooth payouts by sharing work and rewards.
Cloud mining rents infrastructure and adds provider/contract risk.
CPU, GPU, FPGA, and ASIC represent increasing specialisation, with trade-offs in efficiency, flexibility, cost, and obsolescence.
The primary book covers mining methods but not PPS/FPPS/PPLNS payout schemes.

Sources

S. Chandramouli, Asha A. George, Abhillash K. A., and Meena Karthikeyan, Blockchain Technology. Primary extract: Ch. 3 §3.5.2 “Cryptomining” (lines 1998–2005), covering the mining overview; Ch. 4 §§4.4.2–4.4.4.4 “Mining,” “Bitcoin Mining,” “Proof of Work and Hashcash” (lines 2688–2865), covering solo/pool/cloud context, hardware, mempool, block construction, target/difficulty, pool coordination, Hashcash, and retargeting. The extract does not cover PPS/FPPS/PPLNS payout schemes; current reward, price, and hardware-performance numbers are omitted rather than presented as current facts. Clear OCR errors have been corrected silently.