<p>In the best-case scenario, the merchant would be listening to nodes all over the network for any conflicting transactions.  If no conflicting transactions are broadcast before the legitimate transaction fully propagates, then the merchant can be sure that legitimate miners won't put a conflicting transaction into their blocks.</p>

<p>If the customer is mining, however, they can attempt to find a block and include a conflicting transaction before the rest of the network manages to find a block and include the legitimate transaction.  In this case, the chance of the attacker succeeding is equal to the percentage of the network's total hashing power that they control (eg, an attacker mining at 100 GH/s would have a 1% chance of pulling this off if the network's total hashrate was 10 TH/s).</p>

<p>The attacker could wait until they find a block and include a transaction to send their coins to themself.  Once they find the block, they withhold it from the network and attempt to make a purchase from the merchant.  If they manage to complete the purchase and acquire the desired goods before the rest of the network finds a block, they release their pre-mined block and invalidate the legitimate transaction.</p>

<p>The latter version would probably be impractical to pull off on a brick-and-mortar merchant, simply due to the time required to get to the store, make the purchase, and leave after finding a block.  An online merchant could accept the transaction immediately, but wait for at least one confirmation before shipping in order to prevent the attack.</p>

CC BY-SA 3.0
2011-09-21T20:52:52.943Z
Thank you for the explanation - so there's not really anything that can be done for an online merchant or vending machine (where the time of purchase can exactly and arbitrarily be determined by the customer) to reduce the risk of routinely accepting zero confirmation transactions?
Noah
CC BY-SA 3.0
2011-09-21T22:12:37.237Z
More of an explanation of what a Finney attack is than how to mitigate it. Of course you're welcome to start your own "What is a Finney attack" question and post your own answer. Just make sure you give others a chance to post possibly better answers before accepting your own ;)
David Perry
CC BY-SA 3.0
2011-09-21T22:29:36.667Z
@Noah: Yeah, vending machines are probably at the highest risk and can't do anything further to mitigate it without involving a third party (green address, insurance, etc).  Of course, the attacker is still in a situation where they have to wait by the vending machine for hours/days/weeks in order to steal a candy bar.
xyz
CC BY-SA 3.0
2011-09-21T20:33:34.927Z
2011-09-21T20:33:34.927Z
xyz
<p><em>What can a merchant do to mitigate the risk this specific kind of attack?</em></p>

<p>Wait for a few confirmations.</p>

CC BY-SA 3.0
2011-09-21T19:41:41.227Z
Sorry, I thought it was obvious that I am looking for some technique to reduce the risk of accepting unconfirmed transactions (apart from the "listening period" to rule out simultaneously broadcast conflicting transactions) - anyway, I made it explicit now.
Noah
CC BY-SA 3.0
2011-09-22T05:26:15.043Z
That's kind of like if the question was "what can you do to reduce your chance of getting injured in an airplane accident" and instead of giving answers about where to sit, what to wear, or what airlines to use, saying "drive instead".
David Schwartz
CC BY-SA 3.0
2011-09-22T14:09:15.540Z
I think you should delete your answer and make it a comment below the question. Both funny & informative to anyone who missed the obvious.
Stéphane Gimenez
CC BY-SA 3.0
2011-09-21T18:53:25.923Z
2011-09-21T18:53:25.923Z
eldentyrell
<p>The key to understanding why the Finney attack isn't really that big of a deal is understanding the business case for accepting 0/unconfirmed transactions. An online merchant doesn't usually have to accept such transactions since they probably do batch-shipping anyway. It's not required from an integration standpoint since the API includes many options to simply not return transactions without confirmations. The only business case that requires the acceptance of 0/unconfirmed transactions is when your customer is standing directly in front of you and won't be around for 10+ minutes. In such cases, a Finney attack isn't feasible and here's why:</p>

<p>Imagine I'm a scammer wanting to use the Finney attack against you, the honest merchant. I've spent a few grand and bought myself 3 GH/s worth of Radeon 5830 rigs. This number isn't arbitrarily chosen, I specifically picked it to make for easy math - 3 GH/s will net you about 1 block per month at current difficulties. Given that actual brick-and-mortar stores are closed for about 8 hours per night on average, this means that 1/3 of my found blocks will occur outside of business hours so on average I get a chance to double-spend with a Finney attack every 45 days.</p>

