Two bitcoins for the price of one – Analysis of the paper by Karame, Androulaki and Srdjan

Executive summary

This paper examines a narrow but important question:

Can a merchant safely accept a Bitcoin payment immediately—before it receives a blockchain confirmation?

The authors’ answer is essentially no.

They demonstrate that an attacker can create two conflicting transactions spending the same bitcoins:

• One transaction pays the merchant.
• The other returns the bitcoins to the attacker—or pays another party.

By carefully controlling how the two transactions propagate through Bitcoin’s peer-to-peer network, the attacker can make the merchant see the merchant-paying transaction first while causing much of the wider network—and ultimately a miner—to accept the conflicting transaction first.

The merchant hands over the product after seeing an apparently valid payment. Later, the conflicting transaction is mined, making the merchant’s payment invalid.

The attack does not require majority hash power, mining capability, or control of the merchant’s computer. It primarily exploits the insecurity of zero-confirmation payments and the way conflicting transactions propagate.

Source: Two Bitcoins at the Price of One?

---

1. What problem does the paper address?

Bitcoin prevents double-spending through blockchain confirmation. Once a transaction has been included in a block—and especially after additional blocks are built on top of it—reversing it becomes increasingly difficult.

But a normal block takes approximately ten minutes on average. That is too slow for situations such as:

• Fast-food purchases
• Vending machines
• In-person retail
• ATM withdrawals
• Immediate online access
• Other transactions in which goods are released within seconds

A merchant therefore faces a choice:

1. Wait for confirmation and make the customer wait.
2. Accept an unconfirmed transaction and assume it will eventually be mined.

The second option is called a zero-confirmation, or 0-conf, payment. The paper shows that merely receiving a valid-looking transaction is not proof that the merchant will ultimately receive the money.

---

2. How the attack works

The attacker creates two transactions using the same Bitcoin inputs.

Transaction	Recipient	Purpose
TRV	Vendor	Convince the vendor that payment was made
TRA	Attacker-controlled address	Preserve or recover the attacker’s bitcoins

Because they spend the same inputs, both transactions cannot become valid blockchain transactions. At most one can ultimately be confirmed.

The attack proceeds as follows:

1. The attacker establishes a direct Bitcoin-network connection to the merchant.
2. The attacker sends TRV directly to the merchant.
3. The merchant sees a properly signed transaction paying the correct amount.
4. At nearly the same time, the attacker sends TRA to one or more helper nodes.
5. Those helpers rapidly broadcast TRA throughout the wider Bitcoin network.
6. The merchant releases the product based on the unconfirmed TRV.
7. If a miner includes TRA in a block first, the merchant’s TRV becomes an invalid conflicting transaction.
8. The attacker keeps the goods while retaining control of the bitcoins through TRA.

The attack succeeds when two conditions are met:

• The merchant receives TRV before receiving or learning about TRA.
• The competing transaction TRA is confirmed before TRV.

The key insight is that these conditions can coexist. The transaction a merchant sees first does not have to be the transaction most miners see first.

---

3. Why direct connectivity matters

The attacker wants to create two different network views.

flowchart TD
    A["Attacker"] -->|"TRV: Pay merchant"| V["Merchant"]
    A -->|"TRA: Conflicting spend"| H["Helper nodes"]
    V -->|"Release goods immediately"| G["Product or service"]
    H -->|"Broadcast widely"| N["Bitcoin network and miners"]
    N -->|"Confirm TRA first"| F["Merchant payment becomes invalid"]

A direct connection gives the attacker a fast path to the merchant. Helper nodes give the conflicting transaction broader and potentially faster access to the rest of the network.

The attacker does not necessarily need many helpers. In the authors’ experiments, one or two well-connected helper nodes could substantially improve the attack’s probability.

---

4. What the researchers measured

Block confirmation time

Using Bitcoin blocks through November 2011, the authors found:

• Average block-generation time: approximately 9 minutes 54 seconds
• Standard deviation: approximately 14 minutes 41 seconds
• Only about 64% of blocks arrived within ten minutes
• About 36% took between ten and forty minutes

Their practical point is more important than the exact statistical model: “ten minutes” is an average, not a deadline. A merchant waiting for one confirmation may sometimes wait much longer.

The authors model block-generation time as a shifted geometric distribution. In continuous time, Bitcoin mining is more commonly understood through a Poisson process with exponentially distributed waiting times; the paper’s shifted geometric model is essentially a discretized approximation.

Double-spending experiments

The researchers used modified Bitcoin 0.5.2 clients distributed across:

• Europe
• North America
• Asia-Pacific
• South America

They performed hundreds of controlled double-spending attempts involving wallets they owned, so unrelated users were not supposed to lose funds.

They varied:

• The delay between sending the two transactions
• The number of attacker-controlled helper nodes
• The merchant’s number of network connections
• The geographical location of the nodes

They reported scenarios where the attack succeeded in 90–100% of the small experimental samples. The attack generally became more successful when:

• The conflicting transaction was sent early.
• The attacker used more helper nodes.
• The helpers were well connected.
• The merchant had relatively few peer connections.

However, a reported 100% means success in that limited sample—often ten trials—not a mathematically guaranteed success rate.

---

5. Why “listen for a few seconds” is insufficient

One proposed defense was for the merchant to wait briefly—perhaps 10–15 seconds—and monitor the network for a conflicting transaction.

This helps, but the authors show that it is not fully reliable.

The attacker can delay broadcasting TRA just enough that:

