Sites accepting 0-confirmation txns

[gmaxwell]

It's come to my attention that some people are underestimating the danger of accepting zero confirmation transactions because they don't understand the finny attack and/or don't realize how easy and cheap things like GPUMAX make it.  

Are there any actual sites accepting 0-confirm transactions?  I'd like to perform a finny attack demonstration with the consent of the site operator in order to better educate users about this risk.

[1714983368]

1714983368

[1714983368]

1714983368

[Garr255]

It's come to my attention that some people are underestimating the danger of accepting zero confirmation transactions because they don't understand the finny attack and/or don't realize how easy and cheap things like GPUMAX make its.  

Are there any actual sites accepting 0-confirm transactions?  I'd like to perform a finny attack demonstration with the consent of the site operator in order to better educate users about this risk.

+1. This would be far too easy to exploit.

[theymos]

I've noticed that BitcoinTorrentz accepts them.

[bitpop]

love BitcoinTorrentz

[finway]

satoshidice.com ?

[ahbritto]

https://zipconf.com

[ingrownpocket]

Try on CoinAd.com please

[Blazr]

satoshidice.com ?

It now requires a couple of confirmations.

ZipConf would be the most interesting to try this on, as they claim to have developed a system to reduce the double spends significantly for 0 conf transactions.

[realnowhereman]

It's come to my attention that some people are underestimating the danger of accepting zero confirmation transactions because they don't understand the finny attack and/or don't realize how easy and cheap things like GPUMAX make it.  

The Finny attack is indeed a risk, but it requires a trade that has instantly collectable credit/goods; and someone willing to risk a high value item (are you seriously going to do Finny attacks to get a chocolate bar?).  There aren't many places where you can get instant credit for a deposit and then instantly cash it out; and if you haven't run off with the goods within 10 minutes, then the merchant can see you've double spent and debit your account again.

You also run the risk that while you are conducting your transaction, a block is found -- even if it doesn't have any related transactions in it, it invalidates the held-back block; making the subsequent double spend impossible.

While it's theoretically a reasonable attack; practically it is a lot of work for something that will net no more than petty shoplifting would -- and then only sometimes.

[Grix]

What is the golden mean for safety and speed of transaction? I've set my site at 3 confirmations IIRC. Is this too low?

[Blazr]

What is the golden mean for safety and speed of transaction? I've set my site at 3 confirmations IIRC. Is this too low?

6 is what most people use.

3 should be fine for most transactions though.

[Littleshop]

What is the golden mean for safety and speed of transaction? I've set my site at 3 confirmations IIRC. Is this too low?

6 is what most people use.

1 should be fine for most transactions though.

FTFY

There has been no confirmed use of this attack in the real world.  You should be stealing at least 50 BTC worth of something if you are using it.  For things less then 50 BTC it makes no sense.  For things where the site checks later and ships it makes no sense.  Only for things delivered right away and where the site does not check again is this an issue. 

[realnowhereman]

There has been no confirmed use of this attack in the real world.  You should be stealing at least 50 BTC worth of something if you are using it.  For things less then 50 BTC it makes no sense.  For things where the site checks later and ships it makes no sense.  Only for things delivered right away and where the site does not check again is this an issue. 

Agreed.

Since you (you the attacker, not you Littleshop) have already generated your block (and that would be close to guaranteed 50BTC), and by not sending it right away you are risking someone else generating an alternative while you much around trying to steal a banana, you should really be aiming to steal significantly than 50 BTC worth with the attack to cover the times when your attack fails.  What shall we say?  100 BTC doesn't sound unreasonable to me.

What sort of lunatic merchant is going to accept a zero conf for $500 worth of goods?

Worries about this sort of attack just aren't practical.  The attacker would do better to just claim his block reward, than hold it back.  And as the value of bitcoin increases, this attack gets less and less practical and profitable.

[etotheipi]

satoshidice.com ?

Since satoshidice.com returns all bets using the same coins as were sent to it, invalidating your wager would also invalidate any reward transactions.  

Because of the time delay, by the time you found out if you lost, it's definitely too late to try to conditionally invalidate the transaction, at least via simple double-broadcasting.

[HorseRider]

If the transaction is small, or the service or goods must be delivered in a manner of longer than 1 hour, it does not matter you attack it or not.

[DeathAndTaxes]

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

[Nyaaan]

If the transaction is small, or the service or goods must be delivered in a manner of longer than 1 hour, it does not matter you attack it or not.

That is 100% right if I understand you.

[realnowhereman]

One way to look at it is the time value of a pending block reward.  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.  Thus the expected cost of a Finney attack is ~0.083 BTC per second.

Love it.

Excellent analysis.

I'm not sure it's entirely accurate -- surely the cost per second is highly dependent on when, within the ten minute window, you generate your attack block -- but that's hardly relevant.  What matters is that whatever the correct value, there is a time period after transaction receipt that makes the attack have negative expected value... let's just build that time into  the UIs and have a customised acceptance time for every transaction, depending on its value and time.

[mc_lovin]

Certain gambling websites accept 0-conf tx's but they only pay you out winnings after your transactions have been confirmed.  Businesses like this are pretty safe.

[jgarzik]

satoshidice.com ?

It now requires a couple of confirmations.

ZipConf would be the most interesting to try this on, as they claim to have developed a system to reduce the double spends significantly for 0 conf transactions.

If I understand correctly, ZipConf is essentially a private network, that guarantees only specific sites where they have a backchannel method of verifying transactions besides the P2P network itself.