Race Attack

What Is a Race Attack?

A race attack is a specific type of double-spend attack targeting Bitcoin merchants who accept unconfirmed (zero-confirmation) transactions. The attacker creates two conflicting transactions that spend the same UTXO: one paying the merchant for goods or services, and a second sending the same funds back to a wallet the attacker controls. Both transactions are released into the network near-simultaneously, creating a propagation race across Bitcoin nodes.

The name refers to the network propagation race between the two conflicting transactions. Bitcoin nodes follow a "first-seen" rule by default: they accept the first version of a transaction spending a given input and reject subsequent conflicting ones. The attacker exploits the fact that different nodes may see different transactions first, depending on network topology and propagation timing.

Satoshi Nakamoto first discussed this scenario on BitcoinTalk in 2010, using the example of a "snack machine" that dispenses products instantly. The attack was later formalized by researchers Karame, Androulaki, and Capkun in their 2012 paper "Two Bitcoins at the Price of One," which demonstrated that race attacks succeed with high probability when merchants accept zero-conf payments.

How It Works

The race attack exploits the delay between when a transaction appears in the mempool and when it receives its first block confirmation. During this window, the transaction is merely a candidate for inclusion in a block, not a settled payment.

1. The attacker constructs two valid Bitcoin transactions that reference the same input(s). Transaction A pays the merchant the agreed amount. Transaction B sends the same funds to an address the attacker controls.
2. The attacker sends Transaction A directly to the merchant's node (or to nodes closely connected to the merchant) so the merchant sees it in their mempool.
3. Simultaneously, the attacker broadcasts Transaction B to the rest of the network, connecting to as many peers as possible to maximize its propagation speed.
4. The merchant sees Transaction A in their mempool, considers the payment received, and releases the goods or service.
5. If Transaction B reaches a miner first and is included in the next block, Transaction A is invalidated. The attacker keeps both the goods and the bitcoins.

Why Propagation Matters

The attack depends critically on the attacker's ability to control which transaction reaches which nodes first. As Satoshi noted: "If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes." The attacker can improve their odds by maintaining many outbound peer connections to deliver Transaction B broadly, while sending Transaction A only to the merchant's node or its immediate peers.

The success rate depends on several factors: the attacker's number of network connections relative to the merchant, whether the merchant accepts incoming peer connections (which allows the attacker to connect directly), the time gap between sending the two transactions, and overall network latency.

Transaction Construction

Both transactions must be valid, spending the same UTXO inputs. The attacker typically uses different output addresses but may also adjust the fee rate to influence which transaction miners prefer:

# Transaction A (sent to merchant's node)
Inputs:  txid:0 (attacker's UTXO, 0.05 BTC)
Outputs: merchant_address  0.045 BTC
         attacker_change    0.004 BTC
Fee:     0.001 BTC

# Transaction B (broadcast to wider network)
Inputs:  txid:0 (same UTXO, 0.05 BTC)
Outputs: attacker_address  0.049 BTC
Fee:     0.001 BTC

Why It Matters

The race attack highlights a fundamental trade-off in Bitcoin: speed versus security. On-chain Bitcoin transactions are not final until they receive at least one confirmation, which takes approximately 10 minutes on average. For merchants accepting Bitcoin at the point of sale, this delay creates a window of vulnerability.

This trade-off drove the development of Layer 2 solutions like the Lightning Network, which provides instant payment finality without relying on zero-conf base-layer transactions. Similarly, protocols like Spark enable instant Bitcoin transfers with cryptographic settlement guarantees, eliminating the race attack vector entirely.

The adoption of full replace-by-fee as the default policy in Bitcoin Core 28.0 (October 2024) further underscored that zero-conf on Bitcoin's base layer was never reliably secure. Under full-RBF, an attacker does not even need to race: they can send the payment to the merchant, wait for the goods, and then broadcast a higher-fee replacement transaction redirecting the funds.

Race Attack vs. Finney Attack

The race attack is often confused with the Finney attack, another zero-conf double-spend technique. The key difference is the attacker's requirements:

Both attacks target zero-conf transactions exclusively. A third variant, the Vector76 attack, combines elements of both to reverse a transaction with one confirmation, though this requires both mining capability and network-level manipulation.

Mitigations

Waiting for Confirmations

The most fundamental defense is requiring at least one block confirmation before releasing goods. One confirmation makes race attacks infeasible for non-mining attackers. For high-value transactions, the conventional standard is six confirmations (approximately one hour). The trade-off is that this delay is impractical for point-of-sale or instant-delivery scenarios.

Double-Spend Detection

Merchants can monitor the network for a brief listening period (5 to 10 seconds) after seeing a transaction, watching for any conflicting transaction spending the same inputs. Research by Podolanko et al. (2017) found that as few as three well-connected observer nodes can effectively detect double-spend attempts within seconds.

However, sophisticated attackers can delay broadcasting the conflicting transaction past the listening window, and the adoption of full-RBF makes this approach largely obsolete since any unconfirmed transaction can now be replaced with a higher-fee alternative at any time.

Lightning Network and Layer 2 Solutions

Lightning Network payments settle in milliseconds with cryptographic finality within the payment channel. There is no zero-conf risk: payments either succeed atomically or fail, with no window for double-spending. Lightning has become the primary solution for instant Bitcoin payments, effectively replacing the need for zero-conf base-layer transactions at the point of sale.

Similarly, protocols like Spark provide instant settlement through off-chain virtual UTXOs backed by cryptographic proofs, offering merchants instant finality without the race attack vulnerability inherent in base-layer zero-conf acceptance.

Full-RBF and Network Policy

Paradoxically, the adoption of full replace-by-fee as Bitcoin Core's default policy does not increase race attack risk so much as it formalizes the reality that zero-conf was never safe. Before full-RBF, merchants could reject RBF-signaled transactions as a heuristic, but this offered only weak protection since miners were always free to include whichever transaction they preferred. Full-RBF removes this ambiguity and pushes the ecosystem toward proper confirmation-based or Layer 2 payment acceptance.

Risks and Considerations

Merchant Vulnerability

Any merchant accepting zero-conf Bitcoin payments for instantly delivered goods is exposed to race attacks. This includes vending machines, digital content sellers, in-store purchases, and any scenario where the product or service is delivered before on-chain confirmation. The risk scales with the transaction value: small purchases may not justify the effort of mounting an attack, but high-value instant deliveries present a clear target.

Network Connectivity Asymmetry

Merchants who accept incoming peer connections are more vulnerable because attackers can connect directly to deliver the fraudulent transaction. Merchants with limited network connectivity or who rely on a single node without redundant network monitoring have a narrower view of the mempool, making double-spend detection harder.

Evolving Attack Surface

As Bitcoin's mempool policy evolves, the security assumptions around unconfirmed transactions continue to shift. The transition from opt-in RBF to full-RBF as the default demonstrates that protocol-level changes can alter the practical risk of race attacks. Merchants should treat any unconfirmed transaction as potentially reversible, regardless of current network policies, and use confirmation-based acceptance or Layer 2 payment rails for instant settlement.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.