Bitcoin Forum

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 (http://www.nukotoys.com/games/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 (http://www.techlicious.com/blog/apps-that-use-real-world-trading-cards/) using TouchCode (http://www.touchcode.de/index.html) 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 (https://squareup.com/register)), 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 (http://forum.xda-developers.com/showthread.php?t=797419) and here (http://stackoverflow.com/questions/4674197/is-there-a-credit-card-reader-for-the-iphone-that-has-its-own-api)), 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?

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.

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.

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.

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 (https://en.wikipedia.org/wiki/Maestro_%28debit_card%29) 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.

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.

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.


 

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

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,

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 (http://en.wikipedia.org/wiki/EMV#EMV_commands) 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.

Can you explain to me why decentralization would be necessary for a service like this?

The fees are not for profit. They are the minimum required to maintain the integrity of the service being offered at no cost to users. Merchant transaction fees are hardly the issue here, it's the monopolies credit card companies have over all digital transactions be they at POS or online.

You said it yourself, it's a new currency. It's not a payment processor, nor was it meant to replace them. Credit card companies didn't appear from nowhere, they came about when it started becoming more convenient to carry a plastic card than fragile paper currency.

Decentralization is not necessary for the process you've described. Quite the opposite, actually; it needs centralization to work, focused on one or few central banking authorities. The point I was trying to make regarding decentralization is that Bitcoin is based on principles of decentralization, so solutions that move it toward centralization go counter to that fundamental belief, and probably wouldn't be as readily adopted. Yes, the fees by a central banking authority could be just enough to break even, but if there's only one bitcoin central processor, they're not really competing with the standard credit card processors, so is still pretty close to a monopoly, and could charge whatever they want.

So, while there's several good ideas out there, the crux of the matter is still how to get additional logic on handling Bitcoins into the equipment that retail stores have. I've never opened a brick and mortar store, so who supplies stores with the POS credit card scanners? What OS/programming language are they running? Do the manufacturers of those POS devices have developer programs to submit new payment methods?

Does anyone out there have experience implementing a custom in-store credit card or loyalty card system with a standard retail setup? I know those exist already, and I hope they have the potential to be a way Bitcoin logic can get inserted in.

I got a system that works with Card readers and so forth, the problem is most card readers are 2 or 3 track, Visa,MC and AMX.
Getting a merchant to buy/rent give them another card reader is hard. One of our projects is geting a card writer and programming some cards, our software allows us to issue and accept "cards" The card can be used for whatever currency you have in your account we currently will be supporting USD, BTC and LTC.
http://www.youtube.com/watch?v=QyK9kdEgxCA&feature=youtu.be

We are low on capital and it is kinda holding up projects like this but that video is quick vid sorry for the incomplete and lack of editing.

Hmm I don't see this being to much of a problem the store has to have some really high tech cameras. I'm not sure if you've seen recordings of store footage, but honestly I don't know how they catch robbers with them, let alone read a ton of small black boxes.

The camera will also have to be directly above where your phone is read, no glare, good angles etc.

Sorry if this isn't what you mean.. Because every time I do a sale in person with bitcoins, they log into their blockchain.info account, I log in mine, a QR code is scanned, and coins are transferred.
I have not done a ton of trades like this and its been a good while a month and half or so.. But if I recall, the customer scans my QR code? I don't get to see any of their data.



The only flaw.. Is the fact that the customer can change the amount to be sent.

Yes, that's the "normal" transaction method at the moment. The QR codes being scanned are relaying the public Bitcoin address(es). What I'm proposing is some way to relay the private key, such that the customer doesn't need to have a phone on them to make a purchase (the flaw I want to fix is that I as the consumer need to bring my hardware to make a purchase).

Whats wrong with a plastic card?

Just use a plastic card with a credit card style number on it, and a pin

You give this to the retailer who reads it with their standard card reader.

The details get sent to the payment gateway, and that does the hard work through the likes of bitpay who do a deal with streamline or whoever does the credit card payment services in your region.

The retailer get their confirmation and money minus charges.

Happy customer!

Opps, have I just broken a taboo? ;)

The problem with the ideology of wanting total independence from the banks is that without them, you don't get any customers either - Yes, you could bring your own hardware, but its just too much for a retailer to worry about.  To get the service into the shop, you must go through the payment gateway company who are already there.  Don't worry there are a few of them, unfortunately, they are mostly banks or closely connected with them.

Rather than reinvent the wheel - again - why not work with the likes of bitpay to make them the byword for bitcoin in stores?

Just my 0.002 btc

Did you watch the video I posted? You described everything that it doeslol

Thank you, this is exactly what I have been saying. We don't have to restructure society altogether. Some things work well, like carrying around a plastic card instead of something with "real" value that can be lost or stolen.

Tipped +.002 btc

Thanks :)

Exactly. If/when bitcoin (or a successor) takes off big-time it will be enabled by a network of complementary services. The idea that the average retail customer will interact directly with the core bitcoin network, with the associated pain of wallet management, transaction absolute finality (ie no chargeback, aka consumer protections) and the rest, strikes me as ludicrous. In time, it will come to be seen as "just another currency", adopted because of its primary benefit of predictable money-supply growth. The bitcoin network will be the currency's (near)RTGS. The world's financial plumbing system (visa, CLS, SWIFT, whatever) will require little more than trivial tweaks to support it (primarily, links to the bitcoin core network for gross settlement transactions). If this prediction is true then the world's POS devices can already support bitcoin with next-to-no effort.

Looking at this practically, lets say you have a plastic debit card which links to an online wallet.

Load up your debit card from your local fiat currency, and pay your bills in bitcoins (or alt coins) and you only have to swap back to fiat when you want to (and get charged for the pleasure).

The retailer can choose to get paid into a bitcoin account, or into a their standard payment gateway account.

The next stage of the bitcoin story is that the public need to know why they would want it.

To me, the advantages of bitcoin to the public are that its inflation proof and it can be used internationally both in person or online without having to worry about forex charges.

That would tend to suggest that the natural market for bitcoin to start with are business people with international companies.  Therefore, if you want to get to them, how about creating a debit card for expense accounts?

Think of it like an AmEx card - exclusive and desirable, with real benefits that financially astute people understand. Get them to buy into using such a card, and slowly, bitcoins will work its way down the food chain to Wall Mart! ;)

