MASTERING-BITCOIN · Unit 13 · Video 6

Mining Pools and 51% Attacks: Interactive Practice

IKey Formulas and Facts

Concept Formula / Value Meaning
Expected block time for a miner T=10 minfT = \dfrac{10\text{ min}}{f} ff = fraction of network hashrate you control
Effective search space per header 232×264=2962^{32} \times 2^{64} = 2^{96} 32-bit header nonce ×\times 64-bit coinbase extra nonce
Nakamoto attack success prob. P(q,z)=1k=0zλkeλk!(1(qp)zk)P(q, z) = 1 - \sum\limits_{k=0}^{z} \dfrac{\lambda^k e^{-\lambda}}{k!}\left(1 - \left(\tfrac{q}{p}\right)^{z-k}\right) qq = attacker fraction, p=1qp = 1-q, λ=zq/p\lambda = z\,q/p
Blocks per year 52,560\approx 52{,}560 one block every 10 minutes

IIVisualization 1: Solo vs Pool Mining Variance

A miner finds blocks as a Poisson process. The expected income is identical whether you mine solo or join a pool with proportional payouts — but the variance is dramatically different.

Use the sliders to control your share of the network and the pool you might join, then compare the simulated payout streams over one year.

⚙ interactive visualization — coming to this page format soon

Reflect: Try setting your hashrate to a tiny value (e.g., 0.0001 = 0.01% of the network). The solo miner often earns zero for the entire year, while the pool miner receives small, steady payments that closely track the expected line. Both have identical expected income — but only one can pay the electric bill every month.

IIIVisualization 2: The 51% Attack — Probability of Success

With hashrate fraction qq, an attacker tries to catch up to and overtake the honest chain after a merchant has already waited for zz confirmations. This is the calculation from Section 11 of Nakamoto's whitepaper.

Adjust the sliders to see how the attacker's success probability depends on their hashrate and the merchant's patience.

⚙ interactive visualization — coming to this page format soon

Notice: The probability of a successful double-spend drops exponentially with each additional confirmation. With q=10%q = 10\% and z=6z = 6, the attacker's chance is less than one in a thousand. But at q=45%q = 45\%, even six confirmations leaves a meaningful attack probability — and once q50%q \geq 50\%, success is essentially guaranteed given enough patience. This is why "51%" isn't a magic threshold: probabilistic attacks become viable well below it.

IVVisualization 3: Honest Chain vs Attacker's Private Fork

Picture the attacker starting a private fork at some block height, while the honest network keeps building from the same point. Each side mines blocks as a Poisson process at a rate proportional to its hashrate.

The attacker only wins if their secret fork eventually becomes strictly longer than the honest chain — at which point they broadcast it and the network reorganizes onto the longer chain.

⚙ interactive visualization — coming to this page format soon

Reflect: At q<50%q < 50\% the honest chain is expected to pull ahead, but the attacker can occasionally win short races by luck. At q>50%q > 50\% the attacker is expected to win every race given enough time. The Nakamoto formula above quantifies exactly how long a merchant must wait to make double-spends statistically infeasible at any given qq.

VQuiz Questions

Question 1 · Expected Block Time

Suppose you control 0.1% of the total Bitcoin network hashrate (one part in a thousand). The network produces one block every 10 minutes on average.

Roughly how often, on average, will you personally find a block?

Correct! With f=0.001f = 0.001, the expected time is 10/0.001=10,00010/0.001 = 10{,}000 minutes 6.94\approx 6.94 days — about one block per week.

Not quite. Use T=10 min/fT = 10 \text{ min} / f with f=0.001f = 0.001, then convert minutes to days.

Show solution

Solution:

Use the expected block time formula: T=10 minf=10 min0.001=10,000 minT = \frac{10 \text{ min}}{f} = \frac{10 \text{ min}}{0.001} = 10{,}000 \text{ min}

Converting: 10,000 min167 hours6.94 days10{,}000 \text{ min} \approx 167 \text{ hours} \approx 6.94 \text{ days}.

So with 0.1% of the network you find roughly one block per week — but with enormous variance around that average. This week-scale variance is exactly the problem that drives small miners to join pools.

Question 2 · What 51% Cannot Do

A hostile entity acquires more than 50% of Bitcoin's total hashrate.

Which of the following actions is NOT within their power?

Correct! Hashrate controls ordering, not ownership. Stealing coins requires forging signatures — that's a cryptographic problem, not a mining problem.

Not quite. That action is within the attacker's power. Look for the action that requires breaking cryptography rather than controlling block ordering.

Show solution

Solution:

A 51% attacker controls ordering, not ownership. Their hashpower lets them:

  • ✅ Reorder recent blocks (build a longer fork)
  • ✅ Censor addresses (refuse to include those transactions)
  • ✅ Double-spend their own coins (reverse a transaction they originated)

But spending someone else's coins requires forging a valid ECDSA signature against that user's public key. Hashrate does not break cryptographic signatures. The attacker would need the victim's private key, which has nothing to do with mining.

Hashrate controls ordering. Private keys control ownership.

Question 3 · Why Pools Use Shares

In a mining pool, miners submit "shares" — hashes that meet an easier target than the full network difficulty. Most shares are not valid blocks.

What is the primary purpose of shares?

Correct! Shares are the pool's internal accounting system — they let the pool verify each miner's contribution and smooth payouts over time.

Not quite. Shares are an off-protocol mechanism between pool and miners. They don't change block rewards, aren't part of Bitcoin consensus, and don't replace proof-of-work.

Show solution

Solution:

Shares are an off-protocol accounting mechanism used between a pool and its members. The Bitcoin protocol knows nothing about them.

Why they exist:

  • A block is rare (network target). A share uses an easier target set by the pool.
  • Every share is a valid proof-of-work — just not difficult enough to be a block.
  • The share's coinbase commits to the pool's address, so a winning share also names the pool as beneficiary.
  • The pool counts each miner's share contributions and pays out proportionally.

This way miners get smooth, steady income proportional to their work, instead of waiting years for a single lottery win. Shares do not change the block reward, and they certainly do not replace network consensus.

Question 4 · Threshold Is Not Magic

True or False: A hostile entity needs exactly 51% of the network hashrate before any kind of chain-reorganization attack becomes possible. Below 51%, the network is fully safe from reorganization.

Correct! Probabilistic attacks become viable well below 50%. The 51% figure is the threshold for guaranteed eventual success, not for any success at all.

Not quite. Look back at Visualization 2 — even at q=30%q = 30\%, the success probability is small but nonzero. The 51% mark guarantees success; it doesn't gate it.

Show solution

Solution:

False. The figure "51%" is a threshold for guaranteed eventual success, not for any possible success.

From Visualization 2 you can see that at q=30%q = 30\% and z=6z = 6 confirmations, the success probability is still on the order of 10310^{-3} — small, but non-zero. Probabilistic reorganizations become economically viable well below 50%, especially against merchants who accept too few confirmations.

The lesson:

  • q50%q \geq 50\% → success approaches 1 as the attacker waits longer.
  • q<50%q < 50\% → success probability decays exponentially in zz, but is never exactly zero.

This is why merchants set confirmation requirements based on transaction value, and why the security of the chain depends on a deep margin of honest hashrate, not just a bare majority.

Solved: 0 / 4