[Pre-Announce] OpenPay, use your bitcoins at any merchant that takes Visa!

[isis]

As I posted in the original announcement in "offtopic" here
https://bitcointalk.org/index.php?topic=88073.0

I've been asked by a client (Who makes POS software) to find a way to enable BTC transactions at the POS.
At present I'm working on getting the documents for the proposal into a publish ready state, which is itself a fairly big job.

The system will require some momentum to become adopted and I would like to ask the assistance of the community in spreading the word as it comes to life.  That's why I'm going to give the readers digest version of it here.

The crux of the concept I'm tentatively calling OpenPay (because it sounded like a good name), is to form a bridge from the online world of the bitcoin ecosystem, to the offline world of daily transactions.

When complete, you'll be able to spend your bitcoins directly (no intermediary organization is necessary) at any merchant, POS, ATM, gas station etc that takes Visa or Mastercard.

It's a card based system that will utilize an EMV compatible payment card (you probably already have one of these, it's sitting in your wallet or purse right now).

For OpenPay purposes the card will contain an encrypted private key (crafted in such a way that it matches track 2 requirements)
A 4 to 10 digit PIN would be set by you and would be the decryption key.  A standard wallet id would also be stored on the card for loading & refunding purposes.  For daily spends you would be able to handle the loading of the card through standard bitcoin means, or buy coins from your friendly neighborhood merchant.
 
Due to economies of scale, It's unlikely that people would want to purchase their own cards and all the bits and pieces to get it into a "ready to spend" state.  But cost issues aside, there is no real reason why you couldn't.  The cards themselves (any EMV compatible card) are between $15-$20 on the open market and the readers are about $100, but after that you really are your own bank.

It makes sense that card issuers would crop up around this, my planning anticipates that the primary issuers would be existing exchanges and banks that deal in BTC.

I will explain in more depth in another posting about the intermediate steps that occur, but in a nutshell the private key & wallet file are read by the acquiring software (same process as an import), which will then determine the balance, string together a standard bitcoin transaction, sign it and send it off to the network for completion.  (either the merchant will be running their own node, or their payment processor will be running one).

The plan also makes provisions for the merchant who desires to allow their customers to spend BTC, but who themselves needs to receive payment in local currency.  This will be a software setting of the reference implementation of the acquiring server, but would require the merchant to have an account with a company that provides exchange services, so they could run a daily settlement.  Again I'll go into greater depth on this in a few days.

That's the jist of it.  I'll be providing more details in later postings on the subject and will be posting all future developments in this thread, so please feel free to bookmark it.

[1714111137]

1714111137

[rjk]

Is the PIN encryption combined with some kind of provider based encryption, or is it standalone? If someone obtained the track data from a malicious POS or some other method, would it still be hard to bruteforce the private keys?

[DeathAndTaxes]

I will explain in more depth in another posting about the intermediate steps that occur, but in a nutshell the private key & wallet file are read by the acquiring software (same process as an import), which will then determine the balance, string together a standard bitcoin transaction, sign it and send it off to the network for completion.  (either the merchant will be running their own node, or their payment processor will be running one).

Wait what?  Why use a smartcard then?  If both the pin and private key will be given to the merchant then the merchant can create any tx they like.

Buy a 0.3 BTC hotdog get home and find out 500 BTC tx was made emptying your wallet.   Oops.

[isis]

You know those are exactly the types of questions I need to have people asking.

There are various modes of operation available in the EMV standard, the two we are interested in are mag stripe (swipe), and chip & pin.

Magstripe is primary in the United States and that's why I made a provision for it in the design.  It's also going to be the biggest pain to implement (It will require convincing ISO/ANSI to issue us an IIN among other things) and also represents the highest security threat to your wallet since the encrypted private key along with the key to decrypt it MUST be divulged to enable the transaction to process.

Chip and PIN is much easier to deal with, this is because we can do the whole thing "on card" and never divulge the private key.  All we really need to have is a list of the transactions that the card has been involved in.  Since we cannot store the entire blockchain in the available space of the card, we can just ask the gateway for a list of transactions involving the wallet which have occured since the last time the card was used. The card itself can then craft & sign the transaction based on this information.  Once old transactions have been completely spent, the card can delete them from it's memory. (Premature tearing is likely to be a significant problem here)

