Topic: Bitcoin Credit Cards: How to create a POS device? - page 3. (Read 4349 times)

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

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.

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

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.

I don't know what country your from or the situations there, but in the UK The vast majority of crappy corner shops take card payments with POS terminals that connect to the internet to verify payments, the bigger retailers have customer facing screens and self service automated checkouts. I fail to see how a small screen displaying a couple of QR codes is expensive? Even if paying by OTC physical Bitcoins the merchant would most likely want to redeem /verify the coin / private key before releasing goods. As for customers, many people use smart phones, I did myself untill they started putting GPS in them all, I never said the customer software couldn't run on a dedicated hardware wallet or similar device.

it seems incredibly clunky and wasteful to have 9 bitcoin addresses every transaction for every customer,

this

You're requiring the merchant to make an expensive hardware upgrade/investment. But rather than just supply them with an all-in-one system worth investing in, you're requiring their customers to also have smartphones with data available otherwise the merchant needs to supply free WiFi. All that to make a bitcoin purchase.

You don't think it's redundant that the user have internet access to verify a purchase when the merchant right in front of them can process the whole payment more securely/faster with the internet they already have for that reason?

I'm failing to understand how that is even remotely easier than the systems already in place. I really want to understand your thought process here.

This one is easy,

You take your goods to the checkout - merchant scans them with there 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.


so any "peeping tom's" will just see your bill and the merchants address which could also be dynamically created by the POS software if for some reason the merchant wanted to use different addresses.

The actual sending of payment would be done through internet connectivity which is used by merchant POSs' anyway so in rural areas without mobile internet the merchants could provide wifi, could even be built into the POS.


 

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.

Because no service like this currently exists, there is no monopoly holding back competition. This is where it opens up for aspiring bitcoin entrepreneurs. Any POS payment processing company introduced would be smart to provide a safe professional service or risk being replaced by a competitor.

Ideas involving sending the merchant more than the purchase and requiring them to send the "change" back or having multiple addresses with variable amounts to send are just awful. Let's keep making things simpler not take 10 steps in the wrong direction.

Isn't that why credit cards have chargebacks, and the associated fees? I think Bitcoin can be much more competitive if you don't copy that part of the credit card system.

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.

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.

The point I was trying to make is the "your hardware vs. mine" is the barrier, not the "push vs. pull" aspect. If I have to bring $200+ worth of hardware (smartphone/tablet/laptop) with me, make sure it's charged, has WiFi/3G configured properly, and has the right software already installed, that's a lot more prep work than "put a plastic card in your pocket". Also, it allows an easier introduction to Bitcoin; if you gift someone a piece of plastic and tell them they can use it as these local establishments just like a debit card, that's all they need to know to start using it.

The Square customer app might be a good solution, though it sounds like Square still is the middleman and handles the charging of the accounts? In order for that to work with a Bitcoin address, Startbucks would need to have the ability to have a Bitcoin address on file (either presented along with the "You owe me N BTC" broadcast, or saved with Square, so when you make the final "yes, I agree to pay this", Square knows where the money goes), and either the client app on your phone or the Square server needs to know how to transfer funds from/to a Bitcoin address. Does Square have a developer API for writing custom client apps, or plugins to their client app to add that processing logic? I wasn't finding anything initially on that vein.

Is it really so daunting? I've done it a bunch of times, push vs pull is hardly that weird, especially given that outside the USA the standard model is "insert card, confirm transaction on screen, enter pin, press enter" ... ie you are conceptually pushing money to the merchant, albeit with their hardware.

For brick and mortar shops I think the best way to go, long term, is do what Square have pioneered and allow trusted merchants to just automatically tell your phone via wifi/bluetooth to pay them money, and as long as the transaction is for less than a certain amount your phone automatically pays them. The idea is that, you know, Starbucks isn't going to rip you off by charging you for a latte if you didn't actually order one, because their brand is worth so much more than that. So they can broadcast a request to any listening device that says "I am Starbucks and who are you?" then your phone sends them your photo and a nickname (Mike or Mike H or SomeDude or whatever), and the barista sees that on screen. So they push your name/face, enter the amount they want, press OK and the request is sent to your phone which then says "Yep Starbucks is in my good books, payment sent". You never even have to take the phone out of your pocket.

