51% attack

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A 51% attack occurs when one party controls enough consensus power to reliably outpace the honest network and reorganize recent blockchain history.

On a proof-of-work (PoW) chain, the term usually means control of a majority of active hash rate. The attacker can build a competing branch with more cumulative proof of work than the honest branch and cause nodes to adopt it. “51%” is shorthand for a sustained advantage, not a universal switch: an attacker with less hash rate can sometimes reorganize a shallow block by chance, while temporary majority power does not guarantee a profitable attack.

The label should not be transferred mechanically to proof-of-stake (PoS). Voting thresholds, fork choice, finality, inactivity penalties, and slashing are protocol-specific. For example, Ethereum documents different consequences at roughly 33%, 34%, 51%, and 66% of stake. The relevant question is always which consensus rule and which attack objective are under discussion.

How it works

PoW nodes accept only valid blocks and follow the valid branch with the most cumulative work. A majority attacker cannot make an invalid signature valid or create coins outside the protocol rules. The attacker can, however, privately mine a conflicting valid branch and reveal it after it overtakes the public branch.

A typical double-spend sequence is:

1. The attacker pays a merchant or exchange on the public chain while privately mining a branch that spends the same coins elsewhere.
2. The recipient waits for confirmations and then releases goods or permits a withdrawal.
3. If the private branch accumulates more work, the attacker publishes it. Nodes reorganize to that branch, and the original payment disappears from the accepted history.

Each additional confirmation gives the honest branch a larger lead. When the attacker has less hash rate than the honest network, the probability of catching up falls as that lead grows; with a sustained majority, the attacker can reliably outpace the honest branch over time. Confirmations reduce risk, but they do not create absolute finality.

The same control can be used to censor or delay selected transactions, reorder recent transactions, and disrupt confirmations. It cannot steal coins protected by someone else’s private key, spend coins that do not belong to the attacker, or force full nodes to accept blocks that violate consensus rules.

Example

Assume an illustrative small PoW network has 1 TH/s of honest hash rate. An attacker can rent 1.2 TH/s for $20,000 per hour, giving the attacker about 54.5% of the combined 2.2 TH/s while the rental is active. The attacker deposits tokens worth $200,000 at an exchange and simultaneously mines a private branch containing a conflicting spend.

If the exchange credits the deposit after 10 blocks, or about 20 minutes on this hypothetical chain, the attacker may withdraw another asset before publishing the private branch. A two-hour rental costs $40,000, but that figure is not the attacker’s profit. Trading fees, slippage, failed execution, withdrawal freezes, detection, and a fall in the attacked asset’s price can make the attempt unprofitable.

If the exchange raises its requirement to 200 blocks, the attacker must sustain the competing branch for much longer. At the assumed two-minute block interval, that is about 6 hours 40 minutes of confirmation time. The attack becomes more expensive and easier to detect, while legitimate customers also wait longer. A confirmation policy therefore trades settlement speed against reorganization risk.

Risks and controls

The most exposed targets are recent, high-value payments that can be converted or withdrawn before an operator reacts. Rewriting history from thousands of blocks ago would require rebuilding all subsequent work and overtaking the live chain, so practical attacks usually focus on a short, valuable window.

Economic security depends on more than a token’s market capitalization. Relevant factors include rentable hash rate, specialized hardware supply, electricity and coordination costs, mining-pool concentration, block rewards, market liquidity, and the value that a recipient releases after confirmation. Pool concentration is a warning signal, but pool operators do not necessarily own the miners’ equipment; miners can redirect hash rate.

Recipients and infrastructure operators can reduce exposure by:

• setting confirmation requirements according to transaction value and current network conditions;
• monitoring competing branches, unusual hash-rate shifts, and deep reorganizations;
• pausing deposits or withdrawals when reorganization risk rises; and
• limiting how much irreversible value can leave during one confirmation window.

These controls reduce expected loss; none makes a probabilistic PoW settlement mathematically irreversible.

Common misconceptions

Myth 1: An attacker needs exactly 51.0%

No. Below 50%, an attacker can still catch up by chance, especially from a shallow deficit, but the probability falls as confirmations accumulate. Above 50%, sustained hash-rate control gives the attacker an expected long-run advantage. Duration, network conditions, cost, and the chosen objective still matter.

Myth 2: Majority hash power can steal every coin

No. Consensus power affects which valid history is selected; it does not reveal private keys or authorize invalid spends. A majority attacker mainly gains the ability to reverse the attacker’s own recent payments, censor transactions, and reorder recent blocks.

Myth 3: A fixed confirmation count is always safe

No fixed count fits every chain or payment. Risk depends on the attacker’s available hash rate, the honest network’s security budget, transaction value, detection and response time, and how quickly the received asset can be withdrawn or converted.

Related topics

• Chain reorganization (reorg)
• Is a governance delegation signature safe?
• Hash rate
• Liquid staking
• Proof of work (PoW)

Sources

• Bitcoin: A Peer-to-Peer Electronic Cash System - Bitcoin.org (accessed: 2026-08-20)
• Block Chain - Bitcoin Developer Guide (accessed: 2026-08-20)
• Proof-of-stake attack and defense - Ethereum.org (accessed: 2026-08-20)