← all simulations
slide 3 · consensus
Double spending
honest
#1
#2
#3
#4
#5
✓attacker
#1
#2
orphaned ✕Attack the chain with a conflicting spend and see defeat it.
- 1Pay the merchant
- 2Launch the conflicting spend
- 3Add confirmations until the attack dies
live · 0 players in this room
send coins to another player
10.0000 BTC10.0000 ETH
recipient
waiting for another player to join this room… open this page in a second tab or share the link with the class.
fee 0.0005 · total 0.5005 BTC
live transfers in this room
room ledger · tap a row to replay its steps
- no transfers yet — be the first to pay a classmate.
Attacker hash power
30%
Merchant waits for
1 confirmation
Success probability
43%
Attack parameters
Accepting a payment at 0 is the real vulnerability — the transaction is only a promise sitting in the . Each confirmation multiplies the work an attacker must redo, which is why the success probability falls off a cliff.
Run the attack
honest chain
99
contains tx A
attacker fork
contains tx B
waiting…
Why double spending is hard
- 1. Every node checks the UTXO set: the second spend of the same output is simply rejected and never relayed.
- 2. To get both accepted, the attacker must build a longer chain in private — that means out-mining everyone else.
- 3. Longest-chain (most-work) rule makes the honest majority's chain canonical the moment it is longer.
- 4. Proof of Stake replaces this with slashing: an attacker signing two conflicting chains loses their stake.
Practical defences: wait for proportional to value, never accept 0-conf for expensive goods, watch for RBF (replace-by-fee) flags, and use payment channels or for instant retail payments.