The payment protocol work being done right now lays the foundation for this kind of thing, for users who want it.

Currently, to purchase something with Bitcoins in a local brick-and-mortar store, the merchant usually has a sign with a QR code on it which is their receiving address. It's then the buyer's responsibility to have a smartphone/tablet/whatnot that can scan that QR code and generate the transaction to pay. Conversely, paying with credit/debit card, the buyer only has to present their unique identifier (account number) and it's the merchant's responsibility to have the cash register/POS technology to generate the transaction. While the number of smartphone users is increasing, that reversal of roles as to who generates the transaction is a little daunting to those used to paying with credit/debit cards.

So can that be reversed for Bitcoins? Right now instead of having the merchant show their public address to be paid, the buyer could present a QR code of a private key to the merchant, and the merchant could have a "cash register" app that uses that Private Key to generate a transaction to the merchant's account. The buyer would have to trust the cash register app to not hang on to the private key long-term, and not create additional transactions beyond what's agreed upon, but that's what we as buyers do every time we use a POS device for a normal credit card.

The issue is the handling of a printed QR code with a private key on it. If the shop has security cameras (or an enterprising paparazzi with a massive telephoto zoom is lurking nearby), a recorded photo of your private key QR is now in the hands of people you may not trust, which effectively means many more people got access to your Private Key than you intended.

How can this be solved? I had a few ideas:

• conductive ink: With the rise of touch-screen tablets, there's a few vendors out there who are starting to market physical items you purchase that interact with your digital app. Monsterology by Nuko is one example: You buy physical cards that have visible ink showing information about that particular critter, but there's additional, invisible, conductive ink on top of that (presumably using TouchCode technology) that the touch-sensitive devices can decode and read the unique ID of the card being presented. So using visible ink, print the Public Key on a piece of plastic, and with conductive ink, encode the private key on top of it. Then a tablet/phone app can be written to interpret the key without broadcasting it.
  
• invisible ink: There are some inks that are visible (opaque) in the infrared spectrum, but transparent in the visible spectrum. Most cameras can see infrared, but filter it out; if the merchant had a modified webcam to record only in the infrared, the private key QR code could be printed in invisible ink on a blank back of a bitcoin credit card, which would prevent others from casually observing it. However, that enterprising paparazzi could also modify their camera to record in infrared and still grab your private key.
  
• mag stripe encoded: This is the way normal credit cards do it, so would feel very familiar to users. However the issue becomes decoding it. Mag-stripe-scanning hardware addons for smartphones are starting to emerge (like the Square scanner), but those have proprietary apps associated with them, which are tailored toward Credit Cards, and not customized cards. I know in major US retail stores, some have their own "in-store credit cards" that aren't Mastercard/Visa-affiliated (you can only use them in that store), but the POS (point-of-sale) scanners in that store know the difference and can handle normal mastercard/visa cards and the special in-store ones.
  

It seems that the conductive ink or mag-stripe encoding would be the best solutions, if they could be implemented, which is where I'm stuck, and wondering if there's anyone here who knows more. The TouchCode website gives information about the features of their product, but no pricing or technology specifications. I might just email them for some introductory information, to see what they would offer. If there was a third party who did the printing of private keys onto the cards, there would have to be a degree of trust there that they don't keep a record of the keys after they leave their factory.

For mag-stripe encoding, you can buy devices to encode whatever you want on a mag-stripe, but I'm lost in finding resources for implementing a new type of financial card. How do retailers implement an in-store credit card for their POS devices? What programming language/certificates need to be used to load a new type of financial card on a POS device? For mobile scanners, I found a few threads (here and here), which point to a few vendors that have API access to their hardware, but most are still focused on standard credit cards and handling the payment for you as a credit transaction, and give you the data off the card assuming it's in standard financial card (ISO/IEC 7813) formatted. Is there a reader out there that reads all three tracks off a magnetic-stripe card, and gives you the raw characters encoded in it (or even the raw binary; since mag-stripes are encoded in bar-code like "bands" of on-off)?

To me either of these two implementations have the most promise for getting Bitcoin payments more easily handled for day-to-day transactions. Anyone else have thoughts on this?