What can be done to mitigate the risk of a Finney-attack?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Wait for a few confirmations.