Is a 0 confirmation double spend for retail possible?

[drawingthesun]

regarding https://bitcointalk.org/index.php?topic=130764.0
I'm not sure if this was really a success. To this day have any 0 confirmation double spend ever succeeded?

Has the https://en.bitcoin.it/wiki/Double-spending#Finney_attack
Finny attack ever worked either??

Can a merchant accept 0 confirmation purchases without having to worry about a double spend? This merchant would sell products up to the value of $1000, would a attack to save $1000 be worthwhile or is this something we have to worry about?

Thanks

[empoweoqwj]

Nobody should accept a transaction with 0 confirmations. It doesn't matter if you are a merchant or a seaman.

[drawingthesun]

Nobody should accept a transaction with 0 confirmations. It doesn't matter if you are a merchant or a seaman.

I sea, So a POS device using the blockchain is never going to be feasible then? No buying coffee with Bitcoin unless a third party handles the transaction.

[gmaxwell]

I sea, So a POS device using the blockchain is never going to be feasible then? No buying coffee with Bitcoin unless a third party handles the transaction.

off-chain doesn't necessarily have to be a trusted third party, though at the moment thats all thats implemented, or you copy ID with the payment to create a credible threat of prosecution... or you simply take the thefts as a cost of doing business,— that kind of thing is naturally rate limited by how many cups of coffee the thief can walk away with.

[Rothgar]

Nobody should accept a transaction with 0 confirmations. It doesn't matter if you are a merchant or a seaman.

I sea, So a POS device using the blockchain is never going to be feasible then? No buying coffee with Bitcoin unless a third party handles the transaction.

I would sell coffee 0 confirm for POS transactions. 

Today:

You sell coffee someone spends one counterfeit $20 bill and the business is out $20.

The future:

You sell coffee someone double spends 2 uBTC ($2) to buy a cup of coffee.  The business is out around $2.  I don't see why this cant be in the coffee shops business model.

[Peter Todd]

off-chain doesn't necessarily have to be a trusted third party, though at the moment thats all thats implemented, or you copy ID with the payment to create a credible threat of prosecution... or you simply take the thefts as a cost of doing business,— that kind of thing is naturally rate limited by how many cups of coffee the thief can walk away with.

The security requirements for small transactions with physical presense can be remarkably small: http://boingboing.net/2008/05/06/ontario-bakery-succe.html

[nevafuse]

There is a risk of a 0 confirmation transaction being double spent, but it isn't a guarantee.  There are ways to minimize this risk by adding a transaction fee.  If I'm McDonalds, I'd probably accept 0 conf transactions.  The savings & convenience should outweigh the risk of double spends. 

People may even keep specific addresses to use for frequent, low value transactions that have "credit scores" attributed to them.  Blockchain.info already keeps track of double spends, McDonalds could just pay them monthly for access to that information.  Now McDonalds knows whether the address has been double spent from previously or not.  If the address has never been used, McDonalds could deny the transaction on the assumption you may attempt to double spend.

Of course trusted third parties could handle high value, quick transactions for a fee.  But the fee would probably make it not worth it for low value transactions.

[P_Shep]

This whole double spend at a POS thing... not exactly the easiest thing to do, surely?
I mean, your standing there at the cashier paying for your coffee and at the exact same instant, you spend the money elsewhere. How whould you even do that?

[Peter Lambert]

This whole double spend at a POS thing... not exactly the easiest thing to do, surely?
I mean, your standing there at the cashier paying for your coffee and at the exact same instant, you spend the money elsewhere. How whould you even do that?

Right. The person would literally have to be sending out a transaction to other nodes at the exact same time the sent out the transaction to a node you see. I think if you wait a couple seconds and watch the person, you should be pretty safe. If somebody is able to go through the effort of programming a custom client that simultaneously broadcasts transactions to multiple points in the network, they would not expose their creation for just a couple dollars worth of possible profit. There are other, more profitable ways in which they could direct their energy.

