Important! Regarding Restaurants Accepting Bitcoin

[rjk]

Also, isn't this already common practice?

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.

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.

[1714092853]

1714092853

[Phinnaeus Gage]

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!

Today I had the bombest miso soup and crunch rolls from this Japanese restaurant in cypress
~user on Twitter

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~

[Maged]

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?

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.

[kjlimo]

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. 

[Phinnaeus Gage]

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.

[Herodes]

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.

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.

[DeathAndTaxes]

I'm sure Bit-Pay could do something about this, like generating a random number of addresses for merchants that are randomly rotated for every purchase.  This feature could be turned on and off at will. 

So, for example, a company may sign up with Bit-Pay and receive 20 wallet addresses linking to their Bit-Pay account.  At random, 1 out of these 20 addresses would be used for the first transaction after which another 1 out of 20 addresses would be selected randomly for the 2nd transaction.  The merchant could choose to turn the randomness feature on and off at will so that someone who thinks they can simply look at one address and multiply it's received BTC by 20 to estimate the gross earnings would be making a mistake.

Another option would be for Bit-Pay to use a Bit-Pay-owned static address that indirectly funnels the money from the customer to the merchant.  So, if a customer purchases something, the money would be sent to the Bit-Pay-owned address, and then the money would be send to the merchant.

Diagram:    Customer -----> Bit-Pay ----->  Company A, or B, or C, or D, or E, etc.

As far as going straight from a customer's wallet to a merchant's wallet, improved client options for addresses may be needed.

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.

[DeathAndTaxes]

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.

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.

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.

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.

[edd]

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.

No "new" solution is needed.  It is called 1 address per order.  It really is that simple. Actually is 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.

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.

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 swat.

As far as managers stealing one options is to use mult-sig another option 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 is cryptographically impossible for anyone at the store to steal anything.

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.

[chrisrico]

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).

[the joint]

I'm sure Bit-Pay could do something about this, like generating a random number of addresses for merchants that are randomly rotated for every purchase.  This feature could be turned on and off at will.  

So, for example, a company may sign up with Bit-Pay and receive 20 wallet addresses linking to their Bit-Pay account.  At random, 1 out of these 20 addresses would be used for the first transaction after which another 1 out of 20 addresses would be selected randomly for the 2nd transaction.  The merchant could choose to turn the randomness feature on and off at will so that someone who thinks they can simply look at one address and multiply it's received BTC by 20 to estimate the gross earnings would be making a mistake.

Another option would be for Bit-Pay to use a Bit-Pay-owned static address that indirectly funnels the money from the customer to the merchant.  So, if a customer purchases something, the money would be sent to the Bit-Pay-owned address, and then the money would be send to the merchant.

Diagram:    Customer -----> Bit-Pay ----->  Company A, or B, or C, or D, or E, etc.

As far as going straight from a customer's wallet to a merchant's wallet, improved client options for addresses may be needed.

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.

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?

[DeathAndTaxes]

I'm sure Bit-Pay could do something about this, like generating a random number of addresses for merchants that are randomly rotated for every purchase.  This feature could be turned on and off at will. 

So, for example, a company may sign up with Bit-Pay and receive 20 wallet addresses linking to their Bit-Pay account.  At random, 1 out of these 20 addresses would be used for the first transaction after which another 1 out of 20 addresses would be selected randomly for the 2nd transaction.  The merchant could choose to turn the randomness feature on and off at will so that someone who thinks they can simply look at one address and multiply it's received BTC by 20 to estimate the gross earnings would be making a mistake.

Another option would be for Bit-Pay to use a Bit-Pay-owned static address that indirectly funnels the money from the customer to the merchant.  So, if a customer purchases something, the money would be sent to the Bit-Pay-owned address, and then the money would be send to the merchant.

Diagram:    Customer -----> Bit-Pay ----->  Company A, or B, or C, or D, or E, etc.

As far as going straight from a customer's wallet to a merchant's wallet, improved client options for addresses may be needed.

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.

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?

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?

[Phinnaeus Gage]

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]