Bitcoin Forum
December 03, 2016, 01:58:43 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Sites accepting 0-confirmation txns  (Read 3305 times)
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2016



View Profile
May 15, 2012, 05:18:30 AM
 #1

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480773523
Hero Member
*
Offline Offline

Posts: 1480773523

View Profile Personal Message (Offline)

Ignore
1480773523
Reply with quote  #2

1480773523
Report to moderator
1480773523
Hero Member
*
Offline Offline

Posts: 1480773523

View Profile Personal Message (Offline)

Ignore
1480773523
Reply with quote  #2

1480773523
Report to moderator
Garr255
Legendary
*
Offline Offline

Activity: 952


What's a GPU?


View Profile
May 15, 2012, 05:20:23 AM
 #2

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.

“First they ignore you, then they laugh at you, then they fight you, then you win.”  -- Mahatma Gandhi

Average time between signing on to bitcointalk: Two weeks. Please don't expect responses any faster than that!
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2492


View Profile
May 15, 2012, 05:29:31 AM
 #3

I've noticed that BitcoinTorrentz accepts them.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
bitpop
Legendary
*
Offline Offline

Activity: 1918


https://keybase.io/bitpop


View Profile WWW
May 15, 2012, 06:36:58 AM
 #4

love BitcoinTorrentz

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
May 15, 2012, 07:32:18 AM
 #5

satoshidice.com ?

ahbritto
Full Member
***
Offline Offline

Activity: 128


Ripple


View Profile WWW
May 15, 2012, 07:39:35 AM
 #6

https://zipconf.com
Carlos L.
Legendary
*
Offline Offline

Activity: 952


View Profile
May 15, 2012, 08:43:38 AM
 #7

Try on CoinAd.com please
Blazr
Hero Member
*****
Offline Offline

Activity: 882



View Profile
May 15, 2012, 09:26:57 AM
 #8

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.

Busy ATM.
realnowhereman
Hero Member
*****
Offline Offline

Activity: 504



View Profile
May 15, 2012, 09:48:02 AM
 #9

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.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
Grix
Hero Member
*****
Offline Offline

Activity: 536



View Profile WWW
May 15, 2012, 11:09:21 AM
 #10

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

Buy High Powered Lasers from BitLasers.com
BTC: 1Fahk2aa4NS4Qds4VDAL4mpNArDEdV2K5K
Blazr
Hero Member
*****
Offline Offline

Activity: 882



View Profile
May 15, 2012, 11:19:11 AM
 #11

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.

Busy ATM.
Littleshop
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW
May 15, 2012, 11:54:18 AM
 #12

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
Hero Member
*****
Offline Offline

Activity: 504



View Profile
May 15, 2012, 12:04:30 PM
 #13

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.



1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
May 15, 2012, 01:18:59 PM
 #14

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
HorseRider
Donator
Legendary
*
Offline Offline

Activity: 1582


View Profile
May 15, 2012, 01:20:30 PM
 #15

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.

16SvwJtQET7mkHZFFbJpgPaDA1Pxtmbm5P
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 15, 2012, 01:37:03 PM
 #16

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
Full Member
***
Offline Offline

Activity: 140


View Profile WWW
May 15, 2012, 01:38:07 PM
 #17

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
Hero Member
*****
Offline Offline

Activity: 504



View Profile
May 15, 2012, 02:45:42 PM
 #18

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.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
mc_lovin
Legendary
*
Offline Offline

Activity: 1134


www.bitcointrading.com


View Profile WWW
May 15, 2012, 03:42:30 PM
 #19

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
Legendary
*
Offline Offline

Activity: 1470


View Profile
May 15, 2012, 03:51:57 PM
 #20

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!