Race Attack

Race attack is the simplest form of double-spend against a merchant who accepts zero-confirmation payments. The attacker creates two conflicting transactions spending the same coins: one paying the merchant and one paying an address the attacker controls. They send the merchant-facing transaction directly to the merchant while simultaneously broadcasting the self-paying transaction widely to the network, betting that miners will confirm the latter and orphan the former. If the merchant hands over goods the moment they "see" the payment, the attacker walks away with both the goods and the coins.

How the race works

The name comes from the literal race between the two transactions to propagate across the network and reach miners' mempools. Bitcoin nodes generally keep the first version of a transaction they see and reject conflicting ones, so which transaction "wins" depends on propagation — which nodes heard which version first, and crucially which version the miner who finds the next block had. An attacker improves their odds with positioning: connecting directly to the merchant's node so the merchant sees the payment immediately while the conflicting spend races ahead everywhere else, or timing the broadcasts so the self-payment gets a head start on the wider network. Replace-by-fee (RBF) adds another lever — signaling replaceability and then outbidding the merchant-facing transaction with a higher-fee conflict — and modern relay policies that allow fee-based replacement make "first seen" an even weaker guarantee than it used to be.

Defenses

The race attack only works against parties that accept payments instantly on sight. The definitive defense is to wait for at least one block confirmation, which makes both the race and the related Finney attack ineffective — once a transaction is buried in a valid block, the conflicting version is dead unless the chain itself reorganizes. Merchants who cannot wait sometimes run well-connected listening nodes that watch for conflicting transactions during the vulnerable window, treat RBF-signaled payments as unconfirmed cash, or restrict zero-confirmation acceptance to low-value or repeat-customer transactions where the fraud incentive is small. Lightning Network payments sidestep the problem entirely: settlement is instant and final within the channel, with no confirmation race to exploit.

Why this matters to node runners

The race attack is a good first lesson in what Bitcoin's security model actually promises. An unconfirmed transaction is a broadcast intention, not money received; only proof-of-work burial makes it settlement. Running your own node does not let you skip confirmations, but it does let you see the mempool with your own eyes — including conflicting spends — rather than trusting someone else's view of what has been paid.

A lesson from Bitcoin's early years

Zero-confirmation acceptance was widespread in Bitcoin's first years, when blocks were uncongested, fees were negligible, and the informal "first-seen" relay convention made a race genuinely hard to win against a well-connected merchant node. Satoshi himself discussed the attack in early forum posts, arguing that for small retail amounts the race was difficult to execute reliably. What changed is policy and congestion: fee markets made replacement economically rational, replace-by-fee formalized it, and the guarantee zero-conf merchants leaned on — that the first-broadcast transaction wins — was never a consensus rule at all, only a relay custom that individual nodes and miners were always free to ignore. The modern posture follows from that history: unconfirmed means unconfirmed, and any system that needs instant finality should settle on Lightning rather than hope about mempool behavior.

The race attack is the entry point of the zero-confirmation double-spend family that also includes the Vector76 attack; all are species of double-spend, the problem proof-of-work mining exists to solve.