Maybe the trick is to talk to a card provider who deal with these types of clients?

Trying to make deals with the current payment processors, and convince them to reprogram devices to accept Bitcoin would be an incredibly wasteful and expensive undertaking. More headaches then necessary and the whole point is to break away from the current system.

Thankfully credit and debit card terminals are a very simple technology, it would not be difficult to produce a more cost efficient device geared towards Bitcoin. The only problem is getting merchants to adapt it like you said. There needs to be a reason why they personally would want to accept and hold bitcoin before you convince them to invest in a bitcoin terminal.

If they'll be going through the hassle of converting back to fiat anyways, why bother.

What about doing it in stages? For example a MtGox card that throws cashback into your MtGox account.

Thats why our system give the merchant the option at the time of taking LTC, USD or BTC.

The system could focus on accepting BTC, but the payment processor would offer to buy those bitcoin from the merchant immediately. The only addition would be logging the exchange price for each transaction to properly reimburse the merchant at the end of the day/payment cycle.

Having a card with some number other than the private key on it is a possibility, and would work well with the existing credit card financial market, but the downside is the centralization. In order to get a "bitcoin credit card" in that case, I have to open an account with the BitcoinInv or whoever is offering the service. That central authority now has my wallet file, and I have to transfer funds to my account there. Then, the situation is like I described; I only need to bring my card with my BitcoinInv account number on it with me to the store, and use their POS system to make the purchase from my account. However, that centralization now means BitcoinInv becomes a honeypot for thieves. If someone can get in and crack whatever security is behind all the wallet files there, they can walk away with funds from (potentially) anyone who has an account there (depending on the security measures in place).

Having the private key on the card itself, and if the POS system were independently-verifiable to not keep those private keys after being used, there's no central location for a thief to hit to steal all the customer's money.

So, yes, I'd like to see something like the process you're working on come to be, BitcoinInv, but in order to make it work, whatever agency becomes that central point needs to be big enough to be the central processing point, have the servers be reliable enough to handle lots of load, and have ironclad security. That, I believe, is a bigger hurdle than reprogramming a POS card scanner to understand the account number coming in isn't a credit-card-style number of five groups of four numbers, but a string of hex or base-58 characters, no?

I agree! The issue, however, is the "If/when". Currently the credit-card infrastructure has assurances like the FDIC and whatnot that make me the consumer feel okay handing my credit card to a waiter to go do something a back room with (presumably charge me for my dinner and nothing more). Getting to that point is a great long-term goal, but to start with, but there's no one big enough yet to be the strong arm that cracks down on Bitcoin fraud and insures other central processors if they get robbed. So the power needs to stay with the consumers; I'd just like to see it make the step away from owning a smartphone to be the barrier to entry in the day-to-day transactions with Bitcoin.