Chip and PIN also opens up a third option I'm exploring. That option would be a constantly changing PIN sent to your cellphone each time you use the card, but that will require infrastructure that isn't in place and can't be put into place without significant adoption of the Chip & PIN version of OpenPay.  It would be trivial to implement once we get past certain hurdles, but requires externalities & some centralized processing and identity management.

Nevertheless, under either scenario it's best to understand that this is meant as a "spending wallet", you shouldn't leave it laying about, and you shouldn't keep more funds in it than you can afford to lose.  You keep your local currency in a bank, and only carry cash on you when you need to spend it.  An OpenPay card should be thought of the same way, only load it with the funds you need for right now (a day, a week whatever) and leave the rest in your bank (even if the bank is just an offline bitcoin wallet somewhere).

Bitcoin is irreversible just like cash, and the purpose of this whole exercise it to allow you to take it offline and spend it at your local merchant, like cash.  If you would trust this merchant with your cash or credit card, you'll be able to trust them with your OpenPay card.

[DeathAndTaxes]

Bitcoin is irreversible just like cash, and the purpose of this whole exercise it to allow you to take it offline and spend it at your local merchant, like cash.  If you would trust this merchant with your cash or credit card, you'll be able to trust them with your OpenPay card.

That is a bad analogy. 


I have $1000 cash. I pay merchant for hotdog with a $5 bill my max loss is limited $5 - value of hot dog.
If I pay with cash I only need to trust the merchant until I get change.

I have 200 BTC on my card.  I pay a merchant for hotdog  and my max loss is the entire wallet.  Not just the current wallet value but any value it may have at any point in the future.
If I give merchant my private key I must trust him FOREVER.   Hell Merchant could just record private keys as a rainyday fund.  When he runs into financial trouble he robs 10,000 customers instantly.  Due to the nature of Bitcoin once 2+ parties have the private key proving who made a tx becomes impossible. 

[isis]

Bitcoin is irreversible just like cash, and the purpose of this whole exercise it to allow you to take it offline and spend it at your local merchant, like cash.  If you would trust this merchant with your cash or credit card, you'll be able to trust them with your OpenPay card.

That is a bad analogy. 


I have $1000 cash. I pay merchant for hotdog with a $5 bill my max loss is limited $5 - value of hot dog.
If I pay with cash I only need to trust the merchant until I get change.

I have 200 BTC on my card.  I pay a merchant for hotdog  and my max loss is the entire wallet.  Not just the current wallet value but any value it may have at any point in the future.
If I give merchant my private key I must trust him FOREVER.   Hell Merchant could just record private keys as a rainyday fund.  When he runs into financial trouble he robs 10,000 customers instantly.  Due to the nature of Bitcoin once 2+ parties have the private key proving who made a tx becomes impossible. 

You have a good point.  It's a critical flaw with the Magstripe system, although not for the Chip & PIN.

But you're assuming the wallet itself isn't throw away.   Also if you were to buy a hotdog from a vendor using a check, what's to stop him from reading the MICR line and saving that for a rainy day?  You have to change your account number stop that (at least that's what I had to do when I had it happen).  Once you find you've been "robbed", you would just load a new key onto the stripe and get on with life.  Again, we are talking spending money not life savings.  Keep your big funds separate from your spending money.

