Quote from: Come-from-Beyond on March 13, 2013, 07:38:09 PM

What about such a way:

Alice has 9 addresses with 1, 2, 4, 8, 16, 32, 64, 128, 256 mBTC. This lets her to pay any amount from 1 to 511 mBTC (for example, 50 mBTC == 32 mBTC + 16 mBTC + 2 mBTC). When she purchases an item she enters the amount on her smartphone and it displays 3x3 matrix filled with QR-codes. In our example only 3 codes will be displayed, so the seller scans them and signs the transaction. If Alice goes to other department she uses other 9-addresses set. The software can build such sets on the fly using one special account with all her pocket coins.

So? Seems to be paparazzi-proof.

So Alice (or the app itself) has to manually set up 9 different addresses before she walks into the shop. By your logic, if an image of the three QR codes she used was captured by someone, if they went in later and tried to take her money out of those accounts, they would be empty, since they only had those amounts in them. That works, however, now after Alice makes that 50 mBTC purchase, she needs to re-fill those addresses to be ready for the next purchase. If she just re-fills the same addresses, the attacker can get the coins from those addresses. So, she has to use new addresses every time, and set up 9 addresses every time.

You've turned the transaction from a push to a pull (giving the merchant the private key to do the transaction, rather than the client), but haven't solved the issue that Alice needs to bring a smartphone, with a charge, with a particular app on it, into the store. You did remove the requirement that Alice's device needs internet access to do the transaction (she can manually type in the transaction amount, and it can figure out which pre-configured addresses to use, assuming the funds are still there since the last time the blockchain was checked).

Quote from: whitenight639 on March 13, 2013, 10:55:56 PM

You take your goods to the checkout - merchant scans them with their normal POS system, the system calculates total and itemised bill / VAT reciept and encodes it into a QR code which is displayed on a cusomer facing screen along with another QR with the payment address of merchant, the customers wallet / payment app on there phone then reads both QR codes and asks the customer for a passowrd or a confirmation to send payment, it can also record the Itemised bill and total for customer records just like a receipt.

What you're describing is very close to the current system; the merchant somehow shows the buyer the public address of the merchant and it's up to the buyer to make the transaction. You've added the option for an itemized receipt into the mix, which is nice, but doesn't solve the issue that it requires the buyer to be the one to make the transaction happen, with a specific app on a specific piece of hardware.

Quote from: alir on March 13, 2013, 08:53:49 PM

There is no need to reinvent the wheel, Bitcoin has already done that. All we need to do is make spending bitcoin as easy as credit/debit cards. This can be achieved simply by a trusted third party system that processes customer to merchant payments. It would function identically to modern credit card terminal purchases.

So, some new central authority issues cards with their own account numbers (formatted the same way as current credit cards), which the central authority links to a bitcoin address and does the transactions. Yes, that would be nice, but, as you say, there's no such trusted giant to be the processing authority. Plus that centralizes bitcoins, which negates one of its benefits (decentralization). Plus the central authority would probably need to take fees out for its own profit from every transaction, which would put it back to exactly like the current credit card company systems, which I don't think is where bitcoin wants to go (it's a new currency, set to correct mistakes of existing systems, not repeat them).

Quote from: cjp on March 13, 2013, 07:42:01 PM

Here in the Netherlands, hardly anyone uses credit cards; most people don't even have one. Instead, electronic POS payments are typically done with a card known as a "PIN" card (actually a Maestro card), which is a debit card directly linked to your bank account. Transactions are non-reversible (or at least hard-to-reverse, I'm not really sure). the customer doesn't have to pay a transaction fee, and when looking at how eager shops are to tell you you can pay with PIN, they don't have to pay too much either. An essential security feature is that the customer has to enter his secret "PIN" code into the POS terminal; if the POS terminal is untampered, the PIN code is never shared with the shop owner or anyone else.

There is increasing news about POS terminals and ATMs being tampered by criminals, who obtain the PIN code in that way, and then either also obtain the card information (by reading the magnetic stripe) or (with newer, more secure cards) simply steal the card. The fundamental problem here is that the authentication (entering the PIN code) happens on someone else's device.

I think security can actually be a lot better if authentication happens on a device owned by the customer. This has the additional feature that the customer can choose the security method (PIN number, passphrase, voice recognition, fingerprint, whatever). Smartphones might be good enough for this purpose, but since they're also used for so many other things, they're vulnerable to hacking. A separate device, slightly resembling a pocket calculator, would give a really good level of security.

I like this idea; you could publicly display a QR code of a private key, if the data were encoded with a passphrase (symmetric encoding of some sort). Yes, we have issues in the US as well with criminals using card skimmers and whatnot to steal people's money that's hidden behind a card requiring a PIN. Having the merchant do the transaction does require that the customer trust the hardware/software of the merchant, which is true for current PIN car purchases, and would be true of a "bitcoin credit card" too.

A longer PIN number (rather than 4 digits, which is the US debit card standard), or a password (not just numbers) would make it a bit more secure, but not much. I agree the entering of the PIN would be more secure on the purchaser's device, but I like that this setup wouldn't require that. There could be a POS device with a number pad (with physical blinders to prevent nearby people seeing you type your PIN) like current PIN systems, but would also have the option for the user to push a button saying "enter on my device". Then, if they had a phone, with the appropriate app, with a battery charge, and they didn't trust the merchant's hardware, they could enter the data that way.

And if some other vendor was able to come out with a more simple piece of hardware to enter the pin, that would be even better. Or, if a card were created that adhered to the EMV protocol (the integrated circuit protocol in credit cards), and the card had an onboard chip with enough processing power to request a PIN and use it to decrypt the private key, that might work. As the bitcoin community is growing to the point of making custom hardware specific to bitcoin (I'm looking at you, Butterfly Labs!), it might not be long before someone can design an IC microchip for a credit card that would serve this purpose, more cheaply than requiring a smartphone.