Double spending is the attempt to pay with the same digital coins twice. On a public blockchain, every full node rejects any transaction that spends coins already spent in the agreed transaction history. So in practice the attack works only one way: the attacker gets that history rewritten. They either get a payment replaced before it is confirmed in a block, or they control enough mining or staking power to reorganise blocks that were already confirmed. Large networks make the second option very expensive. Smaller proof-of-work chains have been hit repeatedly. The most recent widely reported case is a six-block reorganisation of Monero in August 2025.
Why digital money has this problem
A digital payment is just data, and data can be copied. Banks and card networks deal with this by keeping one central ledger that decides which payment came first. The Bitcoin whitepaper (Satoshi Nakamoto, 2008) set out to remove that central party. It states the problem plainly: "The problem of course is the payee can't verify that one of the owners did not double-spend the coin." It also notes that the main benefits of electronic cash "are lost if a trusted third party is still required to prevent double-spending."
The whitepaper's answer is a public, timestamped chain of blocks secured by proof of work, with one rule for disputes: "Nodes always consider the longest chain to be the correct one and will keep working on extending it." In practice, nodes follow the valid chain with the most accumulated work.
How a double spend is attempted
Before confirmation: race and Finney attacks
A broadcast transaction sits unconfirmed until a miner includes it in a block. The Bitcoin Wiki describes two attacks that target merchants who treat an unconfirmed payment as final:
- Race attack. The attacker pays the merchant and also sends "a conflicting transaction spending the coin to himself" to the rest of the network. If the conflicting transaction is mined first, the merchant's payment becomes invalid.
- Finney attack. This one requires a miner. The attacker mines a block that pays the coins back to themselves and holds it back. They then pay the merchant with the same coins and release the hidden block once the goods are handed over. The attack is named after Hal Finney, who described it on the Bitcoin forum in 2011.
The Wiki also describes a Vector76 attack, which combines the two and can reverse a payment that has one confirmation.
After confirmation: the majority (51%) attack
If an attacker controls more than half of a network's hashrate, they can mine a private chain that grows faster than the public one. They pay a victim on the public chain and wait until the victim delivers. Then they publish the longer private chain, which leaves out that payment. Nodes switch to the chain with more work, and the payment disappears. The Bitcoin Wiki says such an attack has "a probability of 100% to succeed," and that no number of confirmations can prevent it.
Not every reorganisation is an attack. Short reorgs happen naturally when two miners find blocks at almost the same time. Size and intent make the difference.
How long should you wait before a crypto payment counts as final?
Answer a few questions about the chain, the amount and the attacker to see what the article says about waiting.
Which kind of chain is the payment on?
- Proof-of-stake Ethereum → next question
- A large proof-of-work chain such as Bitcoin → next question
- A small proof-of-work chain → next question
Is the amount large for you?
- Yes, it is large → Wait for finality, about 15 minutes
- No, it is small → Still do not treat an unconfirmed payment as final
Can hashpower for this coin's mining algorithm be rented in amounts close to the chain's total hashrate?
- Yes, or I cannot rule it out → Confirmations alone will not protect you
- No, the chain's hashrate is far larger than what can be rented → next question
Does the amount matter to you?
- No, it is small and I receive many such payments → Consider a payment channel
- Yes, the amount matters → next question
How much of the network's hashrate could an attacker plausibly gather?
- About 10% → About 5 blocks keeps the risk below 0.1%
- About 30% → About 24 blocks keeps the risk below 0.1%
- More than 50% → Confirmations alone will not protect you
On proof-of-stake Ethereum, a block finalises in about 15 minutes, once validators holding a two-thirds supermajority of the stake vote for its checkpoint. Reverting a finalised block would cost an attacker at least one-third of all staked ETH through slashing, so for large amounts wait for finality rather than relying on the latest block alone.
Race and Finney attacks work only against payees who accept zero confirmations. The article's finality advice targets large amounts; for a small amount, at least wait until the payment is included in a block, and be aware that only a finalised block carries Ethereum's economic protection.
For frequent small payments, the Lightning Network settles them instantly off-chain. If a channel partner publishes an old, revoked state, the honest party can use a penalty transaction to take the channel's funds. Accepting an unconfirmed on-chain payment instead leaves you open to race and Finney attacks.
The Bitcoin whitepaper's table says an attacker with 10% of the hashrate has less than a 0.1% chance of catching up once you wait 5 blocks. The common six-confirmation rule gives roughly a 0.1% success chance against such an attacker. It is a convention, not a protocol rule, and the risk never reaches zero.
Against an attacker with 30% of the hashrate, the whitepaper's table needs 24 blocks to keep the attacker's chance below 0.1%. The more hashrate an attacker could gather, the more blocks you need to wait.
An attacker with more than 50% of the hashrate can outrun any number of confirmations; the Bitcoin Wiki says such an attack has a probability of 100% to succeed. Small proof-of-work chains whose hashpower can be rented have been hit repeatedly. Watch for reorganisations far deeper than normal, which were the visible sign of every attack in the article's table.
This follows the article's general guidance only: it cannot measure a chain's real hashrate or rental market, it gives no confirmation count for any specific coin, and it does not cover wallet, custody or exchange risks.
What actually stops it
Each coin can be spent once
Bitcoin tracks coins as unspent transaction outputs (UTXOs). A transaction uses up specific outputs and creates new ones: the payment, plus change back to the sender. Once an output is spent in the accepted chain, every honest node rejects any later transaction that tries to spend it again. So two conflicting payments can never both be confirmed on the same chain. The only question is which one ends up in the accepted history.
Confirmations make rewriting expensive
Each block mined on top of a transaction is another confirmation. Section 11 of the whitepaper calculates the attacker's chance of catching up. To keep that chance below 0.1%:
| Attacker's share of hashrate (q) | Blocks to wait (z) for P < 0.1% |
|---|---|
| 10% | 5 |
| 30% | 24 |
The widely used rule of waiting six confirmations on Bitcoin is a convention, not a protocol rule. The Bitcoin Wiki's example shows the reasoning: an attacker with 10% of the hashrate, facing a merchant who waits for six confirmations, has a success chance of roughly 0.1%. Bitcoin's finality is probabilistic. A reversal gets less likely with every block but is never mathematically impossible. And if the attacker's share passes 50%, waiting longer stops helping.
Proof of stake adds economic finality
Ethereum switched from proof of work to proof of stake in September 2022. Time is divided into 12-second slots and 32-slot epochs, and according to ethereum.org it "takes about 15 minutes for an Ethereum block to finalize." Checkpoints become final once validators holding a two-thirds supermajority of the stake vote for them. The thresholds, as ethereum.org describes them:
- With one-third of the stake, an attacker can stop the chain from finalising, though not rewrite it. The protocol's inactivity leak then slowly drains the stake of validators who stop voting.
- To revert a finalised block, an attacker "would commit to losing at least one-third of the total supply of staked ETH" through slashing.
- With more than half the stake, an attacker can censor transactions and do short-range reorgs. With two-thirds, they can finalise the chain they prefer.
The protection is not that an attack is impossible. It is that reversing a finalised payment would cost the attacker a very large, provable loss.
Fixing transaction malleability
Before SegWit, a transaction's ID could be changed without invalidating its signature. That confused wallets and services that tracked payments by ID. Segregated Witness (BIP141) moved signature data out of the transaction hash, and the proposal says this makes "nonintentional malleability" impossible. SegWit activated on Bitcoin at block 481,824 on 24 August 2017. This fixed a bookkeeping weakness. It did not change the consensus rules against double spending.
Payment channels with penalties
The Lightning Network moves repeated small Bitcoin payments off-chain into payment channels. If a channel partner tries to cheat by broadcasting an old, revoked channel state, the Lightning specification (BOLT) lets the honest party use a "penalty transaction" that, using the revocation key, "spends all outputs of a revoked commitment transaction." In other words, the honest party can take the channel's funds.
Documented attacks
Every successful majority attack in this table hit a proof-of-work chain with far less hashrate than the largest network using the same mining algorithm.
| Date | Network | What happened | Reported amount |
|---|---|---|---|
| Aug 2025 | Monero | Six-block reorganisation, about 60 blocks orphaned, after the mining pool Qubic claimed majority hashrate | No double spends reported |
| 6 Aug 2020 | Ethereum Classic | Second attack in about five days, reorganising more than 4,000 blocks | Value not reported at the time (The Block) |
| 31 Jul–1 Aug 2020 | Ethereum Classic | Private chain published after 3,500+ blocks were mined in about 12 hours, using rented hashpower | 807,260 ETC, about $5.6 million (Bitquery) |
| Jan 2019 | Ethereum Classic | Majority attack with chain rewrite | About $1.1 million spotted (MIT Technology Review) |
| Autumn 2018 | Vertcoin | Series of 51% attacks | About $100,000 (MIT Technology Review) |
| May 2018 | Bitcoin Gold | 51% attack; Bitcoin Gold's team said exchanges, not individual users, lost funds | 388,000 BTG, about $18 million (reported) |
| Mar 2013 | Bitcoin | Accidental chain split between versions 0.8 and 0.7 | "At least one large double spend" (BIP 50) |
Reading these cases
- Monero, August 2025. The Block reported on 12 August 2025 that Qubic's founder said the pool had "achieved 51% over Monero." Developer Luke Parker disputed the claim, saying Qubic "may have 51% of the estimated hash rate/mined blocks but less than 51% of overall hash rate." Halborn noted that a six-block reorg "doesn't necessarily mean that a 51% attack succeeded," since a large but non-majority miner can get lucky. Whether Qubic ever held a true majority remains disputed.
- Ethereum Classic, 2020. Bitquery estimated that the attacker spent about 17.5 BTC (about $192,000) renting hashpower. This shows how cheap majority control of a small chain can be compared with the amount stolen. The block counts and amounts come mainly from that one analysis.
- Bitcoin, 2013. The fork was not an attack. BIP 50 says the double spend was done by "someone experimenting to see if it was possible" and was "not intended to be malicious." It also shows that very large networks can face double-spend risk during software failures.
Practical checklist
For anyone receiving crypto payments:
- Don't treat an unconfirmed payment as final if the amount matters to you. Race and Finney attacks work only against payees who accept zero confirmations.
- Scale the wait to the amount and the chain. Use the whitepaper's table as a guide. The more hashrate an attacker could plausibly gather, the more blocks you need.
- Be careful with small proof-of-work chains. If hashpower for a coin's mining algorithm can be rented in amounts close to the chain's total, confirmations give much less protection. A majority attacker can outrun any number of them.
- On proof-of-stake Ethereum, wait for finality (about 15 minutes) for large amounts, rather than relying on the latest block alone.
- Watch for deep reorganisations. On every chain in the table above, a reorg far deeper than normal was the visible sign of the attack.
- Consider payment channels for frequent small payments. Lightning settles them instantly off-chain, with a penalty for publishing old channel states.