With the Chip & PIN mode (which is what I'm advocating folks use whenever possible), you don't have this vulnerability since the PIN pad doesn't read anything from the card.  The pin pad just hands it an amount and a PIN code and gets back a transaction to pass on to the network, the card does all the heavy lifting.

Make sense?

[DeathAndTaxes]

Yes I understand I was just pointing you that any system where you give the private to the merchant and hope for the best is likely doomed.  Chip & Pin is completely different IF the entire transaction signing can be done in chip.  Having worked w/ smart cards that is somewhat difficult.  Still not sold on the advnatage of a chip+pin system vs smartphone especially as smartphones gain NFC.

If a merchant steals my checking account # I am not liable.  The bank is.  A check is reversible tx for exactly that reason.  Bad analogies don't improve the futility of a system involving trusting a merchant.

I used my credit card about 12 times today maybe 100 times in the last week.  Under a system where I gave my private key to all those merchants,  say the "money just disappears".  Who took it?  The risk is not just the merchant but also ever disgruntled employee, every modified terminal with a skimmer, etc.     It basically comes down to "trust the entire world" to not rob you despite the fact that they can do so trivially and anonymously at any point in the future.

POS system where customers card produced signed tx = valuable, maybe the killer app for Bitcoin
POS system where customer blindly and stupidly hands private key to entire world = useless.

Combining the two things causes the weak solution to undermine the security of the strong solution.

[rjk]

If we assume that the magstripe card gets skimmed at some point, but the skimmer doesn't grab the PIN, what's to prevent him from bruteforcing it? If it's limited to digits 0-9, 10 characters is a cinch to crack. Is there any other protection?

[isis]

If we assume that the magstripe card gets skimmed at some point, but the skimmer doesn't grab the PIN, what's to prevent him from bruteforcing it? If it's limited to digits 0-9, 10 characters is a cinch to crack. Is there any other protection?

No not at the moment, but I am definitely open to suggestions on it.
The whole purpose of mag stripe is to allow existing merchants that don't have chip & pin to still process the transaction.

The only real solution that I can see is to limit the amount of money on the card to reduce the potential for damages.  However like I said that's not a complete solution.  The only other solution I see is a revocation mechanism that I have been working on, but I'm having difficulty finding a way to implement it without a central body.

I can go into details on it if you like, it's certainly better than the merchant having the actual key though.  The big drawback is it would require either a change to the way bitcoin operates, or a body of some sort to track & revoke what's encoded on the mag stripe.

[rjk]

Well you could try to band-aid the current system by restricting it to specific POS devices and educating consumers about where not to swipe their cards,.... but I don't like that.

Additionally, consumers are unlikely to switch quickly or easily over to a chip&pin system either. Although Canada has chip&pin literally everywhere, consumers in the US have been known to microwave and hole-punch the chips out of their cards, because of their latent paranoia about "the system".

[Elwar]

My wife's store accepts Visa.

She has a card swiper connected to her laptop. She logs into a webpage that has the credit card transaction set up. She swipes their card and it fills in all of the card information. She types in the price and submits it. It then prints out a receipt.

Will your system work with this?

(though she can already accept Bitcoin payments via her smartphone, but just curious)

[isis]

My wife's store accepts Visa.

She has a card swiper connected to her laptop. She logs into a webpage that has the credit card transaction set up. She swipes their card and it fills in all of the card information. She types in the price and submits it. It then prints out a receipt.

Will your system work with this?

(though she can already accept Bitcoin payments via her smartphone, but just curious)

Eventually yes, but at the start probably not.  The point of the mag swipe is to allow exactly that.  What will happen in the scenario you describe is that the merchant processor (not the merchant themselves) will handle the processing over the bitcoin network and we will be working with processors from the outset to allow this to become a reality. 

For the processor this is a matter of determining which network to run the transaction off from (hence the need for our own IIN).  For the merchant this should be as easy as telling their processor that they want to accept the card and have the processor enable it on their account, pretty much the same as if they wanted to accept AMEX, Discover etc.

Actually doing that would be a bit longer out though; it requires creating agreements with each processor to run transactions on the network, in addition to the overhead of adapting their systems to use it.  It's not insurmountable, and it is in the long range plan.  But the short term plan is to build momentum for the chip and pin system and give merchants a program to load on their POS/Pin Pad solution and some acquiring software to run the back office.  The hope being that after the installed base hits critical mass more processors will see the benefit of making it an integral part of their own systems (because the merchants will be asking for it).

[vv01f]

When complete, you'll be able to spend your bitcoins directly (no intermediary organization is necessary) at any merchant, POS, ATM, gas station etc that takes Visa or Mastercard.

sorry, really dont see that point in your description.

If it where to work pro bitcoin, your POS would have to accept (visa-)debt and pay bitcoin to some public key - which could be locked and verified in some way.
But certainly there is no reason to trust some POS with private keys  - thats the point with bitcoin. here the POS can earn trust.

Reverse for paying at shops where the trader accepts visa and we want to drop bitcoin, you'd offer a public key and connect it to some virtual visa and create advice as soon as your account sees the bitcoin-amount asked for. here the customers gain trust.

Chip and PIN is somewhat oldfashioned as we are used to that on creditcards, I miss the innovation.

I think it is really simple, but there cannot be any chargeback what makes it a hard business for your POS. They will need good inshurance and a good customer management with trust-levels allowing higher debts. Just take a closer look to what ppl already use to trade bitcoin.

Until now I did not find any (small) payments processor to take the risk, it would need a big player I think.
A main problem is, that the advice for the shop is wanted to be seen immediately. But to have some certainty bitcoin takes ~10min. There you might innovate things.

My point was to limit the usage to online-payments in the beginning. That would be natural. And as soon as the payment is confirmed  the delivering can be started. Thats how shops are used to it. As soon as customers have gained trust-levels they also can pay with the CC offline with reasonable amounts. Verifying the customer with some card is then still needed the same way it is for oldfashioned banking.

But nothing of this can be done without a central authority which comes in where your CC does.

/*break*/

innovative in my eyes would be a NFC-system "mailing" encrypted messages and handling "one time" private keys directly using some bitcoin-wallet. but thats much more than a smartcard.

[isis]

Ok let's back this discussion up just a little bit, I can see from some of the replies that folks are getting confused and it's starting to throw the discussion into disarray.

Step back a moment, open your wallet and look at your bank card.

You'll notice that it has several logos on it. 
One of those logos is likely to be Mastercard or Visa.
If you look on the back, you may see Plus, Interlink, Money Pass, paypass, blink etc.
I even have a card with "Green Dot" on the back.

What makes a mastercard a mastercard and not a visa is the network it runs off from.  It's also what makes an AMEX or Discover card what they are.

All these logos you see, they're just payment networks that your card is compatible with.

Bitcoin has a payment network as well, the problem is, there is at present no tie between the world of Bitcoin and the world of Visa/Master etc.

OpenPay (or whatever we decide to call it) would be exactly such a tie.
Regardless of what is on the card whether it be mag stripe, chip & pin, contactless NFC device, or magic pixie dust, the point still remains that the primary purpose is to allow offline spending of your BTC balance.

So that's the organizational aspect, first we find a way to get bitcoins circulating using the most painless methods possible.  Then we standardize those methods and try to get BTC flowing as widely as possible.

Now that's the organizational aspect let's look at the implementation.

After careful consideration I've decided that the way I was discussing magstripe is in fact the wrong way of doing it. 

Pull that bank card out and look at it again.  You'll notice that it starts with a 4 or a 5 and has a total of 16 digits.
The first 6 digits are what is known as an Issuer Identification Number (IIN).  It let's the merchant's payment processor know which network to communicate with to process the transaction. 

OpenPay would need to have it's own IIN because it really is it's own network playing by the rules of bitcoin rather than the rules of Visa or Mastercard. 

Even though it might look a lot like a Visa or Mastercard, the transaction would actually run over a wholly separate network, just like AMEX or Discover. 

Where I made my mistake was in assuming that the card would essentially be disposable if compromised. 
That just wouldn't be the case, so putting the private key into the magstripe (encrypted or otherwise) would be a bad idea. 
But after careful consideration I think I may have found a better way.

For instance let's imagine we have a card with the number 9123 - 4544 - 4112 - 3456 - 7890
The first 6 digits (912345) would be the IIN (Network ID) given to OpenPay by ISO.
The next 4 digits would be a routing code to the network, pointing to actual card issuer.
The remaining digits would be an individual account identifier that the issuer could use to tie the account.

Now before anyone complains about central control, realize that this is possible without any central authority other than a community owned body to pay the fee for the IIN which would be a requirement for any magstripe scenario.
 
The 4 digit routing code would have both reserved and public ranges, just like IP addresses do.  My recommendation is to allow any 4 digit repeating sequence 0000 ... 9999 etc to imply self issue. 

Other ranges could be sold to business issuers like banks, exchanges, mining pools.  These "centrally" issued ranges could be treated like green addresses are now.

Finally, the issue range database would be contained within bitcoin itself.  Just a microspend with a message attached "I'm wallet x and I own cardnumber y" (This is to prevent double issue).  We could take this a step further and allow a card revocation message for when a card gets lost or stolen.  This would free available card numbers over time.

Now let's look at how this all comes together.
Bob has a bitcoin denominated OpenPay card and goes to his local gas station for a drink and a bag of chips.
His total is USD $1.99.
He swipes his card, is prompted for a PIN, waits a few seconds and then is on his way home.

Under the covers as soon as he swiped his card the card reader determined from the IIN that this is actually an OpenPay card.
This triggered the merchant's payment processing software to load up the OpenPay connector which told the bitcoin deamon to send itself 0.01BTC with a message along the lines of "Please send $1.99 * USD/BTC rate, from $cardnumber to $merchant wallet."

Upon seeing that message, Bob's bitcoin wallet (with an OpenPay extension) possibly sitting at home on his computer or even running on his phone, picked a random number and sent a message to his phone.  This is what Bob ended up putting into the pin pad.

After Bob entered the number into the pin pad, the merchant's software sends itself 0.01BTC again, with the exact same message except the disposable pin is now appended. 

Bob's wallet sees the request with PIN attached and sends the transaction off as the merchant requested.

If per chance Bob had a non-self issued card, then the process could be much faster since the routing portion of the card would indicate the funds are coming from a "green address".  Also with a non-self issued card Bob would not need to have a wallet running at home, or on his phone, it would all be taken care of by whomever he has his account with.

Anyways, that's my new suggestion for magstripe.  I think the EMV chip & pin option is the way to go long term, but at least in the USA we've had a tendency to be resistant to changes like that so it could slow adoption.  What I'm proposing here would require nothing on the part of the merchant other than a single software install (and a BTC/USD exchange somewhere if they wanted to get USD at end of day).

[Deafboy]

isis, I like the creative solution to the security problem, but do you realize how many pieces of hardware are involved in the process?
You phone has to be able to receive SMS, and if you have self-issued card, you have to run bitcoind and ensure it's up and connected to network yourself.
I hate "Why don't you just use android wallet?" kind of arguments, but really... why don't you?

[vv01f]

because he wants to use the card-systems in shops.. but i doubt its that easy. in my country the systems are not that much in use as in the us, but a shop-owner decides which systems (aka networks, such as ec, visa, mastercard, amex ..) he supports on basis of his customers needs and will not be happy puchasing another service/network-api.

also the time/delay-issue isnt dealt with - transactions are instant most of the time, but they take their time - aproximately 10min/block. so still aproximateley 1 hour to complete. it could take longer.

[marcus_of_augustus]

So will any of this be Open Source?

Seeing as it is called OpenPay ... and the brain-storming seems to be free-to-air .... just wondering.

[isis]

So will any of this be Open Source?

Seeing as it is called OpenPay ... and the brain-storming seems to be free-to-air .... just wondering.

Yes

[isis]

because he wants to use the card-systems in shops.. but i doubt its that easy. in my country the systems are not that much in use as in the us, but a shop-owner decides which systems (aka networks, such as ec, visa, mastercard, amex ..) he supports on basis of his customers needs and will not be happy puchasing another service/network-api.

also the time/delay-issue isnt dealt with - transactions are instant most of the time, but they take their time - aproximately 10min/block. so still aproximateley 1 hour to complete. it could take longer.

In the USA, which cards you accept are also driven by your customers wants & needs.  A merchant selects which card networks they want to support based on his/her desire to service certain classes of customers and signs a merchant agreement with a payment processor.  The payment processors job is to handle all the details of credit card processing, however no matter which processing networks are used the hardware, card reader, pin pad etc are all basically the same.

A large part of my point is that if we want Bitcoin to gain broader acceptance we need to implement a solution that leverages that existing infrastructure to the degree possible.  Yes there are a lot of moving parts, but that's true of any payment processing mechanism.

As for the time delay, that's only true for the payment to become confirmed by the network, not the amount of time it takes for confirmation that a payment is on it's way.  Especially with the green address blocks (centrally issued cards) it's generally safe to allow the transaction to proceed without any delay.  We could probably speed it up a bit with a request/response callback mechanism.  Wallet X please call Wallet Y at IPx.x.x.x. re: tran-xyzpdq.

[Elwar]

Good concept.

Could the PIN portion of it not be solved by using multisig?

Merchant sends a message to send .42 BTC to XYZ address. The client receives the request and attempts the transaction. The multisig transaction is attempted and awaits the second sig method before it finalizes the transaction.



Some side suggestions of other ideas I had that would apply here.


I had previously suggested something similar to a domain name server but for Bitcoin addresses. Instead of saying "Send the BTC to 1X8JS8SXM42A9W4AJOWQ4262PEW" you would say "Send the BTC to elwarsspendingwallet2012". You could take this concept and have a number DNS setup.


And secondly, the concept of award points. A merchant accepting BTC could pay 1% of each transaction toward a reward program that is tied to the spending address. This would be geared toward people who do not use Bitcoin but would be willing to use it in order to get better rewards than the other cards.