• The merchant does not see the conflict during the listening window.
• The conflicting transaction still reaches enough miners to have a meaningful chance of being confirmed first.

There is another subtle propagation issue. Bitcoin nodes in the tested implementation generally retained the first version of a conflicting transaction they received and ignored the later version. If the merchant’s immediate neighbors received TRV first, they might not forward TRA back toward the merchant.

Consequently, the wider network could know about the double-spend while the merchant remained unaware of it.

---

6. What about observer nodes?

The authors consider having the merchant operate multiple observer nodes in different network locations.

These observers report transactions back to the merchant. Even if the merchant’s main node does not see the conflicting transaction, one of the observers may see it.

Their experiments suggest that observers improve detection, but they have limitations:

• The merchant must operate and maintain several nodes.
• The observers must be well connected.
• Some observers may still fail to receive the conflicting transaction.
• The method introduces infrastructure and operating costs.
• There is no absolute guarantee that every conflicting transaction will reach an observer in time.

The authors estimate that approximately three suitably connected observers could provide useful protection in their experimental environment.

---

7. The authors’ proposed defense

Their preferred defense is a network-wide double-spending alert mechanism.

When a Bitcoin node sees two valid transactions that:

• Spend the same inputs, but
• Send those inputs to different outputs,

the node would broadcast both transactions as proof of the conflict.

The merchant could then reject the payment before releasing the product.

This is stronger than relying only on the merchant’s local view because any honest node that sees both transactions can warn the rest of the network.

The alert itself is independently verifiable. Other nodes can check that:

• Both transactions are properly signed.
• They spend the same inputs.
• Their outputs conflict.

Therefore, an attacker cannot create a convincing false alert without actually producing conflicting signed transactions.

Still, the proposal is not fully engineered in the paper. It does not deeply evaluate:

• Alert flooding or denial-of-service risks
• Bandwidth and storage overhead
• Node incentives to relay alerts
• Privacy implications
• Merchant response policies
• How long the merchant must wait for an alert
• Whether an attacker can manipulate alert propagation

It is a promising detection concept, not a complete payment-security protocol.

---

8. What the paper proves—and what it does not

It convincingly demonstrates

• Receiving a transaction is different from receiving final payment.
• Zero-confirmation acceptance relies heavily on network propagation behavior.
• An attacker does not need majority mining power to attack an unconfirmed payment.
• A merchant’s local mempool view may differ from the broader network’s view.
• A short waiting period reduces risk but does not eliminate it.
• Network connectivity is itself a security variable.
• Low-value payments are not automatically safe merely because attacking them seems uneconomical.

It does not demonstrate

• That confirmed Bitcoin transactions are generally insecure.
• That an attacker can easily reverse deeply confirmed transactions.
• That the same success rates apply to every merchant or network topology.
• That its 2012 client-specific results apply unchanged to modern Bitcoin software.
• That double-spending alerts guarantee irrevocable settlement.
• That merchants cannot manage 0-conf risk through economic limits, identity, deposits, fraud scoring, or other operational controls.

The paper is specifically about fast, unconfirmed payments, not a general break of Bitcoin’s consensus mechanism.

---

9. Important limitations

Historical implementation

The experiments used Bitcoin client version 0.5.2 and network conditions from 2011–2012. The results should therefore be treated as a historical security analysis, not a measurement of current Bitcoin behavior.

Small experimental samples

Some plotted probabilities are based on approximately ten or twenty observations per configuration. Results such as 90% or 100% are informative but have wide statistical uncertainty.

Controlled node population

The authors used ten geographically distributed nodes, but that cannot reproduce every possible topology, miner connection, relay policy, or real merchant deployment.

Simplified miner behavior

The mathematical model largely treats propagation reach as a proxy for the likelihood of confirmation. In reality, miners and mining pools may differ in:

• Peer connectivity
• Hash-rate share
• Transaction-selection rules
• Conflict policies
• Fees and prioritization
• Direct transaction submission

Reaching many ordinary nodes is not necessarily equivalent to reaching a proportionate amount of mining power.

Ambiguities and editorial issues

The experimental description contains at least one apparent notation error: it says the vendor accepts payment if it receives TRA, although the paper’s definitions imply it should be TRV.

The conclusion also refers to “thousands” of attempts, whereas one earlier experimental section describes approximately 500 attempts. This may include later experiments, but the accounting is not fully explained.

---

10. The paper’s deeper lesson

The most enduring insight is about the distinction between three events:

1. Transaction validity: The transaction has valid signatures and correctly references spendable outputs.
2. Transaction visibility: The merchant has received the transaction.
3. Transaction settlement: The network has selected that transaction over any conflicting alternatives.

A zero-confirmation payment establishes only the first two. It does not establish the third.

That distinction can be expressed simply:

Valid transaction≠Final payment\text{Valid transaction} \neq \text{Final payment}

The merchant is making a risk decision during the interval between seeing the transaction and obtaining blockchain confirmation.

---

Bottom line

The paper does not break Bitcoin. It shows that Bitcoin’s blockchain-based double-spending protection does not yet apply when a merchant accepts payment before confirmation.

Its central conclusion remains conceptually sound:

A zero-confirmation Bitcoin payment is a promise visible on the network, not irreversible settlement.

For inexpensive purchases, a merchant may knowingly accept that risk. For cash-like goods, irreversible digital delivery, ATM withdrawals, gift cards, or anything easily resold, the paper suggests that relying solely on transaction reception is unsafe.