Topic: Important! Regarding Restaurants Accepting Bitcoin (Read 2473 times)

I'm pretty sure that my main concern has been addressed with all your kind replies. Heaven forbid a competitor got an unfair advantage on their competition via gleaning blockexplorer and/or blockchain.

Now I can concentrate on Foursquare on Rails or FoR.

~Bruno~ (not Bruno Banani) [you may want to Google this one]

How annoying would it be for amazon to manually move each credit card transaction.... er wait the don't computers handle it in a few clock cycles.

Also why would merchant need to move funds unless they were spending them?  If they are spending them then it requires a move anyways right?

Because how annoying would it be for the merchant to individually move all those funds from each wallet?  How many sales does Amazon make a day?  How many transfers would that require?

Restaurants seem like a great place for the use of Bitcoin. Imagine a party of 10 people wanting to split the check and they don't have cash.

One the one hand, the restaurant staff has to split the check and process 5-10 credit cards.

On the other hand, the restaurant prints a unique address (in text and/or QR code form) on the receipt. The party then determines ownership of their individual portion of the check, and sends that amount to the address. The restaurant staff then merely have to verify that the received amount is greater than or equal to that of the check, and anything above that gets sent to a virtual tip jar. This process could be completely automated, but even if it's done manually I think it would be less of a burden than credit cards (and without a large fee).

I'm still manually processing orders and I also generate a new address for each transaction. If I'm not at home, I've been known to pull a new deposit address from my Mt. Gox account and issue that.

Restaurants will probably find it easier than most retail stores to utilize bitcoins as payment. As you're most likely well aware, Phinnaeus, when a customer starts complaining about anything, they're usually looking for free food, not a refund. Heck, when I owned a dry cleaning plant, I was infamous for my talent at getting unhappy customers to accept a coupon for free cleaning instead of a refund whenever there was a problem with their order that couldn't be fixed to their satisfaction.

One could also create a "petty cash" wallet with limited funds for the manager's use in the event a refund is unavoidable.

No "new" solution is needed.  It is called 1 address per order.  It really is that simple. Actually if Bitcoin ever became mainstream I wouldn't imagine any buisiness would EVER use anything other than 1 throw-away address per transaction.  Bitpay does this right now.  Hell cascius processes order by hand and the Bitcoin address is unique for every transaction.  Everytime you request a deposit address from Mt.Gox it gives you a new one.  The "technology" and "skill" to do this is beyond trivial.


Just like how Amazon manually combines 20,000 credit card receipts every day to balance their books?   A single core celeron could generate reports on billions of transactions per day without breaking a sweat.

As far as managers stealing one option (mentioned above) is to use mult-sig.  A simpler one is to never give the manager access to the private keys to begin with.  No reason wallet can't be generated offsite and each restaurant loaded with 100,000 (or a billion) public addresses.  The store can only accept money.  It becomes cryptographically impossible for anyone at the store to steal anything.

Why rotate?  Addresses are negligible in cost.  You could have a quadrillion merchants doing a quadrillion sales per second and not even reach 1% of available addresses before out sun dies.

Not exactly 100% sure what you're asking about here, but law enforcement could for instance track a bank payment into an exchange, and then get the address to which coins were transferred when moved externally. From there on, tracking would still be possible, but there would be ways to obscure ones tracks.

In effect, law enforcement could track 10 separate transactions from point of origin into an restaurants wallet, while a competitor would have no idea what was going on. This would require law enforcement to have konwledge about all valid btc addresses in the restaurants wallet, and also knowing where the bitcoins came from, if they could be tracked to an exchange, then they could be tied to bank transactions.

I doubt however there would be any serious effort from law enforcement to track payments to a restaurant unless there was a really serious investigation ongoing.

Can it be both ways? A law enforcement agency is able to track nefarious activity on the blockchain but Le Gavroche won't be able to glean any relative information from its direct competitor, Ratatouille.

Couldn't you just have the bitcoins sent to a central wallet.dat file located at "headquarters?"

The restaurants don't need to be able to refund bitcoins or give change. 

This is where things get totally awesome...

Multisignature addresses. With a multisig address, as soon as the customer sends bitcoins to the address, it can only be spent if you have m-of-n signatures. For example, the owner could give every manager a key and then only allow the funds to be spent if 2 managers agree on a transaction. Things like this will be extremely easy as soon as Bitcoin supports the new Pay-to-Script-Hash proposal. Tools that utilize it would come out not too long after that.

