Glossary

Block Withholding Attack

A mining pool attack where a malicious participant submits partial proofs of work but withholds valid blocks to harm the pool.

Key Takeaways

  • A block withholding attack targets mining pools from the inside: the attacker submits valid shares to earn payouts but deliberately discards any share that qualifies as a full proof-of-work block, denying the pool its reward.
  • Detection is extremely difficult because withheld shares look identical to normal shares, and natural mining variance masks the missing blocks. No protocol-level countermeasure has been deployed as of 2026.
  • Pools using pay-per-share (PPS) payout schemes are most vulnerable, since the operator absorbs all block-discovery risk and pays the attacker a guaranteed rate regardless of whether blocks are found.

What Is a Block Withholding Attack?

A block withholding attack (BWH) is a sabotage strategy in which a malicious miner joins a mining pool, participates in the pool's hash-grinding work, and submits partial proof-of-work shares to demonstrate effort: but whenever that miner finds a hash that actually satisfies the full network difficulty target (a valid block), they throw it away instead of submitting it. The pool pays the attacker for their shares without ever receiving the block rewards those solutions would have earned.

The attack was first formally described by Meni Rosenfeld in his 2011 paper "Analysis of Bitcoin Pooled Mining Reward Systems." Rosenfeld identified two variants: sabotage, where the attacker discards every valid block purely to damage the pool, and lie-in-wait, where the attacker delays submission to maximize their proportional share of payout rounds. Both exploit the same fundamental asymmetry: a pool cannot distinguish between a miner who is unlucky and one who is withholding.

How It Works

To understand the attack, it helps to review how pooled mining normally operates. A pool distributes work to participants, who generate hash attempts against block templates provided via the Stratum protocol. When a miner finds a hash that meets the pool's lower share-difficulty threshold, they submit it as a "share" to prove they are working. Occasionally, one of these shares also meets the full Bitcoin network difficulty, making it a valid block. The pool broadcasts this block to the network and distributes the block reward among all contributors proportionally.

The attack subverts this process at a single decision point:

  1. The attacker joins an open mining pool like any legitimate miner, registering a worker and connecting via the pool's stratum endpoint.
  2. The attacker mines normally, generating hashes against the pool's work assignments. When a hash meets the share-difficulty threshold but not the full network difficulty, the attacker submits it. The pool credits the attacker for this work.
  3. When the attacker finds a hash that meets both the share threshold and the full network difficulty (a valid block), they recognize this and discard it. They never submit it to the pool or broadcast it to the network.
  4. Other honest miners in the pool eventually find and submit valid blocks. The block reward is distributed among all participating miners based on their submitted shares, including the attacker's. The attacker receives payouts despite never contributing a block.

Because valid blocks are extremely rare relative to shares (roughly 1 in thousands depending on the share-to-network difficulty ratio), the attacker retains nearly all of their expected per-share earnings while the pool's block discovery rate drops below what its total hashrate should produce.

Why Detection Is Difficult

Block withholding is notoriously hard to detect for several reasons:

  • Submitted shares are indistinguishable from honest work: they have correct formatting, arrive at expected intervals, and meet the required difficulty.
  • Block discovery is a rare, stochastic event. A pool cannot statistically distinguish between an unlucky miner and a withholding miner without observing enormous numbers of shares across many difficulty epochs.
  • Unsuccessful mining effort leaves no auditable trace. There is no way to prove a miner searched a particular nonce space and found (or failed to find) a valid solution.
  • Open pools allow pseudonymous participation, making it trivial for attackers to rotate identities or split hashrate across multiple accounts.

Simplified Example

Consider a pool with 100 miners, each contributing 1% of the pool's hashrate. Suppose the pool expects to find roughly 10 blocks per day based on its total hashrate:

Pool hashrate:        100 TH/s (100 miners × 1 TH/s each)
Expected blocks/day:  10
Block reward:         3.125 BTC (post-2024 halving)
Expected daily pool revenue: 31.25 BTC

With 1 attacker withholding:
  Effective block-finding hashrate: 99 TH/s (99 honest miners)
  Expected blocks/day: ~9.9
  Revenue loss per withheld block: 3.125 BTC + fees
  Attacker earns: 1% of all found blocks (~0.099 BTC/day)
  Honest miners each earn: ~0.099 BTC/day (instead of ~0.3125 BTC)
  Pool revenue: ~30.94 BTC (vs. 31.25 BTC expected)

The attacker earns nearly as much as an honest miner while the pool's total revenue drops. The loss is distributed across all honest participants.

Impact on Different Payout Schemes

The pool's reward distribution method significantly affects vulnerability to block withholding:

Pay-Per-Share (PPS)

Under PPS, the pool operator pays a fixed amount per submitted share regardless of whether the pool finds blocks. The operator absorbs all variance risk. A BWH attacker receives guaranteed payouts while the operator bears 100% of the loss from withheld blocks. A 2026 paper by Chen et al. proved that PPS mechanisms are not incentive-compatible: the optimal strategy is an "all-out attack" allocating the attacker's entire hashrate to the victim pool rather than splitting between solo and pool mining.

Proportional

Under proportional schemes, miners are paid only after a block is found, proportional to their share of total submitted work in that round. Block withholding still works: the attacker gets a proportional cut of blocks found by honest miners. However, the attacker also loses potential revenue from their own withheld blocks, making the attack less profitable than under PPS.

PPLNS (Pay-Per-Last-N-Shares)