Until the day that there's an agency that insures other central bitcoin processors against theft, I won't be keeping any large amounts of coins in online accounts such as the one you're describing, BitcoinInv. But still keeping pocket change there for day-to-day expenses would be quite convenient, and I would take advantage of that.

Plastic cards are fine for me.

But why do the POS terminals need to change to support this?

Today, I can take a credit card that understands only GBP to Spain and purchase an item denominated in Euros from a shop.  I need to look-up where in the network the conversion from EUR to GBP takes place, but I can guarantee it's not in the POS device or at the retailer.   I'm pretty sure it's done at the issuer end, or at worst, by the switch.

The point is: this means that to support Bitcoin today, the only part of the *existing* infrastructure that would need to change would be between the switch and an issuer, in the worst case... and that would just be limited to adding support for an additional currency code.

The risk management could be entirely the purview of the issuer.

I guess my underlying point is: nobody expects retailers to accept more than one (or perhaps) two currencies today - why would we expect them to accept another one in the future?  Sure - a Bitcoin-only subeconomy would be interesting, but is it realistic?

If Bitcoin was recognized as a currency, and major banks/credit card vendors accepted it as just another currency that could be converted to, yes, that would allow existing credit cards to be used as they normally are. However, that also strips Bitcoin of its decentralization, and its anonymity (Ever think a big bank will let you open a BTC-only account with no ID?).

Right now, Bitcoin isn't recognized as a currency. As it is, it could be compared to various "rewards points" programs retailers have. Retailers may only accept a few currencies, but the number of types of plastic cards they can scan is many, for many purposes (paying for the purchase, adding rewards points, adding coupons, etc.). The "rewards points" accounts are more local than an international currency exchange, and I believe would therefore require less infrastructure to be built. While we're waiting for Visa itself to recognize Bitcoin as a currency, a smaller stepping stone could be to do it in a less-centralized way, as I'm suggesting.

Midnightlighting, just the same as you would never walk around with your bankroll in your wallet, there's no logical reason to store anything more than a few days worth of spending in a bank account to fund a debit card.

At the current value of a single bitcoin, there's little reason you should need to store more than a few in your bitcoin card's "hot wallet". You'll never be at risk of losing more than that and assuming a free service does arise, there could be optional fees to insure your deposits against theft.

If you're foolish enough to store your wealth someplace you're not personally in complete control over, well you're asking for an expensive lesson.

Right; with the current system, or any sort of "bitcoin debit card", that would be the case. And true of any gift card you have in the current banking system outside bitcoin; you wouldn't want to have a $5,000 Wal-Mart gift card in your pocket for the same security reasons.

Looks like someone with experience with the POS/credit system back-end has an idea: http://www.reddit.com/r/Bitcoin/comments/1ay1ew/bringing_bitcoin_to_brick_and_mortar_ie_the_debit/

The problem is this is where ideology meets technicallity,

I like the idea of having a bitcoin card or payment / app on a phone, but I do not like the centralisation and loss of anonyimity that goes with it,

Also I think merchants should accept more than one currency, competing currencies only bring prosperity and options to the users. I would like to think that if a merchant accepts my bitcoin cards they would like to use / hold the Btc and not have there EPOS convert it straight to fiat but I suppose that's there choice.


Just been thinking about it and I think its possible to implement a solution that would have the option of using both Cards with existing EPOS technologies and a phone app, both the merchant and customer would have to make use of online wallets but this presents its own disadvantages.

It would be ideal if their was an out of the box software solution that can be installed on any webserver by any n00b that would have a listening API say over https and it interfaced with the bitcoind, so it listened for merchants requesting payments that originated from its assigned customer(s), (so it could be a personal payment processor just for you or it could be for a group of people), the webserver API would respond with a challenge request for a pin number or password then it would send funds to the appropriate merchand webserver API / address,

If somehow you could make this software so that it could be tamper proof it would not have to rely on the blockchain and could verify transactions with the blockchain in its own time, the customer and merchant web based software could trust each other and know that it is not initiating double spends and what not.


Or we should just switch to litecoin and use its daemon and blockchain directly, as the faster confirm times make it more feasable.

I think I'm reinventing the wheel, Think its time for sleep.





 

That's sounding close to what BitcoinINV posted that they were working on: http://youtu.be/QyK9kdEgxCA.

