TECHNICAL_DOC // BLOCKCHAIN / DOUBLE-SPEND
DOUBLE
SPEND
SPEND
A double spend is an attempt to spend the same UTXO twice — broadcasting two
conflicting transactions that each reference the same input. Bitcoin's consensus mechanism
prevents confirmed double spends by ensuring only one transaction can be included in any
valid chain. The risk exists only before confirmation.
HOW_BITCOIN_PREVENTS_DOUBLE_SPENDS
MEMPOOL LAYER — FIRST-SEEN RULE
Alice signs TX1: UTXO-A → Bob (1 BTC)
Alice signs TX2: UTXO-A → Carol (1 BTC) ← conflicting
Node receives TX1 first:
→ marks UTXO-A as "spent pending" in mempool
→ TX2 arrives: UTXO-A already pending → REJECT TX2
Note: first-seen rule is not consensus — different nodes may
see transactions in different orders. Only block inclusion finalizes.
FINAL RESOLUTION
BLOCK LAYER — CONSENSUS FINALIZES
Miner includes TX1 in Block N → TX1 confirmed
UTXO-A removed from UTXO set → permanently spent
All nodes processing Block N:
→ validate TX1 (UTXO-A exists, signatures valid) ✓
→ any subsequent TX2 referencing UTXO-A → INVALID (UTXO gone)
→ TX2 removed from all mempools globally
Double spend attempt FAILED. UTXO-A cannot be spent again.
DOUBLE_SPEND_ATTACK_VECTORS
Race Attack (0-Confirmation)
UNCONFIRMED RISK
Attacker broadcasts two conflicting transactions simultaneously to different parts of the network — one to the merchant, one to themselves. The merchant accepts without waiting for confirmation.
1. Attacker sends TX1 (to merchant) and TX2 (to self) simultaneously
2. Merchant sees TX1, ships goods (accepting 0-conf)
3. Miner includes TX2 in a block
4. TX1 invalid → merchant paid for nothing
Prevention:
→ Never accept 0-confirmation for high-value irreversible goods
→ Monitor mempool for conflicting transactions (replace-by-fee)
→ Use Lightning for instant, truly final small payments
51% Attack (Confirmed Double Spend)
MAJORITY HASHRATE
An attacker controlling >50% of hashrate can mine a secret chain, confirm a payment, receive goods, then release the longer secret chain to revert the confirmed transaction.
1. Attacker pays merchant TX1 → confirmed in block N (public chain)
2. Simultaneously: attacker mines secret chain from block N-1
3. Merchant ships goods after 6 confirmations
4. Attacker's secret chain reaches length N+7 (exceeds public)
5. Attacker broadcasts secret chain → REORG
6. Public chain reorganized → TX1 never happened
7. Merchant has goods. Attacker's coins returned.
Cost for Bitcoin (2024): ~$1M+ per hour of 51% hashrate rental
Economically rational threshold: attack cost < goods stolen
This attack is theoretically possible but extremely costly on Bitcoin due to its massive hashrate. It is a real concern on smaller proof-of-work chains.
MINER SPECIFIC
A variant where a miner pre-mines a block containing TX2 (to themselves) before paying a merchant with TX1. Once the merchant ships, the pre-mined block is broadcast.
Requires: Attacker is a miner AND merchant accepts 0-conf
1. Miner mines (but withholds) a block with TX2 (self-payment)
2. Miner sends TX1 to merchant address
3. Merchant ships (accepts 0-conf)
4. Miner releases pre-mined block → TX1 replaced by TX2
Impractical at scale: miner sacrifices block reward timing.
Rarely observed in practice.
TERMINOLOGY_INDEX
Double Spend
An attempt to spend the same UTXO in two different transactions. Bitcoin's consensus prevents confirmed double spends.
Race Attack
Broadcasting two conflicting txs simultaneously, hoping one reaches the merchant and the other gets mined.
0-Conf
Zero confirmations. An unconfirmed transaction in the mempool. Not final — can be replaced or double-spent.
RBF
Replace-By-Fee. Allows a sender to replace an unconfirmed transaction with a higher-fee version, which can facilitate double spends.
Finality
The point at which a transaction is considered irreversible. In Bitcoin: probabilistic, stronger with each confirmation.
INTERACTIVE — TRY IT YOURSELF
CONSENSUS / SECURITY
Double Spend
A double spend attempts to use the same bitcoin in two conflicting transactions. The Bitcoin protocol prevents this through proof-of-work: reversing a confirmed transaction requires out-mining the honest network from that block forward. The attack cost grows exponentially with confirmations — which is why high-value transfers wait for 6 confirmations.
RACE ATTACK SIMULATOR
A race attack targets merchants who accept 0-confirmation transactions. The attacker simultaneously broadcasts two conflicting transactions — one to the merchant, one to the network. Whichever confirms first wins. This is prevented by waiting for at least 1 confirmation.
0-CONF RACE ATTACK SIMULATIONwatch mempool conflict resolution
51% ATTACK — CHAIN REORG DEMO
A Finney attack or 51% attack works by the attacker mining a secret chain in parallel, then broadcasting it after receiving goods. If the secret chain is longer than the public chain, honest nodes switch to it (longest chain rule), erasing the payment. Cost of attack grows with confirmations required.
CONFIRMATION SECURITY TABLE
ATTACK SUCCESS PROBABILITY vs CONFIRMATIONS
| CONFIRMATIONS | ATTACK SUCCESS % | RECOMMENDED FOR |
|---|
0-confirmation transactions are not safe for high-value goods. For physical goods handed over immediately (pizza, coffee), the economic incentive to double-spend is often too low. For digital goods or high-value items, always wait for confirmations proportional to the value.