<p>Now as with all mining, there's no telling when you'll hit that lucky block so if I'm dead set on executing this attack I have to stay hypervigilant because once every 45 days I'll get an alarm of some sort telling me to go spend money at my target's store. I have to get there quickly because if I don't make my purchase and remotely trigger the release of the block fast enough, that block will get solved by some other miner and I'll lose my chance. So let's say on average it takes me 5 minutes to get somewhere, pick something and make a big purchase - I've got a 50% chance of failure, so now I'm able to execute my attack about once every 90 days.</p>

<p>Mining isn't cheap - my 3 GH/s setup draws something like 2 kilowatts, add in another 800 watts or so for cooling and at my local electricity costs it runs me about $8 a day to try for this attack. Multiply this by the 90 days it takes on average for me to be successful and I have to be successful to the tune of $710 just to break even. I'd make better money mining! Keep in mind that I've spent 16 hours a day every day for three months waiting for that alarm to go off too, so even if I double-spend $1420 (double my costs) I still only make $236.67 per month for my trouble - 49.3 cents per hour.</p>

<p>Oh and once you've made the purchase there's still the gap between then and releasing the block. If a block is found during that window, you've <em>actually</em> spent that money now. This particular attack is not without risk.</p>

<p>So there's something of an answer - not how to mitigate the attack but why the attack doesn't really matter. Online merchants don't <em>need</em> to accept 0 confirmation transactions since your stuff probably won't ship within 10 minutes anyway and brick-and-mortar merchants add a delay to the transaction process that makes the attack unfeasible. Even without the delay, the transaction would have to be positively huge to make any sort of profit and the attacker <em>still</em> stands a large risk of <em>actually</em> spending the money anyway. I don't really see this taking off.</p>

CC BY-SA 3.0
2011-09-21T23:03:30.917Z
Come to think of it, this is one attack that reducing the blocktime actually *would* have an impact on. I suppose I owe a few folks on the forums an apology for all the times I've said the opposite. It still doesn't mitigate a 51% attack though, and I've never heard someone specifically cite a Finney attack as a reason for decreasing blocktime.
David Perry
CC BY-SA 3.0
2011-09-21T23:16:40.657Z
I understand that brick-and-mortar stores are not high at risk, but vending machines, online services which "ship" digital goods or Bitcoin ATMs might be. A single coordinated attack at many locations simultaneously against a hypothetical type of Bitcoin ATM/vending machine that accepts 0/unconfirmed transactions for low amounts/cheap products could still cause severe damage for the operator. I was hoping there was at least something that could be done but it seems there is not. Thank you anyway for the comprehensive explanation!
Noah
CC BY-SA 3.0
2011-09-21T23:37:39.157Z
It would take quite a lot of effort and manpower to execute such an attack against vending machines at any meaningful scale. If I have thousands of dollars initial starting cost, dozens of people and months of time on my hands I'm just going to steal the vending machines. For all intensive purposes right now we're talking about the tiny flaw in a high-security deadbolt attached to a glass door. It's an attack with no market for exploitation at present, though it does behoove us to keep it in mind when building new infrastructure lest we make it a meaningful attack vector in the future.
David Perry
CC BY-SA 3.0
2011-09-22T08:27:20.437Z
+1 for a comprehensive answer. The BitCoinJ library has a wiki entry that is related: http://code.google.com/p/bitcoinj/wiki/SecurityModel
Gary
CC BY-SA 3.0
2011-09-26T09:06:34.023Z
Ok, since there really seems to be no other solution I'm marking this thorough explanation as accepted answer - thank you!
Noah
CC BY-SA 3.0
2011-09-21T22:10:41.217Z
2011-09-21T22:10:41.217Z
David Perry
<blockquote>
  <p>Related Question: <a href="https://bitcoin.stackexchange.com/questions/1192/would-a-reduced-block-generation-time-make-the-finney-attack-more-difficult/1200#comment-1357">Would a reduced block generation time make the Finney attack more difficult?</a></p>
</blockquote>

<p>I understand that the <a href="https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384" rel="nofollow noreferrer">Finney-attack</a> is the main reason why accepting a zero-confirmation transaction should be avoided for transactions of significant value or at on-demand websites that "ship" instantly.</p>

