(slightly) Simpler store pay method

[nelisky]

You can't walk away from the POS, not get your change, and come back expecting anyone is going to believe you if there is a failure.  I can see how this could work with small amounts and trusted vendors.

That is not necessarily true. Right now bitcoin is a marginal thing, but were it mainstream the blockchain would have the payment recorded and you would be holding the priv key to the address, so you could prove you paid 'someone'. If the recipient could be linked to the store on which you are buying (I know a script kiddie would just change the receiving address on the teller at mcdonalds, given the chance, but that's why merchants may need a blackbox approach to POS) and it would be left to the store to prove they sent the change.

Remember we are talking (or at least I am) normal stores, receipt at the end of purchase (maybe even stating the address they sent to so they are protected against people complaining they stole the coins) and good reasons to keep the customer satisfied (i.e., not go out of business). I'm not trying to push this as the ultimate solution for merchants, but rather one we can work on right now and is very much no-nonsense.

[nelisky]

Getting to the store, I buy some porn^H^H^H^H educational dvds and head to the teller, where they say my total is 17.85 BTC. I punch that value into my wallet app, enter my pin and a QR code appear. The store scans it and I get my receipt.

To take it one step further... why not just scan it on the shelf and walk out? It's now yours. Eliminate the middle man.

I'm not sure I get it... you mean the shelf would be connected to the POS and have a scanner there so you would flash your QR codes, grab the goods and flee? This is the middle man being the teller...

It is actually a great idea, but one more closely related to the bitcoin vending machine thread (that I'm too lazy to search and link), whereas this is about using bitcoin as 'just another payment system' on existing stores. I'm not sure we would be making many friends if we told people "And your employer can now sack you, because they have bitcoins!".

[memvola]

This is very 'low tech', we're not sharing transactions, just bitcoin keys, and in a controlled way

It doesn't seem very appealing to me, maybe because it looks like a hack rather than a solution, mainly because of the "change" problem.

[So I think a complete transaction needs to be transferred from the user's device to the store's computer. Fewer problems (you get your change back, can spend all the money from a key in different times, don't have to divide into reasonably-sized several keys in the first place, etc.), more secure.]

I think information density is not a big problem, a few hundred bytes can be transferred through the display, even if a single frame QR-code might not be enough in some odd circumstances. A more colorful encoding or an "emergency" multi-frame scheme could be used, but I'm guessing it wouldn't be necessary in most use cases.

So, I think this would be the perfect solution for POS:

• User transfers his wallet (or a few keys) to the smartphone using the app when a connection is possible.
• On POS, enters the amount to be transferred and an image appears [containing the transaction], which is scanned by the store. Store trusts the transaction after waiting a few seconds.
• App keeps the account of spent coins as if it were connected to the net, so that a double-spend will never happen. User can spend all the money on the device.
• The transactions show up on the thick client, or the service provider's web page. App re-syncs when it has connection again.

[Steve]

This is very 'low tech', we're not sharing transactions, just bitcoin keys, and in a controlled way

It doesn't seem very appealing to me, maybe because it looks like a hack rather than a solution, mainly because of the "change" problem.

[So I think a complete transaction needs to be transferred from the user's device to the store's computer. Fewer problems (you get your change back, can spend all the money from a key in different times, don't have to divide into reasonably-sized several keys in the first place, etc.), more secure.]

I think information density is not a big problem, a few hundred bytes can be transferred through the display, even if a single frame QR-code might not be enough in some odd circumstances. A more colorful encoding or an "emergency" multi-frame scheme could be used, but I'm guessing it wouldn't be necessary in most use cases.

So, I think this would be the perfect solution for POS:

• User transfers his wallet (or a few keys) to the smartphone using the app when a connection is possible.
• On POS, enters the amount to be transferred and an image appears [containing the transaction], which is scanned by the store. Store trusts the transaction after waiting a few seconds.
• App keeps the account of spent coins as if it were connected to the net, so that a double-spend will never happen. User can spend all the money on the device.
• The transactions show up on the thick client, or the service provider's web page. App re-syncs when it has connection again.

Exactly...this is what I was describing in my post.  You also need to provide the merchant with the private key to sweep the funds.  No need for more than one initial address for loading up the device and you transfer the exact amount to the merchant.  No need for Internet connectivity, a camera, or any other wireless communications on the customer device (at the point of sale).

[memvola]

You also need to provide the merchant with the private key to sweep the funds.

Isn't it all in the transaction itself? It would be the same packet you'd broadcast to the network.

(Ah, just realized you'd need to know the merchant's address, so what I'm thinking wouldn't work for dynamic addresses, i.e. the user would have to scan the store's QR code first.)

No need for more than one initial address for loading up the device and you transfer the exact amount to the merchant.  No need for Internet connectivity, a camera, or any other wireless communications on the customer device (at the point of sale).

I also think this would be easier for the user since it would require no key management.

I imagine it would be accompanied with online services that keep your wallet in encrypted form, so that you can use the service to display your wallet but would have to download/sync in order to spend them (though it could just be a local javascript page like WebCoin, so the "downloading" part would be transparent for the user). From the user's end, basically the app would sync instantly when it has Internet connection, which would hopefully change nothing if the store successfully broadcasts the transaction.

[Steve]

You also need to provide the merchant with the private key to sweep the funds.

Isn't it all in the transaction itself? It would be the same packet you'd broadcast to the network.

(Ah, just realized you'd need to know the merchant's address, so what I'm thinking wouldn't work for dynamic addresses, i.e. the user would have to scan the store's QR code first.)

You got it.. We're trying to avoid needing a camera on the customer phone.  We may be limited to web only apps on the iPhone.

No need for more than one initial address for loading up the device and you transfer the exact amount to the merchant.  No need for Internet connectivity, a camera, or any other wireless communications on the customer device (at the point of sale).

I also think this would be easier for the user since it would require no key management.

I imagine it would be accompanied with online services that keep your wallet in encrypted form, so that you can use the service to display your wallet but would have to download/sync in order to spend them (though it could just be a local javascript page like WebCoin, so the "downloading" part would be transparent for the user). From the user's end, basically the app would sync instantly when it has Internet connection, which would hopefully change nothing if the store successfully broadcasts the transaction.

Yeah, you could have a full wallet, the only thing you need to do in advance is stage the funds needed to a single address (that minimizes the size of the transaction that has to be given to the merchant).

[ovidiusoft]

Very nice ideas in this topic! I'd love a thin client on my phone, so I can use it without connectivity... What about this variation on the theme, which has some issues, but also the advantage of being much easier/faster to implement:

* the user has some coins on a Internet accessible system. It could be a web wallet or a self-hosted service. I would prefer to host my own, it doesn't need to be a complicated thing, just a bitcoind with a simple and secure web interface, maybe also free redirector for people behind NAT-s. Let's call this https://paymesomebtc.com/ovidiusoft/

* the user also has the thin client on his smartphone. No keys, no btc stored on it!

* the user has a shared secret with the thick system (a pin, a password...).

I see the payment as going like this:

* user walks to the cashier, scans the store QR code (bitcoin address) with his phone.

* user enters the amount and the shared secret

* phone app generates a QR code which will redirect to https://paymesomebtc.com/ovidiusoft/DATABLOCK.   DATABLOCK contains the receiving address and the amount and will be encrypted with the shared secred.

* cashier scans the code, gets redirected to a very simple page that says: "Press OK to send X amount to address Y" (or "No funds available"). He presses OK, a transaction is made.

The system is not perfect, of course. Some problems:

* system exposed on the Internet == risks of hacking. Probably not a big issue, if you're dealing with small amounts and it's dead-simple to set up even for dumb users. It should probably be able to punch a hole in the firewall, detect attacks and automagically blacklist IPs. Shouldn't require ANY configuration except the shared secret. Maybe it should be integrated in the standard client as an option "Make X amount available for mobile spending" (which will register a URL and start the local web server).

* encryption strength. The algorithm must be symetrical with simple enough keys, so it would be easy to do a plain text attack on in. A random salt will help, also OTP for the shared secret (via SMS) - when a transaction is requested, the thick client sends a sms to the client's phone. He tells the code to the cashier who can then click on the OK button and validate the transaction.

* QR code size. My phone wasn't capable of reading a version 40 code from https://en.wikipedia.org/wiki/QR_Code#Storage , so we might have a problem encoding all that data in the URL.

So, what do you think?