Double spending: the problem Bitcoin was built to solve, and how it solves it

Digital money has a copying problem that cash does not

Hand someone a ten-dollar bill and you no longer have it. Send someone a digital file and you both have it. If a coin is just data, what stops the owner from paying it to one person and then paying the same coin to somebody else before the first person notices? That second payment is a double spend, and until 2008 every workable answer put a company in the middle.

The Bitcoin white paper opens with exactly this. Satoshi Nakamoto describes online commerce as relying on financial institutions to act as trusted third parties, and notes that digital signatures alone do not fix it: a payee can check that a coin was signed over to them, but cannot check that one of the previous owners did not also sign the same coin over to someone else. The usual fix was a mint, a central authority that checks every transaction for double spending. The paper’s objection is simple: the fate of the whole money system then depends on the company running the mint, “just like a bank.”

What was needed, the paper argues, was a way for the person being paid to know that earlier owners had not signed any earlier transactions. The only way to confirm that a transaction is absent is to be aware of all transactions. So Bitcoin makes every transaction public and asks the participants to agree on a single history of the order in which they arrived. For Bitcoin’s purposes, the earliest transaction is the one that counts, and later attempts to spend the same coin are simply ignored.

A valid chain resolves conflicting spends

A transaction spends an earlier output. A second transaction that tries to spend the same output conflicts with it. Nodes reject a block that spends the same output twice or otherwise violates their validation rules.

Nodes choose among valid histories using accumulated proof of work. Temporary competing tips can occur; a later reorganization can remove a transaction from the accepted chain and include a conflict. The white paper’s historical phrase “longest chain” means greatest work in its argument, not permission to accept a longer invalid chain.

The race: what a double-spend attempt looks like from a shop counter

Suppose you run a shop and a customer pays in bitcoin. The transaction reaches your node in a second or two, but it is not yet in a block. It is unconfirmed. In that window a dishonest customer can broadcast a second transaction that spends the same coins back to themselves. Now two conflicting transactions are spreading through the network at once, and whichever reaches more miners first is more likely to end up in the next block. The Bitcoin Wiki calls this a race attack.

Satoshi described the race in July 2010, in a forum thread titled “Bitcoin snack machine (fast transaction problem).” If someone broadcasts a double spend at the same time as your payment, he wrote, “it’s a race to propagate to the most nodes first,” and a slight head start spreads geometrically. He worked the example: one node, then four, then sixteen, until one version holds around 80 percent of the network and the other 20. His suggestion for vending machines and other small, fast purchases was a payment processor with connections to many nodes, one that blasts the transaction out and watches for a conflicting one, giving “good-enough checking in something like 10 seconds or less.”

The wiki lists the harder variants. In a Finney attack the customer is also a miner: they mine a block containing a transfer of the coins to themselves, keep it secret, pay you with the same coins, collect the goods, then release the block. A Vector76 attack combines the two and can reverse a payment with one confirmation, at the cost of sacrificing a block. All of them exploit the same gap: the moments before a transaction is buried under enough work to make rewriting it expensive.

Satoshi’s advice in 2008 was blunt about that gap. Receivers “will normally need to hold transactions for perhaps an hour or more” to let any such race resolve. They can re-spend the coins immediately if they like, but they should wait before doing anything irreversible, such as shipping goods.

Why confirmations matter, in the white paper’s own numbers

A confirmation is one block added to the chain at or after the block holding your transaction. Section 11 of the white paper works out what each one buys you. Picture an attacker who paid you, then secretly starts mining a rival branch in which that payment never happened. Every block honest miners find puts them one further ahead; every block the attacker finds closes the gap by one. If the attacker has less hash power than everyone else, the odds of catching up shrink exponentially with every block they fall behind.

The paper then prints a table. With 10 percent of the network’s hash power, an attacker’s chance of overturning a payment with one confirmation is about 20 percent; after three confirmations it is about 1.3 percent; after five it is below 0.1 percent. With 30 percent of the hash power, the payment needs to be 24 blocks deep before the chance drops below 0.1 percent. The lesson is not that six confirmations is a magic number. It is that the right wait depends on how much hash power you think an attacker could have and how much money is at stake.

That is where the common conventions come from. The Bitcoin Wiki gives the same 10 percent example, puts the chance at roughly 0.1 percent after six confirmations, and suggests waiting for 100 confirmations for very large payments, on the scale of a block reward. Our article on confirmations walks through what wallets and exchanges actually require and why, and the blockchain mechanics dossier explains why Bitcoin has no absolute “final” flag, only deeper and deeper burial.

What a double spend can never do, even with most of the hash power

The white paper says that even an attacker who out-mines the honest network cannot make arbitrary changes: they cannot create value out of thin air or take money that never belonged to them, because nodes will not accept an invalid transaction as payment and will never accept a block containing one. All a majority attacker can do is change one of their own recent transactions to take back money they recently spent. That is the double spend, and it is the whole of the attack.

The wiki’s majority attack page adds two facts worth knowing. No number of confirmations can stop an attacker who controls more than half of the hash rate, though waiting raises the cost. And such an attack has never been successfully carried out on the Bitcoin network, while it has been demonstrated on some small proof-of-work coins. What it takes, what it has cost elsewhere, and how close Bitcoin has come are covered in our article on the 51 percent attack.

So Bitcoin never made double spending impossible in principle. What it did was make the honest history cheap to check and expensive to rewrite, with the expense growing every block. A merchant who understands that can choose a wait to match the amount, and a customer who understands it knows why the coffee shop does not wait at all and the exchange sometimes does.

Follow the conflict at the input, not at the recipient label

Suppose one unspent output is used as an input by transaction A and also by transaction B. Both may be proposed, but an accepted valid history cannot consume that same output twice. By contrast, two payments funded from two different unspent outputs are not a double spend merely because they come from the same wallet.

The question for a recipient is which conflicting spend survives in the accepted history. Seeing a transaction first is not the same as having it included in a block, and block inclusion is not an unconditional guarantee against a later reorganization. That is why the article treats confirmation depth and attacker assumptions separately.