Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Security & Resilience

Preventing double spending

A double spend is an attempt to pay with the same coins twice. The protocol does not prevent the attempt; it resolves the conflict, because two transactions that spend the same output cannot both end up in the chain. What the protocol cannot do is tell a merchant how long to wait before handing over goods, and that judgement is where most of the practical risk lives.

Protocol referenceSource: Bitcoin: A Peer-to-Peer Electronic Cash System, section 11The confirmation-probability analysis is Nakamoto's; the merchant policy that follows from it is not specified by the protocol.

Two spends, one output

Every transaction spends outputs that were created by earlier transactions, and each output can be spent exactly once. A double spend is an attempt to break that rule: the same output is referenced by two different transactions, each signed by the same key, each paying a different recipient. Both transactions are individually valid. Only one of them can be confirmed, because a block that includes both would be spending the same output twice, and every node would reject it.

The conflict is resolved by chain selection. A node that receives two conflicting transactions will typically keep the first one it saw and reject the second, but that is a local policy choice and different nodes may make it differently. What settles the matter is which transaction ends up in a block that the network builds on. Once a transaction is buried under enough accumulated proof of work, replacing it requires producing a competing chain with more work, which is the attack analysed in the 51% attacks page.

The important asymmetry is that a double spend is only ever a reversal of the spender's own payment. An attacker cannot double spend someone else's coins, because it does not hold the key needed to sign the conflicting transaction. The attack is a way to take back money recently spent, not a way to take money that was never the attacker's.

What confirmations buy

A transaction in the mempool is unconfirmed. It has been seen by some nodes and may be included in a block, but nothing prevents a conflicting transaction from being mined instead. Once a transaction is in a block, reversing it requires a competing chain that overtakes the chain containing it. Each additional block on top raises the amount of work an attacker must match, and the probability of a successful reversal falls away quickly as the number of confirmations grows.

Nakamoto's analysis in section 11 of the whitepaper models this directly. If an attacker controls a fraction q of hash power and the honest network controls p, the probability that the attacker ever catches up from z blocks behind is (q/p)^z when p exceeds q. The paper's worked table shows the consequence: at q = 0.1, the probability of catching up from one block is about 20%, from three blocks about 1.3%, and from six blocks about 0.02%. At q = 0.3, six confirmations still leave a probability above 4%, and the paper solves for the confirmation counts that bring the probability below 0.1% — five blocks at q = 0.1, rising to 24 blocks at q = 0.3 and 89 at q = 0.4.

Those figures are a model, not a guarantee. They assume the attacker has a fixed share of hash power, that honest miners all build on the same chain, and that the attacker is willing to spend whatever it takes. They also assume the recipient waits for the stated number of blocks. The model is useful because it makes the trade-off explicit: more confirmations mean more certainty and a longer wait.

Zero-confirmation risk is a merchant decision

Nothing in the protocol requires a merchant to wait. A merchant may accept a payment the moment it sees an unconfirmed transaction, and many do for small amounts where the cost of a reversal is less than the cost of making customers wait. That is a commercial judgement about the value at risk, the identity of the customer, and the consequences of a reversal. It is not a protocol setting, and there is no confirmation count that is correct for every transaction.

The practical guidance that follows is that confirmation policy should scale with the amount at stake. A coffee purchase and a property settlement do not carry the same exposure, and treating them the same either imposes needless delay on the small payment or accepts needless risk on the large one. The confirmations and settlement page covers the settlement side of the same question, and the network partitions page describes what happens when two parts of the network briefly disagree about which chain is current.

Sources

Related reading