Send a friend a photo and you still have it. Money that exists only as data has the same flaw: without some extra rule, you could send the same digital coin to two people and keep it as well. That is the double spending problem, and every kind of electronic money has had to solve it. Bitcoin solves it with a public record that puts every payment in order. The defence is strong, with two weak spots: the minutes before a payment is written into that record, and the rare moments when the network keeps two versions of it.
One of those moments came on the night of 11 March 2013. A software upgrade accidentally split the Bitcoin network, and for a few hours two versions of the record grew side by side. One user, by his own account on the Bitcoin forum, paid 211.9 bitcoin, about 10,000 dollars at the time, to the payment service OKPay on one version, while a second transaction sending the same coins back to himself went into the other. When miners brought the network back to a single version, the one that won did not contain his payment to OKPay. It simply vanished.
Bitcoin developers’ post-mortem of the fork, BIP 50, confirms “at least one large double spend” and says it was done by someone experimenting to see whether it was possible, and “was not intended to be malicious”. It is the best-known double spend of a confirmed payment on Bitcoin itself. It also shows the rule the rest of this lesson turns on: when two payments spend the same coins, only one survives, and everything depends on which one the network keeps.
What is the double spending problem?
The double spending problem is the risk that the same unit of digital money is spent more than once, because a file or a message can be copied at no cost. Any electronic cash system has to make sure that, when two payments use the same funds, only one of them counts and everyone agrees which one.
Why a digital coin can be copied and a banknote cannot
A banknote is a physical object. When you hand it to a shopkeeper, you no longer have it, and nobody needs to check a register to know that. A digital coin is a string of bytes, and bytes can be copied as often as you like at no cost. Send a “coin file” by email and you still have it on your computer, ready to send again.
Digital signatures do not fix this. A signature proves that the owner approved a payment; it says nothing about whether the owner already approved another payment of the same coin to someone else. Two perfectly valid, perfectly signed transactions can spend the same funds. The receiver of either one cannot tell, by looking at it alone, that the other exists.
A double spend is about order, not forgery
The trick, then, is not to stop people from writing a second payment. Anyone can write one. The real task is to decide which of two conflicting payments came first and to make everyone accept that decision. Satoshi Nakamoto put the rule plainly in section 2 of the Bitcoin white paper: “the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend.”
The same section points to the hard part: “The only way to confirm the absence of a transaction is to be aware of all transactions.” To know that a coin was not spent before, you need a complete, shared record of every payment and its order. For decades, the only way anyone knew how to build that record was to hand it to one trusted party.
Before Bitcoin, a central book-keeper settled every dispute
Banks and card networks: one ledger, one clerk
Your bank account is not a pile of coins. It is a line in a database the bank controls. When you pay by card or transfer, the bank or the card network writes the debit, checks your balance and refuses the second payment if the money is gone. A double spend is impossible in that design because a single clerk sees every request and puts them in order. The price is that you depend on that clerk: it can freeze, reverse or refuse a payment, and its records are the only truth.
Chaum’s mint: online checks, then catching cheaters later
The first serious attempts at digital cash kept a book-keeper. In David Chaum’s eCash, a bank or “mint” issued coins and checked each one when it was spent, refusing any coin already seen. Our lesson on digital money before Bitcoin tells that story, along with Hashcash, b-money and bit gold. The point that matters here is what happened when the mint was offline: the system could not stop a double spend, only reveal the cheater afterwards. Hal Finney, explaining Chaum’s offline scheme in 1993, summed up the promise as “Anonymity as long as you don’t cheat, and double-spenders get caught” (“Detecting Double-Spending”).
Nakamoto’s paper describes that model and its weakness in one sentence: a common answer is “to introduce a trusted central authority, or mint, that checks every transaction for double spending.” Everything then depends on the company running the mint, with every payment going through it, “just like a bank”. Bitcoin’s goal was to keep the protection and remove the mint.
How Bitcoin solves double spending without a central party
The abstract of the white paper states the ambition in one line: “We propose a solution to the double-spending problem using a peer-to-peer network.” The solution has several parts, and each one is simple on its own. Our guide to the Bitcoin white paper explained summarises the full document; this lesson follows only the double-spending thread.
Every payment is announced to everyone
Instead of sending a payment to one clerk, a Bitcoin wallet broadcasts it to the whole network of computers running the software, called nodes. Each node passes it on to others. The white paper’s section 2 says transactions must be “publicly announced” so that participants can agree on one history of the order in which they were received. Once a payment is public, a second payment of the same coins is public too, and conflicts can be seen.
Blocks put payments in a public order
Seeing a conflict is not enough: nodes may hear the two payments in a different order, depending on where they sit in the network. Section 3 of the paper begins: “The solution we propose begins with a timestamp server.” Bitcoin groups payments into blocks, and each block contains a fingerprint of the previous one, so the blocks form a chain in time. A payment included in a block has a position in that chain; a conflicting payment can only come later, and later loses.
That is what a confirmation means. A payment gets its first confirmation when it is included in a block, and one more each time a new block is added on top. The deeper it sits, the harder it is to move.
Nodes refuse any coin that is already spent
Bitcoin does not track balances. It tracks unspent outputs: each payment consumes earlier outputs whole and creates new ones, as explained in the previous lesson on the UTXO and account models. Every node keeps the list of outputs that are still unspent. When a transaction tries to spend an output that is no longer on that list, the node rejects it, and a block containing it is invalid for every honest node. A double spend is therefore not a trick of accounting; it is a fight over which of two valid-looking transactions makes it into the shared history first.
Two blocks at once: the chain with the most work wins
Sometimes two miners find a block at almost the same moment, and for a short while the network holds two versions of the latest page. Our lesson on how a blockchain works shows how this resolves: miners keep building, one branch pulls ahead, and every node switches to it. The paper’s rule is that “Nodes always consider the longest chain to be the correct one and will keep working on extending it.”
“Longest” needs care. In section 4, the paper says the majority decision is the chain “which has the greatest proof-of-work effort invested in it”. It is the chain with the most accumulated work, not the most blocks, and that is what Bitcoin Core software actually compares. Producing that work costs real electricity and hardware, which is why rewriting a blockchain’s history has a price.
When nodes switch from one branch to another, the blocks of the abandoned branch drop out. Engineers call this a reorganisation, or reorg. Any payment that was only in the abandoned branch loses its confirmations, and if a conflicting payment sits in the winning branch, the first one can never be included. A reorg is the moment a double spend becomes real.
What an attacker can and cannot do
Section 11 of the paper is precise about the limits of a cheater, even one with a lot of computing power. It says that “An attacker can only try to change one of his own transactions to take back money he recently spent.” He cannot create coins out of nothing or spend coins that were never his, because honest nodes reject invalid transactions whatever the chain. The danger is narrow: a recent payment by the attacker, reversed after the victim has handed over goods or money.
Five ways people try to spend twice
The Bitcoin wiki’s page on irreversible transactions lists the classic double-spending attacks. They differ by when they strike and by how much power the attacker needs. Some need nothing more than a wallet. The strongest needs hashrate, the computing power spent on mining, which is the resource that decides which version of the record wins.
| Attack | When it works | Who can do it | Main defence |
|---|---|---|---|
| Race attack | Payment accepted with zero confirmations | Anyone with a wallet | Wait for at least one confirmation |
| Replace-by-fee swap | Payment accepted with zero confirmations | Anyone with a wallet | Never treat an unconfirmed payment as paid |
| Finney attack | Payment accepted with zero confirmations | A miner who finds blocks | Wait for confirmations |
| Vector76 | Payment accepted after one confirmation | A miner, with good network position | Wait for several confirmations |
| Majority (51 percent) attack | Even after many confirmations | Whoever controls most of the hashrate | More confirmations raise the cost; small chains need many more |
Race attack: two conflicting payments at once
The simplest attempt needs no special equipment. The cheater sends a payment to a merchant and, at nearly the same moment, sends a second transaction spending the same coins to his own address, pushed to as many nodes and miners as possible. If the second one reaches miners first, it gets into a block and the merchant’s payment is dropped. The Bitcoin wiki says merchants can reduce the risk, for example by connecting to well-connected nodes, but “the risk cannot be eliminated”. It only works against someone who accepts a payment before it is confirmed.
Replace-by-fee: when the sender is allowed to swap a payment
Replace-by-fee (RBF) is a normal feature, not an attack: it lets a sender replace an unconfirmed transaction with a new version paying a higher fee, usually to unstick a payment. Our guide to how crypto transactions work shows how a user does it. The catch for receivers is that the new version can also send the money somewhere else.
At first replacement was opt-in. Under BIP 125, assigned in December 2015, a transaction signalled that it could be replaced, and the proposal noted that receivers may choose not to treat such a payment as paid until it confirms. That distinction has gone. Bitcoin Core 28.0, released on 2 October 2024, made full replace-by-fee the default, and Bitcoin Core 29.0, released on 14 April 2025, removed the option to turn it off. On Bitcoin Core, the software most nodes run, any unconfirmed payment can be replaced by a conflicting one that pays more, whether it signalled or not. This is relay policy, not a consensus rule: miners can run other software, but a merchant cannot count on them doing so.
Finney attack: a miner hides a block
On 13 February 2011, Hal Finney described on the Bitcoin forum a cheat available to a miner. His post opens with “Suppose the attacker is generating blocks occasionally.” The miner puts a transfer between two of his own addresses into a block he has found but not yet published. He then pays a merchant with the same coins. If the merchant hands over the goods without waiting, the miner releases his block, which already spends the coins, and the payment to the merchant becomes invalid. The scenario now carries Finney’s name. It needs mining power and some luck with timing, and like the race attack it defeats only zero-confirmation acceptance.
Vector76: one confirmation is not always enough
The Vector76 attack mixes the two previous ones. The attacker mines a block containing a deposit, sends it only to the victim, typically an exchange, and lets the rest of the network build on a block with a conflicting transaction. The victim briefly sees one confirmation, credits the deposit and lets the attacker withdraw; when its node catches up with the rest of the network, the deposit vanishes. The attacker sacrifices a block reward to do it, so it makes sense only against a large, fast payout. One confirmation is far better than none, but it is not a guarantee.
Majority attack: rewriting recent history
The serious version is the one the white paper models. An attacker mines a secret branch in which his payment to the victim never happened, waits until the victim delivers, then publishes his branch. If his branch has more accumulated work than the public one, every node switches to it, and the victim’s payment is gone. Whoever controls more than half of the network’s hashrate can win this race in the end, which is why it is called a 51 percent attack. Below half, the attacker’s chance falls quickly with each confirmation the victim waits for.
Nakamoto’s own figures, in the same section 11, give the attacker’s chance of ever catching up, depending on his share of the hashrate and on how many confirmations the victim waits for:
| Attacker’s share of hashrate | Confirmations waited | Probability the attacker catches up (white paper) |
|---|---|---|
| 10 percent | 1 | 0.2045873 |
| 10 percent | 5 | 0.0009137 |
| 10 percent | 6 | 0.0002428 |
| 30 percent | 5 | 0.1773523 |
| 30 percent | 10 | 0.0416605 |
| 30 percent | 24 | under 0.001 (the paper’s second table) |
| 30 percent | 50 | 0.0000006 |
In plain terms: with 10 percent of the hashrate, an attacker facing six confirmations succeeds about 2.4 times in 10,000 attempts in the paper’s model. With 30 percent, five confirmations still leave him a chance of almost 18 percent, and the victim needs 24 confirmations to bring the risk below 0.1 percent. Later analyses using different assumptions give higher figures, so treat the table as the paper’s simplified model rather than a precise forecast. Above 50 percent, no number of confirmations protects the victim; the wiki says “No amount of confirmations can prevent this attack”, although waiting raises the attacker’s cost. A later Coindaro lesson on 51 percent attacks will go further into their economics.
Real double spends, from 2013 to 2020
Double spends have happened, and the record shows a clear pattern: one on Bitcoin, during an accidental split, and the rest on smaller proof-of-work chains whose hashrate could be rented. Our guide on whether a blockchain can be hacked tells the Bitcoin Gold and Ethereum Classic cases in detail; here is the short version.
| Date | Chain | What happened | Reported amount (at the time) | Source |
|---|---|---|---|---|
| 11-12 March 2013 | Bitcoin | Accidental split between 0.8 and older nodes; a 211.9 BTC payment to OKPay reversed | about 10,000 dollars, by the user’s own account | BIP 50; the user’s forum thread |
| From 18 May 2018 | Bitcoin Gold | Attacker with majority hashrate double spent deposits at exchanges | more than 388,000 BTG through the attacker’s address; over 18 million dollars, BleepingComputer’s estimate | BleepingComputer, 24 May 2018 |
| From 5 January 2019 | Ethereum Classic | Deep reorganisations with double spends detected by Coinbase | 219,500 ETC in 13 double spends, about 1.1 million dollars | Infosecurity Magazine, 8 January 2019 |
| August 2020 | Ethereum Classic | Three reorganisations in one month, of 3,693, about 4,000 and more than 7,000 blocks | not given in the source | The Block, 31 August 2020 |
March 2013 was not an attack. According to BIP 50, a block that version 0.8 accepted was rejected by some older nodes, the 0.8 side held around 60 percent of the hashpower, and two large pools downgraded to the old version to end the split. The double spend worked even though both sides had seen the transactions in the same order, most likely because memory pools were cleared when the smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool nodes restarted. The user’s own account of the payment is in a forum thread of 12 March 2013, which the post-mortem links to. By that account, the payment to OKPay was a deposit to his account at the exchange BTC-e, and the two conflicting transactions were mined at the same height, block 225,446, one on each branch.
Bitcoin Gold, a 2017 fork of Bitcoin, was hit by an attacker who controlled more than half of its mining power. According to BleepingComputer, the attacks began on 18 May 2018, the attacker deposited coins at exchanges while sending the same coins to his own wallet, and more than 388,000 BTG passed through his address, which the site said suggested a gain of over 18 million dollars. The targets were exchanges, not individual holders: no user had lost money, the article said.
Ethereum Classic, the chain that kept the original Ethereum history after 2016, was attacked in January 2019. Coinbase first detected a deep reorganisation containing a double spend on 5 January, then 12 more double spends, totalling 219,500 ETC, about 1.1 million dollars at the time, as reported by Infosecurity Magazine. In August 2020 the chain suffered three reorganisations in one month, the last one more than 7,000 blocks deep, around two days of mining according to the mining pool operator Bitfly, according to The Block.
The lesson from these cases is about size. Rewriting Bitcoin’s chain would mean outpacing the hashrate of the largest proof-of-work network. On a chain whose entire hashrate can be rented for a few hours, the same attack can cost less than the coins it steals. After the Bitcoin Gold attack, exchanges raised the number of confirmations they required for deposits, BleepingComputer reported.
Why six confirmations, and why one is enough for a coffee
Six confirmations, about an hour on average, became Bitcoin’s customary safety margin. The lesson on the mempool and transaction fees tells where the convention comes from and how a payment moves from broadcast to block. The white paper’s table explains why it is sensible: against an attacker with 10 percent of the hashrate, six blocks bring the risk to 0.024 percent in the paper’s model.
Six is a convention, not a rule of the protocol. Each receiver chooses its own threshold, and the right number depends on two things: the amount at stake and the hashrate of the chain. Kraken, for example, credits Bitcoin deposits after three confirmations, according to its help page on deposit processing times updated on 22 October 2026. A seller of a car might wait for more than six. A café selling a 4-dollar coffee might accept the risk of zero confirmations, because the loss is small and the cheater has to stand at the counter.
For smaller proof-of-work chains, the same number of blocks buys much less security, because the cost of producing them is much lower. That is why an exchange may ask for many more confirmations on such a chain than on Bitcoin.
Zero-confirmation payments: the merchant’s real risk
An unconfirmed payment is a promise that has been announced, not a payment that has been settled. Between the moment a wallet shows “received” and the first block, the sender can still try a race attack or, with today’s default node software, simply broadcast a replacement paying a higher fee. At 09:50 UTC on 7 November 2026, mempool.space recommended 2 satoshis per virtual byte for the fastest confirmation, so a replacement could cost a cheater very little.
Researchers raised the alarm early. In a 2012 paper, “Two Bitcoins at the Price of One?”, Ghassan Karame, Elli Androulaki and Srdjan Čapkun started from a fast-food restaurant that accepted bitcoin, and showed that double spends against such fast payments could be mounted at low cost on the Bitcoin software of the time.
For a merchant, the practical rules are short:
- Treat a payment with zero confirmations as not yet received, unless the amount is one you are ready to lose.
- Ship goods or release funds only after the number of confirmations you have chosen for that amount.
- Ask for more confirmations on a chain with low hashrate than on Bitcoin.
- For small, instant payments, use a system built for them, such as a payment channel network like Lightning, rather than unconfirmed on-chain transactions.
Ethereum and other account chains: the nonce does the job
Ethereum does not use unspent outputs. It keeps a balance for each account, and every transaction carries a nonce, which ethereum.org’s page on transactions describes as “a sequentially incrementing counter which indicates the transaction number from the account”. The first transaction of an account uses nonce 0, the next nonce 1, and so on.
The nonce plays the role that “already spent output” plays on Bitcoin. Two transactions from the same account with the same nonce conflict, and only one of them can ever be included in the chain. The lesson on UTXO and account models shows the other side of this rule, the stuck nonce that blocks every later transaction.
The zero-confirmation logic is the same as on Bitcoin. A pending Ethereum transaction can be replaced by another one with the same nonce and a higher fee; the default rules of Geth, a widely used Ethereum client, ask for a fee at least 10 percent higher. A payment that is still pending is not a payment.
Ethereum also closed a door that opened when the chain split in 2016. With EIP-155, a transaction signs the identifier of the chain it is meant for, so it cannot be copied and replayed on another chain that shares the same history. Since its move to proof of stake, Ethereum also marks blocks as final after a delay, a subject for a later lesson on finality and reorganisations.
Solana: a recent blockhash that expires
Solana takes another route. Each transaction must include a recent blockhash, a reference to a recent block, and validators accept it only for a limited time: the Solana SDK sets the maximum age at 150 recent blockhashes, a minute or less at Solana’s speed. A transaction that is too old is rejected, so a signed payment cannot sit around for days waiting to be replayed. Within that window, validators also keep track of the signatures they have already processed and refuse the same transaction a second time. Conflicting spends from one account are simply ordered by the validator producing the block.
Proof of stake: “double signing” is a different double
On proof-of-stake chains, the word “double” appears in another sense. Validators, who lock up coins to take part, are punished by slashing if they sign two conflicting versions of history. ethereum.org’s page on rewards and penalties lists three offences: proposing and signing two different blocks for the same slot, attesting to a block that “surrounds” another one, and double voting, that is attesting to two candidates for the same block.
That is not a user paying twice. It is a validator trying to support two histories, the very thing a deep double spend would need. Slashing burns part of the validator’s stake and forces it out, so the attempt is both costly and traceable to whoever made it. A user who sends two conflicting payments is not slashed; one payment simply fails.
No chargeback in crypto: how card and bank refunds compare
The flip side of Bitcoin’s design is that a confirmed payment has no clerk who can reverse it. The white paper presents this as a feature for sellers: “Transactions that are computationally impractical to reverse would protect sellers from fraud.” For a buyer who paid a scammer, it means the money is gone. The US Federal Trade Commission’s consumer advice on crypto scams says it bluntly: “Cryptocurrency payments typically are not reversible.”
Compare that with the protections American consumers have on bank and card payments. Under Regulation E, the CFPB’s rule on electronic transfers, a consumer’s liability for unauthorized transfers is capped at 50 dollars when the bank is notified within two business days of learning of a lost or stolen card, and at 500 dollars after that, with a 60-day window after the statement to report unauthorized transfers. Under Regulation Z, a credit card holder’s liability for unauthorized use is capped at 50 dollars, and a billing error notified within 60 days of the statement must be resolved within two billing cycles and never more than 90 days.
In the United Kingdom, the Payment Services Regulations 2017 require a provider to refund an unauthorised payment by the end of the next business day after it learns of it, unless it has reasonable grounds to suspect fraud. Section 75 of the Consumer Credit Act 1974 makes a card issuer jointly liable with the seller for single purchases above 100 pounds and up to 30,000 pounds. Since 7 October 2024, even victims of authorised push payment scams, who sent money to a fraudster themselves by Faster Payments or CHAPS, can be reimbursed up to 85,000 pounds. The Payment Systems Regulator set that limit for Faster Payments, and the Bank of England, which runs CHAPS, chose the same one.
Nothing like this exists on a public blockchain. An exchange can refund a customer out of its own pocket, and a recipient can choose to send coins back, but the protocol has no dispute button. The FTC puts it this way: “you can usually only get your money back if the person you paid sends it back.” Our guide on how to avoid crypto scams covers the habits that matter most when there is no chargeback.
What to remember as a user or a merchant
A public, ordered record lets strangers agree which payment came first without a bank. It does not protect a payment that is not yet in that record, or one that sits on a chain cheap to rewrite, and a few habits follow from that.
- An unconfirmed payment can still be replaced or dropped: treat it as a pending promise.
- Size the wait to the amount: the larger the sum, the more confirmations before you release goods or funds.
- A small proof-of-work chain needs many more confirmations than Bitcoin, because its hashrate is cheaper to rent.
- A confirmed crypto payment to a scammer cannot be charged back; check the address and the recipient before you send.
- On Ethereum, a pending transaction can be replaced by another with the same nonce; on Bitcoin, any unconfirmed one can be replaced with a higher fee.
The next lesson in this path looks at finality and reorganisations: how deep a reorg can go on different chains, and when a payment can be called final rather than just very likely to stay.
