Sites accepting 0-confirmation txns

[mcorlett]

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.

[1714093203]

1714093203

[1714093203]

1714093203

[1714093203]

1714093203

[freewil]

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

[DeathAndTaxes]

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.

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.

[SgtSpike]

Coindl?  They let you download with 0-conf.

[twobitcoins]

satoshidice.com ?

It now requires a couple of confirmations.
o reduce the double spends significantly for 0 conf transactions.

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:

To address some former posts - we have not/will not change SatoshiDice payouts to require a confirmation. The goal is always for the payout to be instant.

And if there are any material changes to how it works that would affect your bets, we will absolutely post it here.

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

So, has anyone executed a double spend attack on SatoshiDice yet?  The site claims it is not possible because the payout transaction depends on the bet transaction, so reversing the bet will also reverse the payout.  But that doesn't prevent attacks: all you have to do is wait to see if you win or lose, then reverse the bet (and hence the payout) only if you lose.  It could be done in a few ways:

1. Simple race: Try to connect to SatoshiDice as directly as possible, and as soon as you receive a losing payout, send a double spend of the bet transaction to any parts of the network that have not yet seen the original bet.  The site could prevent this attack fairly effectively by introducing a small delay and sending the original bet transaction to as many nodes as possible (especially mining nodes).

2. Finney attack: Generate a block that contains a payment to yourself but don't distribute the block.  Send the same coins to SatoshiDice.  If you lose, distribute the block and reverse the losing bet.  If you win, don't distribute the block.  This attack requires you to give up the block reward in the case of a wining bet, so it is only effective if bets can be high enough.  With current bet limits, it could be marginally profitable.  If bets of say 1000 BTC were permitted, attackers would be all over that.

3. Mining attack: Place a bet as usual.  If you lose, try to put a double spend of your bet transaction in the next block you generate.  With a few percent of the network hash power, you could overcome the house edge and make a profit.  Any decent sized mining pool could profit from this attack now, regardless of betting limits.

One more possible attack:

4. Duplicate transactions:  It is possible for the same transaction hash to occur more than once (see BIP 30 for details).  Since the result of a bet depends only on the day's secret and the bet transaction hash, it is possible to place a bet and if it wins, repeat the same bet again within the same day.  For example, prepare some transactions as follows: Mine a block with address A, then send the coins to B, then to C.  Mine another block with address A and send the coins to B.  Mine another block with address A and leave the coins there.  Now you can send coins from C to SatoshiDice and if the bet is a win, place two more bets B->C->SatoshiDice and A->B->C->SatoshiDice.  The site could prevent this attack easily though (perhaps even unintentionally, if it uses transaction hashes as keys in a database to determine whether a payout has been sent).

Here is an easier double spend attack:

5. Bet transaction that won't confirm: Intentionally construct a bet transaction that miners won't include in blocks due to fee rules.  Then after you see whether you won or lost, you have plenty of time to mine your own block that includes either the bet and payout transactions or a double spend of the bet transaction.  Of course not all miners follow identical rules so you may not have an arbitrarily long amount of time to mine the block, but it makes the attack much more feasible and profitable than if you had to mine the very next block.

[phelix]

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

[mcorlett]

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

[phelix]

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

[evoorhees]

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.

[d'aniel]

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

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.

[R-]

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

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

[gmaxwell]

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

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)

[mcorlett]

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

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

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

[gmaxwell]

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

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.

[DeathAndTaxes]

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.

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.

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.

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.

[R-]

Thanks for the thorough reply gmaxwell.

[dooglus]

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.

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.

[FreeMoney]

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.

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.

[gmaxwell]

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.

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.

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.

[rjk]

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.