<p>The time for when a block has been confirmed is the main issue that seems to arrise. The coffee shop problem (I want my coffee now but this may take 10 minutes to confirm payment)</p>

<p>The mobile reception issue could be resolved by allowing restricted open access with on-site wifi service</p>

<p>There are third party services which may help this very effectively (www.flexcoin.com)</p>

<p>Also SolidCoin offers 3 minute blocks and may be substantially more elegant if a third party service was chosen not to be used for small transactions.</p>

CC BY-SA 3.0
2011-09-04T14:51:48.050Z
AFAIK, for small transactions, it is probably not worth it to double spend, so the coffee shop could just accept immediately with zero confirmations and have an almost zero fraud rate.
ripper234
CC BY-SA 3.0
2011-09-04T15:10:39.813Z
True, its all about faith in the system.
MaxSan
CC BY-SA 3.0
2011-09-04T16:28:29.377Z
Not just about faith, but also understanding that the cost to double-spend is larger than the price of coffee.
ripper234
CC BY-SA 3.0
2011-09-04T17:47:10.260Z
It's highly unlikely anyone would ever attempt, in person, a double spending attack for less than the equivalent of $500 or so.
David Schwartz
CC BY-SA 3.0
2011-09-04T18:42:21.790Z
+1 to ripper234. As discussed in http://bitcoin.stackexchange.com/questions/382/what-percentage-of-bitcoin-transactions-never-complete attempting to spend twice without a 51% attack results in one transaction being invalidated almost immediately and as mentioned in ripper234's comment spending twice with a 51% attack costs significantly more than anything your average merchant could possibly have for sale.
David Perry
CC BY-SA 3.0
2011-09-05T02:43:50.720Z
A race attack costs nothing to attempt except that if it fails (let's take a guess and say it will fail 50% of the time) then the attacker just made a legitimate purchase.

Now if the purchase is at a vending machine, for instance, where the attacker is purchasing something easily convertible to cash, like postage stamps, there might be a strategy that is profitable and a lower chance of getting caught.

So there will be some risk analysis required though at this point, race attacks are not likely to be a problem for a merchant who follows the recommendations (e.g., no inbound connections).
Stephen Gornick
CC BY-SA 3.0
2012-04-08T00:42:00.147Z
Don't ETF card transactions in shops take weeks for the funds to transfer, all that happens at the checkout is a validity check
Chris Huang-Leaver
CC BY-SA 3.0
2012-04-10T12:31:59.993Z
Yes this is exactly true, but as its centralised the bank can put a hold on the funds so you cant "double spend".
MaxSan
CC BY-SA 3.0
2011-09-04T13:43:35.307Z
2011-09-04T13:43:35.307Z
MaxSan
<p>Let's say all usability problems were solved. I'm imagining something like shops with tills that present QR codes for the amount and payment address for a transaction, and mobile clients exist that can scan them and present and easy Pay / Do Not Pay choice. So paying in a shop by Bitcoin would be no harder than credit/debit card, or even cash.</p>

<p>What limitations inherent in the Bitcoin protocol and network might prevent this from working? I'm thinking of things like:</p>

<ul>
<li>Network latency (transaction being received by the shop) holding up queues</li>
<li>Poor mobile reception meaning shoppers find they unpredictably can't send money</li>
<li>Lack of confirmations before the customer leaves meaning shops may sometimes lose payment</li>
</ul>

<p>I can see this being less of an issue in slower transactions, eg pubs, bars, restaurants. Are the above problems likely to materialise, and if so, are there any other types of transaction that might be affected?</p>

CC BY-SA 3.0
2011-09-04T14:00:44.997Z
You might want to check [How to accept bitcoin payments at a real world store?](http://bitcoin.stackexchange.com/questions/327/how-to-accept-bitcoin-payments-at-a-real-world-store)
nmat
CC BY-SA 3.0
2011-10-07T21:47:25.983Z
The primary issue with not waiting for confirmations is the [Finney attack](http://bitcoin.stackexchange.com/q/1192/85), a form of double-spending attack that doesn't require massive hashing power.
David Schwartz
<bitcoin-economy><mobile><face-to-face-payment>
Is Bitcoin suitable for fast transactions, eg in shops?
Ash Moran
# Is Bitcoin suitable for fast transactions, eg in shops?

(Asked by: username_0 on 2011-09-04)

Let's say all usability problems were solved. I'm imagining something like shops with tills that present QR codes for the amount and payment address for a transaction, and mobile clients exist that can scan them and present and easy Pay / Do Not Pay choice. So paying in a shop by Bitcoin would be no harder than credit/debit card, or even cash.

What limitations inherent in the Bitcoin protocol and network might prevent this from working? I'm thinking of things like:

* Network latency (transaction being received by the shop) holding up queues
* Poor mobile reception meaning shoppers find they unpredictably can't send money
* Lack of confirmations before the customer leaves meaning shops may sometimes lose payment

I can see this being less of an issue in slower transactions, eg pubs, bars, restaurants. Are the above problems likely to materialise, and if so, are there any other types of transaction that might be affected?

**Tags:** bitcoin-economy, mobile, face-to-face-payment

> **Comments:**
> **username_1**: You might want to check [How to accept bitcoin payments at a real world store?](http://bitcoin.stackexchange.com/questions/327/how-to-accept-bitcoin-payments-at-a-real-world-store)  
> **username_2**: The primary issue with not waiting for confirmations is the [Finney attack](http://bitcoin.stackexchange.com/q/1192/85), a form of double-spending attack that doesn't require massive hashing power.  

---

## 1 answers

### Answer by username_3 on 2011-09-04. Score: 5 | Accepted answer

The time for when a block has been confirmed is the main issue that seems to arrise. The coffee shop problem (I want my coffee now but this may take 10 minutes to confirm payment)

The mobile reception issue could be resolved by allowing restricted open access with on-site wifi service

There are third party services which may help this very effectively (www.flexcoin.com)

Also SolidCoin offers 3 minute blocks and may be substantially more elegant if a third party service was chosen not to be used for small transactions.

> **Comments:**
> **username_4**: AFAIK, for small transactions, it is probably not worth it to double spend, so the coffee shop could just accept immediately with zero confirmations and have an almost zero fraud rate.  
> **username_3**: True, its all about faith in the system.  
> **username_4**: Not just about faith, but also understanding that the cost to double-spend is larger than the price of coffee.  
> **username_2**: It's highly unlikely anyone would ever attempt, in person, a double spending attack for less than the equivalent of $500 or so.  
> **username_5**: +1 to username_4. As discussed in http://bitcoin.stackexchange.com/questions/382/what-percentage-of-bitcoin-transactions-never-complete attempting to spend twice without a 51% attack results in one transaction being invalidated almost immediately and as mentioned in username_4's comment spending twice with a 51% attack costs significantly more than anything your average merchant could possibly have for sale.  
> **username_6**: A race attack costs nothing to attempt except that if it fails (let's take a guess and say it will fail 50% of the time) then the attacker just made a legitimate purchase.  Now if the purchase is at a vending machine, for instance, where the attacker is purchasing something easily convertible to cash, like postage stamps, there might be a strategy that is profitable and a lower chance of getting caught.  So there will be some risk analysis required though at this point, race attacks are not likely to be a problem for a merchant who follows the recommendations (e.g., no inbound connections).  
> **username_7**: Don't ETF card transactions in shops take weeks for the funds to transfer, all that happens at the checkout is a validity check  
> **username_3**: Yes this is exactly true, but as its centralised the bank can put a hold on the funds so you cant "double spend".  

---