[Syke]

A double-spend would be pretty easy if the purchase transaction was sent without a fee, then the double-spend transaction was sent with a standard fee.

[Peter Todd]

A double-spend would be pretty easy if the purchase transaction was sent without a fee, then the double-spend transaction was sent with a standard fee.

You make a very important point.

Currently the majority nodes on the network use code that will not replace a transaction with another one under any circumstance. However, if fees were a major source of income from miners, it would make sense to mine the highest fee transaction the miner knew about regardless of whether or not it replaced a previous transaction with different outputs.

If even one or two miners/mining pools start implementing this, perhaps under the guise of allowing people to easily "adjust" the fees of their transactions, all the assumptions about the difficulty of getting double-spends mined will change overnight.

Of course, we do have a weapon against mining pools: given the infrequency of target-meeting PoW solutions a hasher can easily change their hashing setup to fail to send the shares that happen to meet the target, thus cheating the pool operator out of the block and effectively stealing all the shares. P2Pool combats this with a 0.5% reward to the block finder, but it's easy to see how a pool identified with double-spends could be attacked.

However you can run a "pool" in a different way; call it a "Block Opportunities" service. Now the service simply gives each hasher a work unit that pays the whole coinbase to the hashers chosen address. If the hasher withholds the solution, they've just wasted their effort. Of course it gets rid of the variance reduction that pools provide, but the long-term profit is still the same. I'm sure there are lots of hashers with setups large enough to consider essentially mining solo with such a service in exchange for the higher reward, not to mention it can obviously be done in a decentralized way as well by modifying the Bitcoin client to preferentially connect to other nodes with a simple "max-fee-wins" policy.

[falschgeld]

A double-spend would be pretty easy if the purchase transaction was sent without a fee, then the double-spend transaction was sent with a standard fee.

[...] modifying the Bitcoin client to preferentially connect to other nodes with a simple "max-fee-wins" policy.

I raised the very same issue in this thread: https://bitcointalk.org/index.php?topic=192918.new

[Blueberry408]

A McDonalds or a Starbucks would have enough BFL mini rigs at HQ to pre-auth the trans in house.
With a credit card, you can still buy stuff with just a carbon copy impression of the card.  I wouldn't be surprised if a few showed up to the upcoming bitcoin future of payments show. 

There is a risk of a 0 confirmation transaction being double spent, but it isn't a guarantee.  There are ways to minimize this risk by adding a transaction fee.  If I'm McDonalds, I'd probably accept 0 conf transactions.  The savings & convenience should outweigh the risk of double spends. 

People may even keep specific addresses to use for frequent, low value transactions that have "credit scores" attributed to them.  Blockchain.info already keeps track of double spends, McDonalds could just pay them monthly for access to that information.  Now McDonalds knows whether the address has been double spent from previously or not.  If the address has never been used, McDonalds could deny the transaction on the assumption you may attempt to double spend.

Of course trusted third parties could handle high value, quick transactions for a fee.  But the fee would probably make it not worth it for low value transactions.

[Stampbit]

So a double spend would have to be performed at the exact same time? So even if you waited a minute for one confirmation then what chance is there that the double spend will succeed?

[nevafuse]

So a double spend would have to be performed at the exact same time? So even if you waited a minute for one confirmation then what chance is there that the double spend will succeed?

You don't have to send the 2nd transaction at the same time, but the longer you wait, the least likely it will succeed because the original transaction will probably have more traction. 

Trying to double spend after 1 conf would be pretty difficult.  You can query blockchain.info & see how often orphans blocks happen.  I think last time I looked at it, it happened like once or twice a day.  So basically that means you'd have to be double spending right around that off chance that an orphan gets generated - which you won't know until the next block (another 10min). 

Then you have situations like the 0.7 vs 0.8 fork that allowed for 100+ conf double spends depending on which version you were using vs the person you were double spending against.