If "any webserver" could get this software installed on it, then in theory every merchant has their own instance, which allows for decentralization, right? I've been suggesting modifying the POS devices, since they already have to be internet-connected (to process the credit card transactions), and most merchants already have one. For a merchant that's changing over to using an iPad for checkout (like Square encourages), or smaller mobile device (like Apple stores do), just having some webserver out there able to be contacted by those check-out devices would work swell.

I was thinking about buying a NFC writer and some tags and seeing if I could make some magic happen. How hard is it to program them things?

Encoding an NFC tag? Not too hard; I believe there's standard libraries for doing so in most languages. I've played with several NFC apps on my phone, most of which give you the ability to write content to a tag, so it can't be that hard. The basic NFC tags hold 144 bytes of data, which would be enough for an account number at least. There are (slightly) more expensive ones that hold 1,000 bytes, if more space is needed to hold an encrypted account value or more data.

From what I have gathered he doesn't posses any technical skill to create the service.

Ideas are a dime a dozen, I'm sure you've heard.

I must admit that I'm still struggling to understand the use case.

Life is complex enough for merchants as it is... the idea of implementing a parallel infrastructure for BTC, with its own idiosyncracies, qualities of service, staff training needs, consumer education, etc., strikes me as entirely unrealistic.

As discussed above, consumers already have the ability to *spend* using any currency they like (a GBP credit card works just fine for EUR purchases in Europe) so allowing consumers to *spend* using BTC would just require an issuer to support it and, perhaps for teh Visa/MC network to add support.   This is clearly feasible:  the Euro's introduction showed new currencies could be added and we can be sure the banks/networks have planned for its disintegration and the introduction of multiple successor currencies.

From a security/safety perspective, a BTC credit card would not have to be linked to anybody's wallet.... the user just needs to settle once a month using the BTC network or via an intermediary.  Similarly, a BTC debit card would just need to be linked to a wallet with a modest balance.

Now, somebody mentioned above that merchants might also want to *accept* BTCs, to avoid conversion to/from existing currencies.  I think that, too, is possible using the existing infrastructure... some merchants in tourist areas already allow consumers to select in which currency they pay (with the exchange rate often being unfavourable but that's another issue).  Now this may well require changes to POS devices... but an update to an existing system is easier to consume and easier for staff to understand than introduction of an entirely new parallel infrastructure.

So... given that adding full support for BTC to the existing payments infrastructure is achievable without too much technical effort, it strikes me that effort would be best spent overcoming the non-technical objections/blockers, rather than investing effort reinventing technical solutions that don't seem to be needed.... am I missing something?    Is the main problem that people don't like the fees imposed by Visa/MC?   Dislike of the idea of an intermediary? (i.e. a vision that all BTC users in the future will transact directly across the Blockchain?) Something else?

[Edited]

It would just need a number on it, when the person waves it in front of the reader it just fills in the blank for the card #. The pin would have to be inserted manually by the customer. I do not think my phone reads writes NFC :( stupid evo

My suggestion is that getting an issuer (like Visa/MC) to accept BTC as a currency is a monumental task that won't happen soon. And that solution centralizes the otherwise decentralized Bitcoin economy by funneling through the issuer (who can make whatever claims it wants to break down anonymity if you want to use that service). Which is why I'm searching for another solution.

The idea Is that If there is inefficiencies in the system in the form of middlemen then they should be eliminated, I dislike Visa & MC, they between them have a duopoly, they refused to process payments for wikileaks they are not your fiend. We have been given technology that liberates us from centralisation and now everybody wants to know how they pay their taxes or who they can use to store their bitcoins and why can't we use the normal payment systems, This is ridiculous if we do theses things then we might as well give up using bitcoin.

It's not that hard to enable customers to pay merchants in Btc and with a little bit of ingenuity and funding I think a system that makes use of most of the retailers existing EPOS devices could be found with maybe a small device that can be plugged in, if a company selling these devices also does Btc -> Fiat conversion I'm sure they could make enough to make these devices very cheap or even free for merchants. 

I can't speak for everyone, but I think nominal fees are the issue. If you're making a $1000 purchase, there is no reason that a ~2.75% fee (roughly $30) should be taken from the merchant to handle less than 1 kilobyte of data.

Ideally transaction fees would have a hard limit to prevent high charges for larger purchases. Another idea would be to allow merchants to set a fee based on when they prefer their money is deposited to a wallet. The highest fee (ex: 0.5%) would deposit sales into the merchant wallet immediately, with lower fees happening at lesser frequency for those who just don't need the bitcoin available right away.

There's no reason we should be working with VISA or MasterCard when we can make a superior service that they couldn't possibly compete with.

The way our merchant processing system is set up is to take .25% of every transaction. Here is the catch, you have to sign up for merchant processing via a broker. The broker can charge from .10% to 2% depending on how greedy they are. This makes it easy for us to expand business and put money back in the pockets of some bitcoin users.

Anyone can qualify to be a merchant broker, and we are accepting brokers for when our merchant system launches in the next month.

What requirements are there to being a merchant broker? Do we need a dedicated server, or a minimum capital?  do merchants take the risk of double spends then? Where can I sign up?

OK - so there's several things there then, right?

1) Belief/assertion that middlemen are bad.  Not sure I buy this... any system that can bring together two large groups of people (customers and merchants) is going to be valuable --- users of the system get value from the "middleman" service MC/Visa provide... it saves them having to worry about sorting out multilateral links/contracts/relationships, etc.

