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

I don't think that's true.  In recent blocks I see some bets and payouts occurring within the same block.  Also, see this statement from the site operator:


I outlined some potential attacks on SatoshiDice in another thread.  Perhaps one of them would meet your needs:

Coindl?  They let you download with 0-conf.

The odds of the next hash solving a block are independent of the failure of prior hashes. The time since the last block doesn't change the fact that the odds that the next hash will solve the block = 1/(difficulty * 2^32).

If someone were to use a system to increase the economic cost of a finney attack in production the most important factor is the global hashing power.  Difficulty indirectly reflects that but since difficulty only adjusts every two weeks if hashing power falls significantly between adjustments the time between blocks will rise and the margin of safety for the merchant will decline.  Alternatively if the attacker brings online a significant amount of new hashing power.

For most cases this should be merely academic as any merchant should pad in enough of a "house advantage" to ensure small changes in global hashing power don't material affect the expected value of the attacker.  Still it would be good for such a system to look at avg block time for say prior 24 hours and alert operator when any change outside of normal variance is detected.

I wouldn't recommend it for general purpose client.  There are significant limitations so it really should be used by merchants who intend to accept 0-confirm tx anyways and wish to increase their level of protection.

BitMe requires 6 confirmations AND 1 hour to pass since first seeing the transaction to be safe

Based on what's been released so far, that appears to be correct.

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.

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.

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.

That is 100% right if I understand you.

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

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.

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.

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.

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. 

6 is what most people use.

3 should be fine for most transactions though.

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

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.

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.

Try on CoinAd.com please

https://zipconf.com