<p>Suppose a merchant needs to accept transactions near-instantly - what can he do to mitigate the risk of this specific kind of attack without relying on any third-party (escrow-like) service? Are there any practical strategies like checking large pools for the transaction, systematically delaying the acceptance of the transaction, etc. that actually work? What could be changed within the Bitcoin-client to lessen the likelihood of this attack-vector?</p>

<security><confirmations><revert-transaction>
What can be done to mitigate the risk of a Finney-attack?
Noah
# What can be done to mitigate the risk of a Finney-attack?

(Asked by: username_0 on 2011-09-21)

> Related Question: [Would a reduced block generation time make the Finney attack more difficult?](https://bitcoin.stackexchange.com/questions/1192/would-a-reduced-block-generation-time-make-the-finney-attack-more-difficult/1200#comment-1357)

I understand that the [Finney-attack](https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384) is the main reason why accepting a zero-confirmation transaction should be avoided for transactions of significant value or at on-demand websites that "ship" instantly.

Suppose a merchant needs to accept transactions near-instantly - what can he do to mitigate the risk of this specific kind of attack without relying on any third-party (escrow-like) service? Are there any practical strategies like checking large pools for the transaction, systematically delaying the acceptance of the transaction, etc. that actually work? What could be changed within the Bitcoin-client to lessen the likelihood of this attack-vector?

**Tags:** security, confirmations, revert-transaction


---

## 3 answers

### Answer by username_2 on 2011-09-21. Score: 7 | Accepted answer

The key to understanding why the Finney attack isn't really that big of a deal is understanding the business case for accepting 0/unconfirmed transactions. An online merchant doesn't usually have to accept such transactions since they probably do batch-shipping anyway. It's not required from an integration standpoint since the API includes many options to simply not return transactions without confirmations. The only business case that requires the acceptance of 0/unconfirmed transactions is when your customer is standing directly in front of you and won't be around for 10+ minutes. In such cases, a Finney attack isn't feasible and here's why:

Imagine I'm a scammer wanting to use the Finney attack against you, the honest merchant. I've spent a few grand and bought myself 3 GH/s worth of Radeon 5830 rigs. This number isn't arbitrarily chosen, I specifically picked it to make for easy math - 3 GH/s will net you about 1 block per month at current difficulties. Given that actual brick-and-mortar stores are closed for about 8 hours per night on average, this means that 1/3 of my found blocks will occur outside of business hours so on average I get a chance to double-spend with a Finney attack every 45 days.

Now as with all mining, there's no telling when you'll hit that lucky block so if I'm dead set on executing this attack I have to stay hypervigilant because once every 45 days I'll get an alarm of some sort telling me to go spend money at my target's store. I have to get there quickly because if I don't make my purchase and remotely trigger the release of the block fast enough, that block will get solved by some other miner and I'll lose my chance. So let's say on average it takes me 5 minutes to get somewhere, pick something and make a big purchase - I've got a 50% chance of failure, so now I'm able to execute my attack about once every 90 days.

Mining isn't cheap - my 3 GH/s setup draws something like 2 kilowatts, add in another 800 watts or so for cooling and at my local electricity costs it runs me about $8 a day to try for this attack. Multiply this by the 90 days it takes on average for me to be successful and I have to be successful to the tune of $710 just to break even. I'd make better money mining! Keep in mind that I've spent 16 hours a day every day for three months waiting for that alarm to go off too, so even if I double-spend $1420 (double my costs) I still only make $236.67 per month for my trouble - 49.3 cents per hour.

Oh and once you've made the purchase there's still the gap between then and releasing the block. If a block is found during that window, you've *actually* spent that money now. This particular attack is not without risk.

So there's something of an answer - not how to mitigate the attack but why the attack doesn't really matter. Online merchants don't *need* to accept 0 confirmation transactions since your stuff probably won't ship within 10 minutes anyway and brick-and-mortar merchants add a delay to the transaction process that makes the attack unfeasible. Even without the delay, the transaction would have to be positively huge to make any sort of profit and the attacker *still* stands a large risk of *actually* spending the money anyway. I don't really see this taking off.

> **Comments:**
> **username_2**: Come to think of it, this is one attack that reducing the blocktime actually *would* have an impact on. I suppose I owe a few folks on the forums an apology for all the times I've said the opposite. It still doesn't mitigate a 51% attack though, and I've never heard someone specifically cite a Finney attack as a reason for decreasing blocktime.  
> **username_0**: I understand that brick-and-mortar stores are not high at risk, but vending machines, online services which "ship" digital goods or Bitcoin ATMs might be. A single coordinated attack at many locations simultaneously against a hypothetical type of Bitcoin ATM/vending machine that accepts 0/unconfirmed transactions for low amounts/cheap products could still cause severe damage for the operator. I was hoping there was at least something that could be done but it seems there is not. Thank you anyway for the comprehensive explanation!  
> **username_2**: It would take quite a lot of effort and manpower to execute such an attack against vending machines at any meaningful scale. If I have thousands of dollars initial starting cost, dozens of people and months of time on my hands I'm just going to steal the vending machines. For all intensive purposes right now we're talking about the tiny flaw in a high-security deadbolt attached to a glass door. It's an attack with no market for exploitation at present, though it does behoove us to keep it in mind when building new infrastructure lest we make it a meaningful attack vector in the future.  
> **username_6**: +1 for a comprehensive answer. The BitCoinJ library has a wiki entry that is related: http://code.google.com/p/bitcoinj/wiki/SecurityModel  
> **username_0**: Ok, since there really seems to be no other solution I'm marking this thorough explanation as accepted answer - thank you!  

---

### Answer by username_1 on 2011-09-21. Score: 0

In the best-case scenario, the merchant would be listening to nodes all over the network for any conflicting transactions. If no conflicting transactions are broadcast before the legitimate transaction fully propagates, then the merchant can be sure that legitimate miners won't put a conflicting transaction into their blocks.

If the customer is mining, however, they can attempt to find a block and include a conflicting transaction before the rest of the network manages to find a block and include the legitimate transaction. In this case, the chance of the attacker succeeding is equal to the percentage of the network's total hashing power that they control (eg, an attacker mining at 100 GH/s would have a 1% chance of pulling this off if the network's total hashrate was 10 TH/s).