2) Claim that Visa/MC are anticompetitive / duopolostic.   I think this is probably accurate but also unavoidable... and it's hard to see how to fix it....   the card network business has huge scale efficiencies and network effects... a small number of large players is what you would expect to see.    This makes it really, really hard for small players to operate profitably.  Not sure how to fix it since it's a fundamental property of the market structure from what I can see

3) Ability to refuse some transactions.   This strikes me as a really good argument - they have this power as a result of 1) and 2) and it would strike me as being abusive....   as you suggest, however, it suits law enforcement bodies since it provides them with an easy way to stop transactions they don't like..... I just wonder if this would be enough to enable the creation of an entirely parallel network (especially one that would presumably also benefit from the effects of 1) and 2)!)

I'm not saying middlemen are necessarily bad, It's just that if we have middlemen that add no value then they should be done away with, in the UK we have a bloated service sector with everybody cutting hair or doing book-keeping, nobody is doing real work and this creates poor growth. Anyway MC and Visa add value in the current system because they facilitate customers transactions for money they hold in banks, they have massive overheads and lose vast sums of money to fraud. Now that bitcoin provides individuals with there own personal electronic bank account (in effect) We may not need these services in their current form.

As we are our own bankers we can send money to anybody else with a wallet or client, so the question is: not why do need to get rid of MC and Visa, rather it's: why do we need to keep them? (I'm thinking long term obviously).

The problem we have now with bitcoin is slow Transaction confirmations, even with the appropriate fee and transaction priority confirmations still take minutes, this is no good if you want to pay for fuel in a garage and have to wait around, Maybe MC & Visa types will find a business model in handling payments and taking the risk for the time between confirmations?

Exactly... that's my theory for how this will play out.

I see two possible future extremes:

1) Everybody has full access to the core Bitcoin network and every transaction is settled on the Blockchain,

2) Aggregators / net settlement providers spring up to provide "concentration" of transactions off-blockchain, with periodic net settlements across the blockchain.  Most "normal" users access the system through one of these entry points.  They may not even "know" their Bitcoin address.


Future 1) implies a need for massive increases in the scalability of the Bitcoin network and perhaps some rearchitecture to prevent the size of the Blockchain ballooning out of control.  It also implies a need for huge investment in retail-customer-friendly tools/technologies to deal with the lack of chargeback/customer protections/"compensation for your own stupid acts" that retail customers get (and expect) from their banks and card providers.     Entirely achievable - but it requires huge efforts along multiple dimensions (Bitcoin network, consumer education, POS infrastructure, etc, etc).    Note: without this, transaction fees will grow to the point that the only viable transactions are large ones in any case (i.e. micropayments would be unaffordable)

Future 2) is far more compatible with the world "as it is" today but dilutes several of the key benefits of Bitcoin (transaction finality, no need to trust a bank, anonymity (for some definition of that word), etc, etc)


My prediction: we'll end up with a hybrid system:  the rigor and strictness of the core Bitcoin network will prove too onerous for the average user and they will trade-off the BTC benefits for the convenience of Visa/MC/a bank/whatever for day-to-day use.  BUT... direct access to the Bitcoin network will provide the opportunity for a few (many?) people directly to store the bulk of their BTC holdings on the blockchain and not via a bank.

So you get the convenience of today's system for day-to-day low-value transactions whilst being able to hold savings/wealth on the chain.

Like I say, just a prediction..... but if true, it has implications for where we should be spending our efforts with respect to technology build-out, etc, etc.

No requirements, you get paid for the work you put in. The more merchants you sign up the more you make. No server is needed just a Verified account in our system. 0% chance of double spends if the purchase comes from a account inside of our system. If a payment is made to the listed address of course it will take longer to process and will not post to the merchants account from 1-12 hours depending on how fast I or support see's it pending.