What can be done to mitigate the risk of a Finney-attack? Related Question: Would a reduced block generation time make the Finney attack more difficult?


I understand that the Finney-attack 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?
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.