A single Finney attack can contain several transactions, affecting several merchants at once.

When considering a defense against a Finney attack we must first recognize that the attack is undetectable until after the fact.  So unlike with non-Finney double spend the goal should be to increase the cost of such an attacker.

One way to do this is look at the "time value" of a pending (but not yet broadcast) block.  A solved block is worth ~50 BTC.  The odd that another peer will find and broadcast (and thus invalidate the attackers pending block) is ~0.17% per second.  We can estimate that any delay to execute a Finney attack costs the attacker ~0.083 BTC per second.

Finney Attack Cost (in BTC) = (50 BTC) *(1-(1 - 1/600)^(tx time in seconds))

Example:
Say I have a service which will instantly deliver a xbox timecode worth 5 BTC.  Now lets assume I have a comprehensive double spend detection system in place so I can detect non-Finney doublespends BUT I am still vulnerable to Finney attacks right?  I can't detect or prevent a Finney attack BUT I can make them prohibitively expensive for the attacker.

5 BTC 0.083 = 60 seconds.  At 60 seconds the "double spend game" is fair.  In the long run neither the attacker or merchant will gain or lose anything.   Still we want to make it prohibitively expensive.  So say I delay delivery 120 seconds instead.  We will call this delay the "hold period".  During the hold period I monitor the network for new blocks looking for new blocks which contain the double spend.  If I detect a double spend (either in a block or as a relayed tx) I halt delivery.

Expected Value to Attacker:
If attacker doesn't delay block until delivery is complete it will cost him nothing but his attack will always be detected and failed.
The hold period forces the attacker to delay broadcasting the block until delivery is complete which in this example is 120 seconds.

The chance a peer will find a duplicate block and invalidate the attackers block (at a loss of 50 BTC to the attacker ) is ~= 1 - (1-0.0017)^120 = 18.2%

81.8% of the time the attacker will gain 5 BTC (game code stolen).
18.2% of the time the attacker will not gain 5 BTC (tx where attacker paid legit remains valid)  AND will additionally lose the 50 BTC block.

5.0 *0.818 - 50*0.182 = -4.973.  In the long run the attacker can expect to have a net loss of 5 BTC for each attempt.  While the attacker will get away with it some of the time the attack has a long term negative expectation.  The attacker is essentially gambling with the merchant being the house and having in this example a 8% house advantage.  A merchant could adjust the hold period to strike a balance between speed and safety.  For example even w/ a delay of 60 seconds the expected loss is 0.  By not making the delay unknown and/or pseudo random it increases the chance the attacker will release block too soon providing advance warning to the merchant.  When a failed attack is detected merchant could increase the holding period or switch to 1 block confirms.

If anyone wants to play that game (and is willing to wager a total of 100 BTC spread out among 20 or more tx) I would be willing to make a demonstration site.  


Simple version:
Low value tx can be safely protected by delaying delivery by more than 1 second for each 0.083 BTC in value (or ~5 BTC per minute).

Question: in what way does the Finny attack directly related to GPUMAX?

~144 Blocks per day... 99% found by good guys. This means there can only be a handful of finney attacks every day. Compared to credit card fraud this is completely neglectable. Especially for low value transactions.

Is that right?

If the merchant waits 60 seconds before sending goods priced at 5 BTC to the attacker, then he has a 1 in 11 chance that someone else will solve a block, making the attacker lose his 50 BTC block reward.  In this case the merchant makes a regular 5 BTC sale and profits by his regular markup.

He also has a 10 in 11 chance that nobody else solves the block.  In this case the attacker gets the goods worth 5 BTC as well as the 50 BTC block reward.  The merchant is out 5 BTC.

That's not fair.  It's break-even for the attacker - he loses 50 BTC 1/11th of the time and gains 5 BTC 10/11 of the time, and 50*1/11 = 5*10/11 - but it's a net loss for the merchant.  Most of the time he gets ripped off for 5 BTC, and 1/11th of the time he makes a small percentage of 5 BTC.

No matter how long the merchant waits, there's never any chance of him gaining the block reward since the merchant isn't mining, and so there's nothing to balance the risk of losing his goods to the Finney attack.

There are things that could be done in the protocol to help this, e.g. flooding information about the existence of double spends.  Or merchants with hacked up software which abusively tries to connect to the whole network may have a fighting chance ...  but in the direct and obvious implementation with current software, what you're suggesting is not safe.  Suggestions like having the node remote might be a good idea— though they're bad for reliability... but that isn't even something our community advises as a best practice.   Security isn't about being secure iff you get lucky and a bunch of random characteristics about your setup happen to be the right ones that make an attack hard.