PPLNS bases rewards on the last N shares submitted before a block is found. This scheme discourages pool-hopping and reduces BWH profitability because withholding a valid block also reduces the attacker's own expected revenue more significantly. Academic literature suggests PPLNS keeps the attacker's impact smaller than proportional schemes, though it does not eliminate the attack entirely.

Payout SchemeBWH VulnerabilityWho Bears the Loss
PPS / FPPSHighestPool operator
ProportionalModerateAll miners equally
PPLNSLowestAll miners, with reduced attacker profit

Block Withholding vs. Selfish Mining

Block withholding is often confused with selfish mining, but they are distinct strategies with different targets and mechanics:

AspectBlock WithholdingSelfish Mining
TargetA mining pool the attacker has joinedThe entire Bitcoin network
GoalSabotage pool revenue or free-ride on payoutsEarn disproportionate block rewards relative to hashrate
Block fateDestroyed (never broadcast)Strategically delayed, then broadcast to orphan competitors
Attacker rolePool member attacking from withinSolo miner or pool acting independently
First describedRosenfeld (2011)Eyal & Sirer (2014)

Hybrid variants exist as well. The Fork After Withholding (FAW) attack, described by Kwon et al. in 2017, combines elements of both: the attacker conditionally releases withheld blocks to create strategic forks rather than discarding them, yielding approximately 56% more reward than standard block withholding.

Proposed Mitigations

Researchers have proposed several countermeasures, though none have been deployed at the protocol level:

Oblivious Shares

Originally proposed by Rosenfeld in 2011, this approach has the pool construct work templates so that only the pool (not the miner) can determine whether a submitted share also meets the full network difficulty. The miner cannot selectively withhold blocks because it cannot identify them. However, this requires a Bitcoin consensus-level hard fork and increases block propagation latency, since the miner cannot independently recognize and propagate a block.

Two-Phase Proof of Work

This approach splits the proof-of-work into two phases. In the first, the miner generates a candidate solution. In the second, a separate verification step determines block validity. The miner cannot determine at discovery time whether their solution qualifies as a valid block. Like oblivious shares, this requires network-wide changes that create backward-compatibility challenges.

Auditable Proof of Work (APoW)

A 2025 proposal introducing dual-mode mining: miners alternate between normal hashing and a verification mode where they re-explore specific nonce regions from previous rounds. This allows pools to retroactively verify that a miner exhaustively searched their assigned nonce space, making withholding detectable after the fact. APoW is designed so that verification hashing remains productive (contributing to the pool's effective hashrate) rather than being wasted computation.

Statistical and Operational Approaches

  • Reputation tracking: monitor miner submission patterns over time and flag statistically anomalous workers who submit many shares but no blocks across extended periods.
  • Block-bonus incentives: offer elevated payouts for shares that also qualify as valid blocks, increasing the cost of withholding.
  • Permissioned pools: restrict participation to vetted miners, though this conflicts with mining decentralization goals.
  • Game-theoretic deterrence: pool operators adopt mixed strategies (such as zero-determinant strategies) that make mutual non-attack the rational choice, as explored in Eyal's "Miner's Dilemma" analysis.

Real-World Incidents

While block withholding is difficult to detect and likely underreported, two notable incidents have been publicly documented:

  • The Eligius mining pool lost at least 300 BTC over several months in 2014 before detecting and blocking the attackers. This remains the most widely cited real-world BWH incident and demonstrated the practical damage the attack can inflict even on well-run pools.
  • In late 2013, an "evilpool" proxy was discovered connecting to the 50BTC mining pool and forwarding all shares except those that were valid blocks, in one of the earliest documented real-world attacks.

Why It Matters

Block withholding highlights a fundamental tension in pooled mining: pools must trust that participants submit all valid work, yet there is no cryptographic mechanism to enforce this. The attack undermines the cooperative economics that make mining pools viable, and the shift toward PPS/FPPS payout schemes (driven by miners' preference for predictable income) has paradoxically increased the ecosystem's vulnerability.

For the broader Bitcoin network, BWH attacks reduce effective hashrate without reducing reported hashrate, creating a gap between perceived and actual network security. This makes block withholding relevant to anyone evaluating Bitcoin's censorship resistance and the decentralization of its mining infrastructure. For a deeper analysis of mining economics and pool dynamics, see the Bitcoin mining economics research article.

Layer-2 protocols like Spark and the Lightning Network are not directly affected by block withholding, since they settle off-chain. However, they ultimately depend on the security and honest operation of the base layer, making mining pool integrity a concern for the entire Bitcoin ecosystem.

Risks and Considerations

  • No deployed countermeasure exists at the protocol level as of 2026. Pools rely on statistical heuristics and game-theoretic deterrence, neither of which provides strong guarantees.
  • The attack is profitable under common payout schemes, particularly PPS and FPPS. The "all-out attack" variant demonstrated in 2026 research shows that rational miners may have incentive to withhold even when it appears individually suboptimal.
  • Eyal's "Miner's Dilemma" models inter-pool BWH as a prisoner's dilemma: each pool has incentive to attack rivals, but mutual attacks leave all pools worse off. The equilibrium is fragile and depends on implicit cooperation among pool operators.
  • Proposed protocol-level fixes (oblivious shares, two-phase PoW) would require a hard fork to Bitcoin's consensus rules, making deployment unlikely without broad community agreement.
  • The increasing dominance of a few large pools concentrates the attack surface: compromising or infiltrating a top-5 pool could have outsized impact on network economics.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.