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?