Thank you, Herodes, et al., for your well informative post(s). I took away many a ideas from it. I truly understand that at the onset of an establishment accepting Bitcoin, this is not too much of an issue. My grave concern, as outlined in the OP, is that further down the road, if a defense mechanism is not in place, a competing establishment could glean valuable information. Whatever final solution is developed, bear in mind that at the end of the day the accounting aspect shouldn't be too much to bear. Heaven forbid a proprietor asks his manager for the reports at the end of the day, but has to wait til his manager hunts, collects and combines all the addresses. Now, another concern popped into my head (sorry about all this, folks): What would stop a rogue manager from transferring coins out of the system to his own address?

But on the other side of the good coin, a restaurant could opt to not to hide their transaction, thus allowing the world to see exactly what people enjoy eating at his fine establishment. (brb--going to Twitter to drive this great idea home) Back!


Pretend that this Twitter user used Bitcoin to pay for her meal. Not only is she not afraid to broadcast to the world what and where she ate, she'll be able to offer up proof of the transaction to her followers, as well as the rest of the readers of her tweet. She'll provide a link to the restaurant's menu where it would not only show that what she stated is fact, but would also show perspective customers which entrees were purchased the most via Bitcoin, albeit at first via fiat. Consider it 4 Square on Rails (hope the my analogy is correct).

Allow me to take this one step further. A restaurant could choose to broadcast their Bitcoin food sales on Twitter or via some other social media platform, although a time delay may be order.

~Bruno~

Fortunately this should become less ambiguous with the release of 0.6.0 which supports signmessage within the GUI. Now all we need to do is to get signmessage integrated into BitcoinSpinner and other mobile apps, if they don't have it already.

It is the recommended practice.

I've seen restaurant's that print a QR-code and laminate it and set it up on the cashier as well, that means they have perhaps only a single receiving btc address, or perhaps a new address for each day. As for receiving payments, if the customer does it in front of the staff, and he's saying he pays immediately, and it shows up on their screen immediately (although as 0/unconfirmed), there's no need for different receiving addresses to identify the payment of this particular customer. A payment can also be identified on it's TxID, but as that's public information anyone could claim it, but the shop could print the TxID as a reference number on a printed receipt for instance.

Note: A TxID is the reference you get when you make a bitcoin transaction. It's not visible in all clients, but it's looks something like 8703f0076c65ff7e2295445a0d526a34b90e461a1b09cf665f0fd7bb7821dc2c and it uniqely identifies a particular transaction, which can later be looked up, for instance on block explorer.

Also, isn't this already common practice?

Granted, new businesses who want to test out the demand tend to use a single address but AFAIK almost all automated solutions use one address per payment simply because you can't track individual payments otherwise. Correlation may or may not be a problem depending on how you utilize your bitcoins.

In an ordinary circumstance, they would be spent through diverse channels and collecting enough information to reach a useful sum of earnings is pretty difficult. Even if what you only do with them is to send to a single exchange, you can use different receiving addresses for each bulk transfer.

Phinnaeus Gage:

For a developer it's straightforward to develop a solution that generates a new receiving bitcoin address for every transaction. This new address could either be generated on the spot, or it could be taken from a pool of pregenerated addresses. It's true what you say that if a business uses the same address all the time, it would be just like the public having access to their bank account (ie. seeing all their transactions).

There are numerous ways this could be solved, but first one would have to consider how important it would be to hide this information from public view. Perhaps some restaurant owners wouldn't object to anyone knowing how much bitcoin transactions they did, perhaps it's 2% of their overall sales anyway, so there would be no reason to be overly sensitive about the privacy.

In the event that a business simply doesn't want anyone else to see all their transactions, they would need to have a unique address for every payment received. That might seem like a daunting taks, but unless you're amazon.com, it's pretty manageable. For a restaurant this could mean that when it's time to pay the bill, the cashier simply selects bitcon as the payment method, then the customer is presented with a QR-code to scan and make the payment that way, or there could be a very short and easy url-shortener the customer could just type in to get the whole bitcoin address, like 'https://tb.co/3r7'.

It would also be possible for the restaurant to present the menu, and even make a order system the customer could access available over wifi once the customer enters the restaurant, then payment addresses could be generated based on mac-addresses or ip adresse, depending on whether it's a local network only, or connected to the internet. It would even be possible for a customer to have a btc address permanently assigned to him at that restaturant, so he later could look through his bills to have an overview (but it should be optional), as the standard should be a new bitcoin address for each transaction done.

The restaurant would need to have a well programmed system that made encrypted backups of the store's wallet to multiple remote locations after each purchase, so that in the event of failure of the system, the bitcoins the customers paid would not be lost. I would imagine that most restaurants simply would not have the technical knowledge or expertise to make this themselves, so it would probably have to be outsourced to companies that specialized in merchant solutions for bitcoin.

