<p>If you are attempting a 0-confirm double spend then which transactions (if any) are included in the next block is irrelevant.  Your goal is to simply complete both transaction prior to either merchant getting notification of the other one.  </p>

<p>The "problem" is that the network is fairly quick at passing transactions from one node to the next.  Unless you have located an inefficiency in the network, a bottleneck, or actively degrading network performnce is unlikely you will complete both transactions before the merchant sees both halves of the double spend.  </p>

<p>An effective countermeasure would be for the merchant to introduce a short delay between the time they detect your 0-confirm transaction and when they give you access to the purchased item or service.   Say you execute a perfectly timed double spend.  The merchant sees their transaction and waits 60 seconds.  60 seconds is a long time for transactions to not propagate the network.  If at any point in that 60 seconds the merchant sees the "other" transaction you have failed.   Unlike other forms of fraud you will lose the funds as your double spend is irrevocable.  It will just be luck on which merchant gets paid.</p>

<p>Also many transactions are not irreversible.  Software which has a license key can have the license key revoked.  Many giftcards can be reported as stolen to freeze the funds.  Any subscription based site would grant you at most a few seconds of service before cutting you off.  Product which require physical deliver are never going to be shipped fast enough to execute a double spend.</p>

<p>The risk of a 0-confirm double sped is low but security can be improved by designing ultra fast low latency "super nodes".  A service provider could setup a network of Bitcoin nodes around the world with low latency links between them.  Each of these nodes would be running modified version of bitcoind to maximize the number of connections, establishing thousands or even tens of thousands of connections to peers.  No matter where the two halves of the double spend originate it would be only a few hops to a super node.  </p>

<p>If a merchant only accepts transactions from the super node network then you would be unable to complete the double spend.  Either the network has seen both transactions and the double spend is detected or they haven't in which case one of the merchants won't give access to the item purchased.</p>

CC BY-SA 3.0
2011-11-03T14:41:44.590Z
It wouldn't really take much work just demand.  Map out the existing Bitcoin network and find locations for servers in diverse parts of the net (say server in Hong Kong, UK, US East Coast, US West Coast, Germany, Brazil).  Setup those nodes to create a huge number of connections to peers in the network and then relay those transaction to each other quickly.  There isn't sufficient demand today to warrant the cost but someday these nodes could be the equivelent of internet backbone for the Bitcon network.
DeathAndTaxes
CC BY-SA 3.0
2011-11-03T16:24:37.850Z
Well, I guess one could basically set everything up on Amazon EC2 with minimal effort. Costly, but quick to set up.
ThePiachu
CC BY-SA 3.0
2011-11-03T13:53:26.583Z
2011-11-03T22:29:59.613Z
2011-11-03T22:29:59.613Z
DeathAndTaxes
<p>What you're forgetting is that merchants who accept transactions with zero confirmations would already defend against this attack using well-known methods. The primary defense is monitoring the Bitcoin network at multiple points, as close to the largest mining pools as possible. The merchant only considers a transaction valid if they see it at the vast majority of their probe points. And, of course, if they see a conflicting transaction at <em>any</em> probe point, they reject the transaction (until/unless it gets confirmations).</p>

<p>This is why the Finney attack was such a shock. It was generally believed that this was sufficient defense. In my opinion, it is still sufficient for low-value transactions, say less than $250 or equivalent. At least, that's my opinion until we actually see a successful double-spend attack against a merchant using reasonable defenses.</p>

CC BY-SA 3.0
2013-11-26T22:13:56.007Z
How do you get to the $250 number? I was going to post a question about how to calculate this and found your answer.
Emre K.
CC BY-SA 3.0
2013-11-26T22:33:31.280Z
It can be higher now. The number is based on the risk an attacker takes -- the risk of losing the mined block. Just be warned, the primary defense is not sufficient, you need others as well. For example, the transaction fee must be adequate.
David Schwartz
CC BY-SA 3.0
2013-11-27T16:06:22.003Z
Bear with me. How does a double spend attacker, not a 51% attacker, risk losing a block? He's not necessarily a miner. I can send the same coins to 10 addresses and I own 9 of them, only 1 is a merchant I'm trying to fraud. Isn't there 90% chance I will end up still owning the coins? If the merchant sells an irreversible good with 0 confirmations, he's in trouble. Or is he? Enlighten me :)
Emre K.
CC BY-SA 3.0
2013-11-27T16:59:14.870Z
@AntonAnsgar That won't work because as soon as the merchant sees a conflicting transaction, he won't issue the goods. You can't get 90% of the miners to see the transaction and still hide it from the merchant. So the attacker will have to mine his own block with the conflicting transaction, hold it until the merchant releases the goods, and then release the block with the conflicting transaction. (We're assuming the merchant uses all reasonable defenses against double spends *except* waiting for a confirmation.)
David Schwartz
CC BY-SA 3.0
2013-11-27T18:07:17.580Z
All reasonable defenses include connecting to enough nodes and having enough delay before accepting the payment that the probability of not seeing the conflicting transfers become negligible. As suggested in the first answer. I need to learn more about how to hold a mined block to understand the block mining part of your answer but I think I get the 0 confirmation double spend part. Thank you very much.
Emre K.
CC BY-SA 3.0
2013-11-27T18:48:35.190Z
@AntonAnsgar Punch "[Finney attack](http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack)" into your favorite search engine.
David Schwartz
CC BY-SA 3.0
2011-11-03T22:13:17.840Z
2011-11-03T22:13:17.840Z
David Schwartz
<p>To perform a Finney attack or a 51% attack I need to have lots of computational power, but in this case (a website that accepts transactions with 0 confirmations) it seems to me that I only need to issue two transactions almost simultaneously. Depending on what the miner chooses to include in the next block, I might get lucky.   </p>

