Topic: Sites accepting 0-confirmation txns (Read 4052 times)

It shouldn't be seen as a silver bullet or magic weapon.  It would require a smart merchant who deals in low price, high margin transactions and is willing and able to do some risk analysis.  Remember credit cards are 0% risk either.  The goal for a merchant who needs to deal w/ real time tx shouldn't be 0% fraud but to minimize and manage that fraud.

I'm asserting that the merchant will indeed lose something.  He'll lose his product and not get his 5 BTC in the majority of cases with nothing balancing that loss.

If merchant waited 5 minutes then an attacker would not risk his block unless he expected to gain more than 25BTC from the merchant.

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.

I think we're miscommunitating somewhere, but I'm not sure where.   There is no publicly available Bitcoin software which is able to "see" the double spend and alert the site and the network itself won't propagate the conflicting transaction, so even if such software was widely available it would not be very effective.  

My family of sites all accept payments at zero confirmations:

Paysius.com
FeedZeBirds.com
SatoshiDice.com
Coinapult.com


If you try a double-spending attack, please get in contact with myself and bearbones (ira miller) so we can proceed together.

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.

Well there is "instant" and there is "instant".   Waiting even 10 seconds would make such weak attack worthless.  A good merchant's bitcoin node should be unknown.  It doesn't need to be on the same server as the storefront.  The merchant would see the double spend and halt the transaction.

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.

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.

What if the attacker has a whole bunch of purchases ready to be executed automatically as soon as he finds his double spending block?  Wouldn't all the merchants then be collectively underestimating the time they should wait?  The attacker could even offer a subscription service for a fee to increase his reward.

There is no double spend propagation, notification (even when it propagates to the victim), or repercussions (at least so far I'm not aware of anyone successfully being prosecuted for bitcoin based fraud, though I expect it will happen someday) ... this means that I can give my victim a transaction but 1ms later simultaneously give the same transaction to all the big pools.    The whole network will be my attacker then.

~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.

It allows me to get instant on demand access to large amounts of hash power at low cost and direct it how I like it.

One of the barriers to a Finney attack is that you have to cause a block to be mined with a valid but not publicly announced transaction— without tens of thousands of dollars of fixed equipment costs you can't do this without having to wait with your finger on the attack trigger for years.   GPUMAX lets you purchase hash power with Bitcoins, (which will, more or less be returned to you from successful mining,  the only cost to you is the GPUMAX marketplace premium on hash rate and the slight chance of increased orphaning).

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

Some people don't realize how easy and cheap things like GPUMAX make it.  

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).

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

~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.