For everything to work flawlessly, there would need to be good design, redundancy and simplicity of use. For instance a restaurant could offer a app for bitcoin and iphone that could be installed on the phone, from which the visitor could order his meal and pay bitcoins. This way the restaurant could also verify that the funds where received before the customer left, as it would most likely be a few confirmations in that time. Usually eating at a restaurant takes around an hour or more.

It would also solve the problem of a customer running from his bill, as he would always pay up front. If he paid too much, or had a complaint and needed a refund, then the restaurant could just reinstate him the coins. I haven't looked into all the possible merchant systems that exists, but if something like what I described here doesn't exist (doubt it), it's bound to be implemented by someone soon.

So in summary, to have bitcoins accepted at a restaurant, the owner of the restaurant should be aware/educated of every aspect of using bitcoin, and a good merchant solution should be used, that will make it almost as easy or just as easy as using cash to make the payment.

One good argument is that if the restaurant now is accepting debit or credit card, a certain percentage of their earnings will go to the credit card companies and banks. Typicall fees of 3% or less. A negative aspect with bitcoin though is that there often is big fluctuations in it's worth relative to fiat money, so if the restaurant can't accept the price swings, they would need to convert to fiat money immediately, probably on an exchange, and this would mean they would need to pay a trading fee, which could be anything from 0.7% to 0.25%. Then they would also need to get the fiat money out of the exchange to their bank account, unless they paid their staff wages in BTC. Perhaps in the future, this will happen, and the steps for needing to exchange the bitcoins to fiat money will not exist.

But currently, there's so much technicalities that the head of the average restaurant owner would spin around it's own axis trying to comprehend it all, so in short what would be needed to have bitcoin as a popular option at restaurants would be to have companies that does all the integration, and can guarantee for the earnings of the restaurant.

So with a good solution, and good sales tactics, I'm sure a lot of restaurant and other brick and mortar businesses could be talked into accepting bitcoins, but there would need to be some incentive for them to do it. I'm sure the 'no fee'-alternative would be a good selling point, but only if there are good solutions that can be readily adopted.

Also there's another good argument, I'm sure today a lot of restaurants lose revenues over customers that pay with cards they don't own (ie. stolen cards). With bitcoins, once the payment is done, it's done, and there's no chargebacks, ever. This is because of the nature of the irreversibility of bitcoin transactions.

We also have another selling point. It's the coolness of this cryptocurrency. I would think it would be 'posh' and 'cool' to use the smart phone to make the payment, and using a QR-code would by many be considered as high tech and interesting. So for a lot of free advertising, the first restaurant in a town could claim to be the first one in that town to accept bitcoin, and thus I'm sure a lot of people would go there because they became curious, and news papers would write about it, which would mean free PR for the restaurant.

As for the negative points, I already mentioned a some of them, mainly the volatility, and the technical barrier and the simple fact that most people simply have no clue what bitcoin is. For the time being, I'm sure that this would be more of an experiment for most restaurants, than something they would get most of their income from. But in big cities, bitcoin enthusiasts would certainly go to places where they could spend their bitcoins.

I hope this gave some insight, and I'd be happy to answer more about the technical side of things.

It sure is interesting that more and more brick and mortar shops is accepting bitcoin.

I'm no programmer, but every time I (personally) want to accept bitcoins from a new source, I make a new address and labelled it for that transaction.

I imagine that a programmer with a minor effort could automate that process to give a unique address to each customer.

Bruno, you'll want to keep in mind that publicly aware transactions is part of the theory of bitcoin.  I don't think it's that big of a deal, because there are ways to limit the amount of information available.  

It doesn't seem like GrubGo is using bit-pay.com, so they will need to do this on their own.

I encourage a programmer to reach out to them, but I doubt GrubGo will be worried about it until they start getting 20+ orders via bitcoin.

Note: This would only work if the deposits went straight to a MtGox or some kind of mixing service. If it went to the restaurant's wallet, you could correlate the outputs with the inputs.

Great! Therefore, you see that this is an important aspect that needs to be addressed for reasons I've outlined? And chances are, it's a relatively easy fix?

Right, if I use a new address each time and forward all my funds straight to MtGox each time I receive, the funds will be mixed together with all the other MtGox deposits and can't be linked.

They will need integration with their existing payment systems.  Alternatively, servers could generate an address and display the QR on their smartphone.  There is work to be done here, but a system could be built to guarantee one address can only give you info for a single transaction.