The attacker could wait until they find a block and include a transaction to send their coins to themself. Once they find the block, they withhold it from the network and attempt to make a purchase from the merchant. If they manage to complete the purchase and acquire the desired goods before the rest of the network finds a block, they release their pre-mined block and invalidate the legitimate transaction.

The latter version would probably be impractical to pull off on a brick-and-mortar merchant, simply due to the time required to get to the store, make the purchase, and leave after finding a block. An online merchant could accept the transaction immediately, but wait for at least one confirmation before shipping in order to prevent the attack.

> **Comments:**
> **username_0**: Thank you for the explanation - so there's not really anything that can be done for an online merchant or vending machine (where the time of purchase can exactly and arbitrarily be determined by the customer) to reduce the risk of routinely accepting zero confirmation transactions?  
> **username_2**: More of an explanation of what a Finney attack is than how to mitigate it. Of course you're welcome to start your own "What is a Finney attack" question and post your own answer. Just make sure you give others a chance to post possibly better answers before accepting your own ;)  
> **username_1**: @username_0: Yeah, vending machines are probably at the highest risk and can't do anything further to mitigate it without involving a third party (green address, insurance, etc).  Of course, the attacker is still in a situation where they have to wait by the vending machine for hours/days/weeks in order to steal a candy bar.  

---

### Answer by username_3 on 2011-09-21. Score: -3

*What can a merchant do to mitigate the risk this specific kind of attack?*

Wait for a few confirmations.

> **Comments:**
> **username_0**: Sorry, I thought it was obvious that I am looking for some technique to reduce the risk of accepting unconfirmed transactions (apart from the "listening period" to rule out simultaneously broadcast conflicting transactions) - anyway, I made it explicit now.  
> **username_4**: That's kind of like if the question was "what can you do to reduce your chance of getting injured in an airplane accident" and instead of giving answers about where to sit, what to wear, or what airlines to use, saying "drive instead".  
> **username_5**: I think you should delete your answer and make it a comment below the question. Both funny & informative to anyone who missed the obvious.  

---

