Bitcoin Forum

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 (https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384) 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.

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

I've noticed that BitcoinTorrentz accepts them.

love BitcoinTorrentz

satoshidice.com ?

https://zipconf.com

Try on CoinAd.com (http://CoinAd.com) please

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.

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.

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.

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. 

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.

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.

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.

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

That is 100% right if I understand you.

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.

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.

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.

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

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

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.

Coindl?  They let you download with 0-conf.

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:

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

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

oops.  ::)    still this seems like a lot of work for some low value digital goods for me.

try the attack here: http://bitcoinx.com/clocktweak. it will not get any easier than that. should also work with a normal double spend.

if you succeed I would not give a damn and probably would not even notice.

My family of sites all accept payments at zero confirmations:

Paysius.com (http://Paysius.com)
FeedZeBirds.com (http://FeedZeBirds.com)
SatoshiDice.com (http://SatoshiDice.com)
Coinapult.com (http://Coinapult.com)


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

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.

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

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

Effectively GPUMAX somewhat violates the security assumption of Bitcoin:  We assume that hash power is well distributed and at worst consolidated in a manner proportional to parties long term interest in the Bitcoin system.   By allowing the highest bidder to redirect hash power at will, a party can get enormous amounts by paying a small premium for just the time they need it.   I understand that the GPUMAX system has some protection against attack usage (though I've not heard details and don't know how complete they are), but the finny attack case is basically not possible for a middleman system to protect against because it looks so much like normal mining.  (In fact you can finny attack using an existing pools, if you can find one that either won't relay your double spend or you simultaneously put conflicting txn on their peers to prevent relaying of it.— GPUMAX lets you move hashpower where you need it for the attack)

GPUMAX only allows you to direct the power at preapproved pools, right?

Others have pointed out that you can do more than one attack per block—  but not only that, but:

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.   

The point of the Finny attack is that even fancy listening and alert stuff can't protect you against an attacker than can mine.  But even without the finny attack the lack of detection and notification means that zero confirmation transactions are trivially reversed without significant technical sophistication or expense.   They simply aren't safe for non-reversable/non-recourse transactions  (of course things like Spamoshidice are somewhat safe because reversals there also undo the payout),  and the finny attack means they can't easily be made safe.   

Of course, safety isn't always required but people should be aware of the risks.

He certainly could however targeting multiple merchants simultaneously would be difficult.  Each merchant may (likely should) have different hold period which complicates when to broadcast the block.  Remember we are generally speaking talking about small value transactions.   The goal is simply to increase the cost/complication/risk to the point it isn't worth it.  Even if finney attack works as long as the merchant doesn't include more value than it can afford to lose in the next block the loss can be mitigated.  Merchant either extends the hold period or goes to 1 confirmation.  The repeat value of the attack because negigible.  So huge upfront cost, complexity, risk of losing block for a one time attack on low value transactions?

It could happen.  Could you defraud a soda machine?  Probably however they are hardened "enough" to make such attack a futile exercise (especially as more become digital).  The small benefit is unlikely to outweigh the cost and complexity of pulling off the attack.


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.

Thanks for the thorough reply gmaxwell.

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.

If merchant waited 5 minutes then an attacker would not risk his block unless he expected to gain more than 25BTC from the merchant. You could just wait based on size of the deposit, but as mentioned the ability to do many of these in one block ruins that calculation. Waiting 2 blocks is starting to seem to be best in a lot of situations imo.

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.  

There is no amount of waiting, short of the first including block which is sufficient to show evidence that most of the hash power isn't attempting to mine some conflicting transaction, at least not currently.

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.

I believe that having multiple remote nodes with many connections is indeed what some merchant providers (Bit-pay?) do to ensure double spend detection.

And why is connecting to a majority of the network considered abusive, if I may ask? Reference for example piuk's blockchain.info site - as of this writing it is connected to about 300 nodes, but I believe this number has been in the 2000-3000 range before.

hmm, i wonder if you could get paid from feedzebirds by finney paying for an ad and on other accounts retweet it

Of course there is.  It is called a well connected bitcoind.

Lets call the two tx
A: the valid spend
B: the double spend

Attacker tries to send both of them to the network.  Remember attacker can't send the tx directly to me he can only broadcast them to some or all of the peers he happens to be connected to.  BTW what are the IP address of my bitcoind nodes? :)

So what are the possible outcomes:
B wins the race to the pools AND my bitcoind (and all my direct peers).  I never see A.  While I may not be aware of the double spend I haven't got paid = no loss
A wins the race to the pools AND my bitcoind (and all my direct peers).  Double spend failed.  I may not be aware of the double spend but I got paid = no loss.
B wins the race to the pools AND A wins the race to my bitcoind. This is the interesting one.

First I would argue the third case is already difficult but we can make it more difficult by simply waiting 10 seconds.  If anyone ONE of my direct peers gets B first then it will relay it to me and I will be aware of A & B.

Often (incorrectly) it is assumed the attacker just needs to get A to "me" and B to the "pool" however that isn't accurate.  The attacker needs to get A to "me" AND all of my peers (which for one of my nodes is 827) AND there may/should be MULTIPLE "me's" while simultaneously getting B to "the pools".

A nearly impossible task when the attacker doesn't know which node is me, how many me's there are, nor does he know which nodes are my direct peers, nor can he control the relaying of the peers.

This is true.  The attacker wouldn't attack because he doesn't expect to gain anything.  What I'm disputing is this:


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.

Sorry yeah that was a bad reference.  I updated it in the quote.

The point is that one can increase the economic cost of the attack to the point where a profitable attack is no longer viable.  The merchant still loses but so does the attacker.  The example above was showing the break even point but a smart merchant would push it solidly negative for the attacker.  

Much like the blockchain can't prevent NON-ECONOMIC 51% attacks the merchant can't prevent NON-ECONOMIC finney attacks.  If someone has BTC to burn they can force the merchant to take a loss (or stop accepting 0-confirm txs).   Still the more likely attack is one where the attacker is actively trying to profit from the merchant.  By forcing the attacker to hold a rapidly depreciating asset (the block reward) for a random period of time the merchant can make the attack riskier, and more complicated for the attacker.

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.

And that is why the download services that take 0-confirmation transactions are totally safe: bandwidth is cheap, and if a file is stolen like this, they can just simply tell whoever would have been paid that the file was stolen and that they won't be paid for that download. The person who would have been paid wouldn't care either, since to them, the person who stole the file might as well have just pirated it instead of stealing it directly.

Hell, if you've ever downloaded a song at Amazon MP3 or itunes, they don't even bother authorizing the credit card for a few hours. Defeating that doesn't even require you to do something as technically difficult as a normal Bitcoin double-spend!

Double-spends matter to so few people that it's sort of ridiculous. As I've mentioned in the past, double spends only matter if all of the following are true:

1) Purchaser is anonymous.
Real life isn't anonymous, since it can be recorded with a video camera.
2) Item is irrevocable/irretrievable.
You could buy a video game license instantly, without risk to the publisher, because it is revocable.
3) Transaction is instant.

Finney attacks add even more restrictions:

4) Item is easy to resell/you can easily get a refund.
Finney attacks don't always work, and unlike normal double-spends where you can try it only when you want the item anyway, you will most likely need to be able to resell the items to make up for your loses when the Finney attack fails. This restriction isn't always true, but it certainly reduces the motivation to steal the item.
5) Attacker is able to pick the time that they pay at, within a few seconds.
Imagine waiting to do a Finney Attack at the grocery store. You get a notification to checkout immediately, then some couponer gets in the checkout line right before you do. Or, more likely, as your stuff is being scanned at the checkout, you lose the Finney Attack because another block was found as you were checking out.

As you can see, real life zero-confirmation transactions are already at least as safe as credit cards are to the merchants, and more likely they are several orders of magnitude safer. This is even true of most internet transactions: if credit cards are already good enough for a business, zero-confirmation bitcoin transactions likely are too. This could even eventually include selling gift cards if you are able to convince a retailer to let you revoke the remaining balance of a gift card if the transaction fails (currently, this is a big if, but it can happen if retailers start selling their own giftcards for bitcoins).

Off the top of my head, the only things that I can think of that would need to worry about the Finney Attack are places that sell cash or cash-like items. Mostly, that would be exchanges, but that definition can also include any e-wallet that allows you to withdraw without tying the withdrawal transaction to the deposit transaction (which would be a good idea for e-wallets to start doing; thank you satoshidice for the idea) or without waiting 6 confirmations.