It all depends on the target risk. A Bitcoin ATM machine (deliver BTC and get USD) where an exploit could rapidly be exploited and empty the machine? You probably want confirmations unless you want to go broke. A $6 combo meal for lunch where "delivery" is going to take a couple minutes anyways? You are unlikely to be successfully double spent (or at least no more likely then customer using counterfeit or stolen CC).
You are definitely right there. And that sort of gets to what I was saying - I think a technological attack (via scripts, for example) is easier than a face-to-face initiated one. The ATM would need special consideration for confirmations due to its increased untraceability (no person to see a face or just human reactions). Again, I think its the overhead involved once one of the transactions takes place face to face that makes this issue harder to execute.
However you are misunderstand that in a double spend there aren't two vendors. The second tx just sends funds back to the user.
Not sure what you mean here... I know about the "change" transaction, but that doesn't say anything about the vendors involved. I was meaning that the same person would not try to double-spend against the same vendor; the second spend would have to take place elsewhere physically, introducing the problem of coordination.
A lot would depend on how sophisticated the merchant (or merchants provider) is. If the merchant runs a network of nodes that connect to a large fraction of the Bitcoin network it is unlikely that the double spend could reach a miner without the merchant detecting it during the transaction. 0-confirm tx are also subject to finney attacks so the value of the transaction is going to matter a lot. It isn't worth it to try and Finney attack a $5 transaction but a $50,000 one? Well it certainly would be and the merchant would be unable to detect the threat.
Definitely. One thing that relates to this though that I also think is interesting is that, in general, the length of time of the transaction (time spent in store) is proportionate to the value of the transaction. A small purchase of a coffee or drive-through food is quite fast and also low dollar amount, while a $50k transaction would likelty be for a car or a boat, which involves significant time at a store. In the latter case its no big deal to initiate the payment before the last of the papers are passed along, so that the transaction can have multiple confirmations before the customer leaves.
The middle case also applies - a few hundred dollars would be spent on a bug ticket item like electronics, furniture, etc. Again, something that likely involves some amount of time (loading a vehicle, arranging delivery or something) which gives time for the transaction to be confirmed. (There are of course exceptions to this rule of thumb, such as grocery or department stores, but then maybe BTC isn't suited to them?)
The only real "trouble" case is the low-dollar amount, and the question of whether it's worth it or not is really the issue.
TL/DR version:
There is no single risk level acceptable for all merchants under all scenarios. 0-confirm for low value in person transactions may certainly be viable but the merchant should either be sophisticated or use a sophisticated payment processor which actively monitors the risk.
Yup - again, good point. Agreed that just using a sophisticated process to cover your bases should be enough that this isn't a concern for the low-dollar merchant.
