Sites accepting 0-confirmation txns

[drakahn]

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.

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

[1715693755]

1715693755

[1715693755]

1715693755

[1715693755]

1715693755

[1715693755]

1715693755

[1715693755]

1715693755

[DeathAndTaxes]

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.  

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.

[dooglus]

If merchant waited 5 minutes then an attacker would not risk his block unless he expected to gain more than 25BTC from the merchant.

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

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.

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.

[DeathAndTaxes]

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 neither gain or lose anything.

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.

[Maged]

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.