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?

2 Answers 2


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.

  • 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. Commented Nov 3, 2011 at 14:41
  • Well, I guess one could basically set everything up on Amazon EC2 with minimal effort. Costly, but quick to set up.
    – ThePiachu
    Commented Nov 3, 2011 at 16:24

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.

  • 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.
    Commented Nov 26, 2013 at 22:13
  • 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. Commented Nov 26, 2013 at 22:33
  • 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.
    Commented Nov 27, 2013 at 16:06
  • @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.) Commented Nov 27, 2013 at 16:59
  • 1
    @AntonAnsgar Punch "Finney attack" into your favorite search engine. Commented Nov 27, 2013 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.