<p>Is it that easy or am I forgetting something?</p>

<security><attack><confirmations><doublespend><fraud>
How to perform a double spend attack in websites that accept transactions with 0 confirmations?
nmat
# How to perform a double spend attack in websites that accept transactions with 0 confirmations?

(Asked by: username_0 on 2011-11-03)

To perform a Finney attack or a 51% attack I need to have lots of computational power, but in this case (a website that accepts transactions with 0 confirmations) it seems to me that I only need to issue two transactions almost simultaneously. Depending on what the miner chooses to include in the next block, I might get lucky.

Is it that easy or am I forgetting something?

**Tags:** security, attack, confirmations, doublespend, fraud


---

## 2 answers

### Answer by username_1 on 2011-11-03. Score: 7

If you are attempting a 0-confirm double spend then which transactions (if any) are included in the next block is irrelevant. Your goal is to simply complete both transaction prior to either merchant getting notification of the other one.

The "problem" is that the network is fairly quick at passing transactions from one node to the next. Unless you have located an inefficiency in the network, a bottleneck, or actively degrading network performnce is unlikely you will complete both transactions before the merchant sees both halves of the double spend.

An effective countermeasure would be for the merchant to introduce a short delay between the time they detect your 0-confirm transaction and when they give you access to the purchased item or service. Say you execute a perfectly timed double spend. The merchant sees their transaction and waits 60 seconds. 60 seconds is a long time for transactions to not propagate the network. If at any point in that 60 seconds the merchant sees the "other" transaction you have failed. Unlike other forms of fraud you will lose the funds as your double spend is irrevocable. It will just be luck on which merchant gets paid.

Also many transactions are not irreversible. Software which has a license key can have the license key revoked. Many giftcards can be reported as stolen to freeze the funds. Any subscription based site would grant you at most a few seconds of service before cutting you off. Product which require physical deliver are never going to be shipped fast enough to execute a double spend.

The risk of a 0-confirm double sped is low but security can be improved by designing ultra fast low latency "super nodes". A service provider could setup a network of Bitcoin nodes around the world with low latency links between them. Each of these nodes would be running modified version of bitcoind to maximize the number of connections, establishing thousands or even tens of thousands of connections to peers. No matter where the two halves of the double spend originate it would be only a few hops to a super node.

If a merchant only accepts transactions from the super node network then you would be unable to complete the double spend. Either the network has seen both transactions and the double spend is detected or they haven't in which case one of the merchants won't give access to the item purchased.

> **Comments:**
> **username_1**: It wouldn't really take much work just demand.  Map out the existing Bitcoin network and find locations for servers in diverse parts of the net (say server in Hong Kong, UK, US East Coast, US West Coast, Germany, Brazil).  Setup those nodes to create a huge number of connections to peers in the network and then relay those transaction to each other quickly.  There isn't sufficient demand today to warrant the cost but someday these nodes could be the equivelent of internet backbone for the Bitcon network.  
> **username_2**: Well, I guess one could basically set everything up on Amazon EC2 with minimal effort. Costly, but quick to set up.  

---

### Answer by username_3 on 2011-11-03. Score: 1

What you're forgetting is that merchants who accept transactions with zero confirmations would already defend against this attack using well-known methods. The primary defense is monitoring the Bitcoin network at multiple points, as close to the largest mining pools as possible. The merchant only considers a transaction valid if they see it at the vast majority of their probe points. And, of course, if they see a conflicting transaction at *any* probe point, they reject the transaction (until/unless it gets confirmations).

This is why the Finney attack was such a shock. It was generally believed that this was sufficient defense. In my opinion, it is still sufficient for low-value transactions, say less than $250 or equivalent. At least, that's my opinion until we actually see a successful double-spend attack against a merchant using reasonable defenses.

> **Comments:**
> **username_4**: How do you get to the $250 number? I was going to post a question about how to calculate this and found your answer.  
> **username_3**: It can be higher now. The number is based on the risk an attacker takes -- the risk of losing the mined block. Just be warned, the primary defense is not sufficient, you need others as well. For example, the transaction fee must be adequate.  
> **username_4**: Bear with me. How does a double spend attacker, not a 51% attacker, risk losing a block? He's not necessarily a miner. I can send the same coins to 10 addresses and I own 9 of them, only 1 is a merchant I'm trying to fraud. Isn't there 90% chance I will end up still owning the coins? If the merchant sells an irreversible good with 0 confirmations, he's in trouble. Or is he? Enlighten me :)  
> **username_3**: @AntonAnsgar That won't work because as soon as the merchant sees a conflicting transaction, he won't issue the goods. You can't get 90% of the miners to see the transaction and still hide it from the merchant. So the attacker will have to mine his own block with the conflicting transaction, hold it until the merchant releases the goods, and then release the block with the conflicting transaction. (We're assuming the merchant uses all reasonable defenses against double spends *except* waiting for a confirmation.)  
> **username_4**: All reasonable defenses include connecting to enough nodes and having enough delay before accepting the payment that the probability of not seeing the conflicting transfers become negligible. As suggested in the first answer. I need to learn more about how to hold a mined block to understand the block mining part of your answer but I think I get the 0 confirmation double spend part. Thank you very much.  
> **username_3**: @AntonAnsgar Punch "[Finney attack](http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack)" into your favorite search engine.  

---

