Educational protocol and incentive analysis only; not investment, mining, legal, or security advice. Selfish-mining profitability and detectability depend on the exact network, strategy, propagation, rewards, difficulty rules, costs, observation window, and adversary model; no hash-share threshold, stale-block statistic, simulation, or confirmation count guarantees a conclusion.
Direct answer
Selfish mining is a family of strategic proof-of-work mining policies in which a miner or coordinated coalition withholds one or more valid blocks, privately extends a branch, and selectively publishes blocks in an attempt to make other miners spend a larger fraction of their work on branches that do not become accepted. The objective is usually modeled as increasing the coalition’s long-run share of accepted rewards relative to its compatible hash share, not creating proof of work from nothing.
The classic Eyal-Sirer strategy, often called SM1, tracks the coalition’s private lead. At lead zero, a coalition block is withheld. At lead one, another coalition block extends the secret branch, while a competing public block triggers publication to create a visible tie. If the private lead is at least two, publication is timed to override or stay ahead of the public branch. Every published block must still satisfy the network’s validity and proof-of-work rules.
Two model parameters are commonly denoted alpha and gamma. alpha is the coalition’s fraction of compatible block-finding rate. In the original instantaneous-network abstraction, gamma is the fraction of non-coalition hash power that mines on the coalition’s branch during a public tie. It is not simply latency, the fraction of nodes that first saw a block, or a permanent property of a mining pool. Topology, relay policy, block validation time, template refresh, fee content, and other miners’ strategies can all change effective tie behavior.
There is no universal selfish-mining threshold. The familiar values of one-third or one-quarter come from a particular constant-reward, two-party, stationary, longest-chain model and a specified strategy. Later work expands the strategy space, includes propagation delay, variable fees, multiple coalitions, eclipse conditions, and different difficulty-adjustment algorithms. A threshold from one model is a conditional result, not a measured safety boundary for every proof-of-work network.
Selfish mining is also not synonymous with every kind of block withholding. A pool participant can submit partial shares while hiding full solutions to sabotage a pool; that is a different pool-level attack. Accidental delayed publication, temporary forks, invalid-block attacks, censorship, fee sniping, undercutting, double spending, majority reorganization, and stubborn-mining variants overlap in some mechanics but require separate definitions and evidence.
How to analyze selfish mining
- Fix the network and objective. Record genesis, client and activation state, proof-of-work algorithm, fork-choice and tie behavior, target and difficulty adjustment, reward maturity, subsidy, fee treatment, stale-block treatment, observer, time window, and whether the objective is relative accepted reward, reward per wall-clock time, profit after cost, censorship, or reorganization.
- Specify the strategy as a state machine. Define public and private branches, cumulative work, unpublished lead, allowed actions such as wait, adopt, match, override, or publish, coalition coordination, maximum withheld depth, and behavior after every coalition or non-coalition discovery. Do not use “selfish mining” as a complete algorithm.
- Define hash and propagation parameters. Bind
alphato effective compatible block-finding rate over the same interval. Define exactly howgammaor a richer delay model allocates non-coalition work during each race; include relay topology, validation, template switching, compact-block behavior, partitions, and eclipse capability where relevant. - Model accepted rewards and time separately. Track coalition and other accepted blocks, stale or abandoned valid blocks, subsidy, transaction fees, any uncle or inclusion rewards, reward maturity, discovery time, public-chain growth, and difficulty epochs. Relative accepted share is not automatically revenue per hour or profit.
- Solve and validate the stated model. Use an exact Markov analysis, bounded Markov decision process, or reproducible event simulation appropriate to the strategy. Report truncation, convergence, warm-up, seeds, confidence intervals, sensitivity, and an honest-mining baseline; independently reproduce small state transitions by hand.
- Test evidence and alternatives. Preserve first-seen headers, peer-level arrival times, competing branches, work, coinbase or payout attribution, templates, fees, timestamps, and pool changes. Compare withholding with ordinary Poisson variance, propagation delay, outages, software faults, partitions, fee sniping, and label error. Public-chain data alone may not reveal unpublished losing blocks.
- Evaluate controls without overclaiming. Stress faster and more diverse relay, validation improvements, tie rules, fork-choice or reward changes, difficulty algorithms, pool concentration, miner switchability, monitoring, incident response, and confirmation policy. Each control can change incentives or observability and can create new strategic behavior; reanalyze the complete network rules.
The output should distinguish the strategy definition, model result, simulation result, observed network evidence, and operational conclusion. None can silently substitute for another.
Worked examples
1. A private-lead trace and a public race
Let a coalition have alpha = 0.30. Starting from one public tip, suppose the next discoveries are coalition, coalition, then non-coalition. The probability of that exact independent prefix in the simplified model is:
0.30 * 0.30 * 0.70 = 0.063 = 6.3%
The coalition can publish its two-block branch against the one-block public branch; if both branches are valid and each block represents equal work, its branch wins and the competing block becomes stale. This trace gives the coalition two accepted blocks, but it does not establish long-run profitability because all other traces, failed private branches, elapsed time, fees, and adjustment rules also matter.
If instead the sequence reaches a one-block public tie, set gamma = 0.50. Conditional on the next discovery resolving that race, the coalition finds it with probability 0.30 and earns two accepted blocks; non-coalition miners extend the coalition branch with probability 0.70 * 0.50 and the coalition earns one; the other outcome earns it zero. Conditional expected coalition blocks are:
0.30 * 2 + 0.70 * 0.50 * 1 = 0.95
There are two accepted blocks after resolution in every branch of this toy race, so the conditional share is 0.95 / 2 = 47.5%. Comparing that selected event directly with 30% is selection bias; a long-run state model must include the probability and cost of reaching the race.
2. Why the classic threshold is conditional
For SM1 in the original constant-reward abstraction with alpha < 0.50, the reported break-even hash-share threshold is:
alpha* = (1 - gamma) / (3 - 2 * gamma)
At gamma = 0, the threshold is 1 / 3 = 33.3333%. At gamma = 0.50, it is 0.50 / 2 = 25%. At gamma = 0.90, it is 0.10 / 1.20 = 8.3333%. These values show sensitivity to the tie assumption; they do not say that a measured network with eight, 25, or 34 percent hash share is necessarily profitable, safe, malicious, or controlled by one actor. Strategy optimization, real delay, reward variance, fees, difficulty, and costs change the question.
3. Relative accepted share is not immediate time revenue
Suppose a simulated interval contains 1,000 block discoveries. A coalition with modeled 28% hash share gets 270 accepted blocks, other miners get 650, and 80 valid discoveries are abandoned. The coalition’s share of accepted blocks is:
270 / (270 + 650) = 270 / 920 = 29.3478%
That is 1.3478 percentage points above its hash share. Yet an honest proportional benchmark over the same 1,000 discoveries is 280 coalition blocks, so its accepted count before any time normalization is 10 lower, or 10 / 280 = 3.5714% below that benchmark. A later difficulty adjustment may restore public-chain block frequency and change reward per wall-clock time, but only under its exact window, timestamp, clamp, hash-rate, fee, and continued-strategy assumptions. Relative share alone does not prove immediate profit.
4. A block-share anomaly is not attribution proof
Assume an independently estimated coalition share of p = 0.30 and, only as a rough null model, n = 10,000 independent accepted blocks. The expected count is n * p = 3,000, and the binomial standard deviation is:
sqrt(10,000 * 0.30 * 0.70) = 45.8258 blocks
An attributed count of 3,080 gives z = (3,080 - 3,000) / 45.8258 = 1.7457. That is not a selfish-mining detector. Accepted blocks are not necessarily independent with fixed p; hash estimates and pool labels have error; fee selection, outages, luck, propagation, and switching can alter counts; and unsuccessful private blocks may never reach the observer. Investigation needs competing-header and peer-arrival evidence plus a declared causal model, not a block-share z-score alone.
Risks and review failures
Model and protocol errors
- Undefined strategy:
SM1, stubborn variants, optimal policies, fee-aware withholding, and pool sabotage take different actions. Publish a complete state and action table. - Height substituted for cumulative work: Branch choice follows network rules over valid work, not a universal block-count comparison. Reconstruct both branches and exact work.
- Universal threshold claim: One-third, one-quarter, or any other value is conditional on a model and objective. State the equation, domain, strategy, and assumptions.
- Misreading
gamma: It is a modeled allocation of non-coalition mining during a race, not a directly observed global latency score. Define how it is estimated or simulated. - Constant equal-reward assumption: Subsidies, heterogeneous fees, uncle rewards, maturity, and transaction selection can change incentives. Model the actual reward vector.
- Ignoring difficulty adjustment: Lost public-chain growth can affect later difficulty and wall-time revenue. Simulate the exact epoch, timestamps, bounds, and hash-rate response.
- Calling one policy optimal: A bounded MDP optimum depends on its state, action, reward, delay, and truncation choices. Report bounds and sensitivity rather than universal optimality.
Evidence and security errors
- Conflating pool block withholding: Hiding a full solution from a pool while submitting shares differs from privately extending a consensus branch. Keep participants and reward mechanisms separate.
- Conflating double spending or majority control: Reward manipulation can occur without a conflicting payment, while reorganization and censorship objectives need additional state and evidence.
- Treating valid withholding as invalid-block acceptance: Published coalition blocks still face ordinary proof-of-work and transaction validation. Hash share cannot authorize invalid state transitions.
- Consecutive-winner inference: Poisson mining naturally produces runs. Use long windows, uncertainty, competing branches, arrival timing, templates, and alternative hypotheses.
- Stale-rate certainty: Observer coverage, relay policy, topology, accidental races, outages, and hidden losing blocks bias stale measurements. Preserve vantage-point limitations.
- Pool-label certainty: Coinbase tags, payout addresses, template fingerprints, hash contributors, and beneficial control do not map perfectly. Version attribution and uncertainty.
- Ignoring partitions and eclipse effects: Restricted network views can alter races, measured
gamma, and strategy feasibility. Test peer diversity and adversarial connectivity.
Economics and mitigation errors
- Relative share called profit: Convert accepted rewards to wall-clock cash flows, subtract power, hosting, pool, capital, financing, tax, variance, and failed-block costs.
- Assuming immediate post-adjustment economics: Strategy persistence, competitor exit or entry, hash-price changes, fees, coin price, and adjustment lag can invalidate steady-state projections.
- Treating pool share as permanent control: Hash contributors may switch, but contracts, firmware, payout custody, coordination delays, geography, and concentration can constrain them.
- Single-metric detection: Block share, stale rate, latency, or fee pattern alone is non-identifying. Combine independent telemetry with an explicit statistical decision rule.
- Mitigation without equilibrium analysis: Faster relay, random tie breaking, freshness rules, reward changes, or penalties can move incentives and add manipulation surfaces. Re-model adoption and adversaries.
- Confirmation count as a complete fix: More depth can reduce some transaction-reorganization exposure but does not remove reward distortion, wasted work, centralization pressure, or liveness effects.
Common misconceptions
Selfish mining requires majority hash power
No. The original result studies when a minority coalition can improve its modeled relative accepted-reward share. The break-even point depends on tie behavior and other assumptions; majority power is neither the definition nor a universal prerequisite.
Withholding one block proves selfish mining
No. Operators can delay publication accidentally or for other strategic and technical reasons, and an outside observer may not know when a block was found. Selfish mining is a contingent policy across states, not one isolated delay.
More accepted blocks than hash share proves the strategy
No. Block finding is random, hash share is estimated, labels are imperfect, and miners switch. Even a statistically unusual deviation needs propagation, branch, template, reward, and alternative-cause evidence.
Selfish mining creates invalid blocks or free work
No. Its published blocks must be valid and contain real proof of work. The modeled advantage comes from changing which valid discoveries become accepted and from the response of other miners and difficulty rules.
A relay improvement or more confirmations eliminates the issue
No single control proves incentive compatibility. Relay can change race probabilities, while confirmations address some transaction reversal risk; neither alone resolves reward design, strategic variants, concentration, adjustment rules, or fee incentives.
Related topics
Sources
- Majority is not Enough: Bitcoin Mining is Vulnerable - Eyal and Sirer (accessed: 2026-08-19)
- Optimal Selfish Mining Strategies in Bitcoin - Sapirshtein, Sompolinsky, and Zohar (accessed: 2026-08-19)
- Stubborn Mining: Generalizing Selfish Mining and Combining with an Eclipse Attack - Nayak et al. (accessed: 2026-08-19)
- Bitcoin Blockchain Dynamics: The Selfish-Mine Strategy in the Presence of Propagation Delay - Göbel et al. (accessed: 2026-08-19)
- On the Profitability of Selfish Mining Against Multiple Difficulty Adjustment Algorithms - NIST (accessed: 2026-08-19)
- Bitcoin Developer Guide: Block Chain - Bitcoin Project (accessed: 2026-08-19)
- Bitcoin Core: Chainwork Calculations - Bitcoin Core (accessed: 2026-08-19)
- On the Instability of Bitcoin Without the Block Reward - Carlsten et al. (accessed: 2026-08-19)