Double spend

Digital money is copyable by nature, and stopping the copy is the problem bitcoin was built to solve. Every coin is an output that can be consumed exactly once, and the ledger settles disputes by burying one version under blocks: after six confirmations, roughly an hour, undoing it means out-mining the whole network. Until a payment confirms, treat it as a promise rather than money received.

How it works

Spending bitcoin means consuming specific outputs, each identified by the transaction that created it and its position in that transaction. Full nodes keep a set of all unspent outputs, and validation is a lookup: if the output your transaction names is not in that set, the transaction is invalid and gets dropped, no matter how well signed it is.

That makes a confirmed double spend impossible by construction. The interesting cases all happen before confirmation, and there are three of them.

The common one is replacement. Two transactions that spend the same output are conflicting, and only one can survive. Nodes accept whichever arrived first and normally ignore the second, but they will forward a replacement that pays a higher fee. Since Bitcoin Core 28.0, released in October 2024, the -mempoolfullrbf setting defaults to on, meaning a node will relay a conflicting higher-fee transaction whether or not the original asked to be replaceable. Anything unconfirmed is fair game.

The second is a race. The attacker broadcasts one transaction to the merchant's node and a conflicting one to the rest of the network at the same moment, betting that the version paying themselves reaches miners first. No fee premium is needed, only better connectivity.

The third is a reorg, which requires majority hash power and is discussed under 51% attack. It is the only method that can undo a payment already in a block.

Bitcoin's own code has been wrong about this exactly once in public. CVE-2018-17144, disclosed in September 2018, was a bug that let a transaction spend the same input twice without crashing the node that checked it. Bitcoin Core 0.16.3 shipped the fix within days, and no chain damage occurred, but it is a useful reminder that the guarantee is enforced by software people have to keep auditing.

Why this matters when you buy bitcoin

Buyers are almost never the victim of a double spend. When you send dollars or euros to an exchange and receive bitcoin, the exchange bears the settlement risk, which is why it waits for confirmations before releasing a withdrawal and why deposits show a progress counter. Once coins arrive at an address you control, nobody can spend them again, because a spend needs your signature.

The exposure flips the moment you are the one receiving bitcoin. That happens more often than people expect: selling coins in a peer-to-peer trade, accepting bitcoin for freelance work, running a shop that takes payments. In every case, releasing goods, cash, or a bank transfer against an unconfirmed transaction is the mistake. Wait for at least one block, and for larger amounts wait for several.

There is also a whole scam genre built on the phrase. Sellers on messaging apps and video sites offer "double spend software", "flash BTC", or tools that supposedly generate spendable coins for a fee. Nothing they sell works, because the invalid transaction is rejected by every node on the network; the product is the fee you paid. Our security guide covers the family of frauds this belongs to.

Lightning changes the shape of the problem rather than removing it. Payments settle in seconds against a channel balance, so a merchant does not need to wait for blocks, and the double spend question moves to whether a channel partner tries to broadcast an old state, which watchtowers exist to punish.

Replacing an unconfirmed payment, step by step

Replacing an unconfirmed payment is the cheap version of the attack, and it is worth walking through with real numbers.

Alice buys a laptop and pays 0.01 BTC. Her wallet builds a one input, two output SegWit transaction of about 141 virtual bytes and attaches 3 sat/vB, a fee of 423 satoshis. The shop's terminal shows the payment as received and the laptop goes out of the door.

Before a block arrives, Alice broadcasts a second transaction spending the same input, this time sending the coins to her own address, with a fee of 20 sat/vB, or 2,820 satoshis. Miners take the version worth more to them. When the block lands, the shop's payment is gone from the mempool and will never confirm. Alice spent an extra 2,397 satoshis, well under a dollar at most prices, and kept both the laptop and the coins.

Nothing in that sequence is exotic, and no hash power was involved. The defense costs nothing either: wait one block, about ten minutes on average, and the replacement window closes.

Double spend vs replace-by-fee

Replace-by-fee is the same mechanism used honestly. When your own payment is stuck, you rebroadcast it with a higher fee to the same recipient, and the network happily replaces the old version. A double spend uses that machinery to change who gets paid. Relay policy cannot tell the two apart, because the difference is intent expressed in the outputs, which is why merchants who accept unconfirmed payments now assume every one of them is replaceable.

Double spend vs transaction malleability

Malleability changes a transaction's identifier without changing what it pays. The coins still move to the intended recipient; only the txid you were tracking becomes stale, which historically broke exchange accounting and Mt. Gox's withdrawal system in February 2014. SegWit, activated in August 2017, removed third-party malleability by moving signatures outside the data that gets hashed into the txid. A malleated transaction is a bookkeeping problem; a double spend is a payment that vanishes.