258 / 736BWH

Block Withholding Attack

Withholding block solutions from a pool

Imagine a miner who regularly sends a pool evidence of work. When the miner finds the result needed for a valid block, however, they conceal it. The dashboard shows an active participant while the pool loses a chance to earn a reward. This is the basic Block Withholding Attack: an attack on cooperation between miners whose traces can resemble ordinary bad luck. Understanding it requires separating routine work proofs, actual blocks and the rules for distributing money.

A Block Withholding Attack occurs when a miner submits ordinary work proofs to a pool but deliberately fails to submit a valid block solution. The pool can therefore credit that miner’s work without receiving the corresponding opportunities to earn block rewards.

A Mining Pool brings miners together and distributes rewards under agreed rules. It cannot wait for every small participant to find a whole block. As the Bitcoin Developer Guide explains, it uses shares: results meeting an easier requirement that provide ongoing evidence of work. A rare result also meets the Bitcoin network’s stricter requirement. The attacker submits ordinary shares but discards this more valuable discovery. The machine is genuinely computing and consuming electricity; this is not a cost-free pretence of mining. [3]

The answer depends on the payout model. Meni Rosenfeld distinguishes Pay Per Share (PPS), where the operator pays for accepted shares, from Pay Per Last N Shares (PPLNS), where actual block rewards are distributed according to recently accepted shares within a defined range. With PPS, the operator therefore bears the shortfall from missing blocks if it honours its promised payments. With PPLNS, there is less money to share among participants, including the attacker. The same discarded discovery can thus reduce different participants’ income. The pool’s actual rules matter more than a “mining” label on a dashboard. [1]

Discarding discoveries alone can be costly sabotage. The attacker pays for equipment and electricity while giving up revenue they could have earned honestly. Ittay Eyal also studies a more complex case: a competing pool mines honestly with some capacity and uses another part against a different pool. Under certain assumptions, that allocation can increase its total revenue. A mathematical result is not a promise of profit after all costs, however. The victim’s loss alone does not tell us whether the attacker made money overall. [2]

Both names involve an unpublished block, but its fate differs. Eyal and Emin Gün Sirer describe Selfish Mining as mining on a private chain branch and strategically publishing its blocks. The attacker wants that branch to prevail and earn rewards. In contrast, a classical Block Withholding Attack within a pool discards discovered blocks; it need not build a winning private branch. Other variants only delay submission. When reading an analysis, we therefore need to identify the strategy the author actually studies. [4]

Imagine a period in which an honest miner would find an average of 1 block given its computing power and difficulty. The Poisson model, also used by Rosenfeld, describes independent random discoveries at a constant expected rate. It gives roughly a 37% chance of finding none. With 3 blocks expected, that chance is about 5%. This is not a probability of guilt: we are calculating the chance of zero results assuming honest mining, not the probability of cheating after observing zero. The illustration assumes suitable stable conditions and a predefined observation period. An average is not a deadline for a block to arrive. [1]

Eyal points out how difficult it is to attribute an attack to a particular small miner. An account with no discovered block is insufficient. Accepted shares must be compared with blocks over the same period, taking share difficulty—the work those shares represent—into account. Hashrate means computing speed; estimating it from these proofs also produces fluctuations. Outages, missing records and changing conditions need investigation too. A pool may have grounds to investigate a problem without having enough evidence to accuse an individual. [2]

Eyal discusses a bonus for discovering a block, reputation-building and test tasks with known solutions. Each changes something. A bonus shifts more of the reward to the finder and can increase small miners’ income fluctuations. Reputation rules make moving between pools harder; test tasks require maintenance and reliable interpretation. This is not universal protection available at the flick of a switch. Operators must assess effectiveness alongside side effects and explain honestly what their measures can detect. [2]

The Bitcoin Developer Guide distinguishes finding a block from its validation by the network. Concealing a discovery changes no transaction-validity rules and does not itself allow spending other people’s coins or rewriting confirmed history. It primarily harms the economics and trust of mining cooperation. Three questions help keep the issue clear: what was withheld, who lost money under the agreed rules, and what evidence actually exists? Describing this mechanism accuses no current pool of using it. [3]

For the clearest picture, read this entry together with Mining Pool, Pay Per Last N Shares, Hashrate, Selfish Mining.

DOC · 001Rosenfeld — Analysis of Bitcoin Pooled Mining Reward SystemsPrimary DOC · 002Eyal — The Miner’s DilemmaPrimary DOC · 003Bitcoin Developer Guide — MiningDocumentation DOC · 004Eyal and Sirer — Majority is not EnoughPrimary
Revised: Source-first · No investment advice