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

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

[isis]

Hi Everyone,
I just wanted to post an update on the progress of OpenPay

Today I found out from several manufacturers that PIN pad programming is generally only dictated by the payment processor if the equipment is leased from them.

However most merchants in the USA purchase their own equipment.  Some of the higher end merchants pay for some serious customization, but for the most part all products within a product line run essentially the same software.

So in the long run, reprogramming them to recognize a new IIN won't require a lot of messing around with merchant processing companies who might take offense to not getting as big a cut of the transactional revenue.

On another note...

I've been trying to solve the magstripe issue all day and I think I have a solution, one that should work regardless of whether or not you have a cellphone.  It also allows you to self issue without purchasing any additional cards or equipment.

I just don't have the mathematical capacity at my disposal to determine whether or not this is a holy grail or a major security problem.
So help me figure this out folks.


I call this the "pick a card, any card method"
It should only require a series of simple modifications to any existing bitcoin client and for the merchants part all they need is a pin pad with a configurable alt-tender option on the front end then a fairly simple gateway program running on the backend.

Using this method you can enroll any card you already have as an "OpenPay" compatible payment card.
This means literally any card with a magstripe compliant to payment industry standards, including an old gift card from $ome_random_place.

It wouldn't even matter if it's expired,  

You would enroll by entering the numbers on the card into your OpenPay enabled bitcoin client.  
During enrollment you also choose a static pin number or numbers, the purpose being to set various daily spending limits,
Furthermore you could enable an SMS option similar to the one described earlier to set a PIN on the fly and allow multi-factor authenticated transactions to potentially bypass any spending limits.

Once enrolled the client generates a hash based on the card number, the expiration date and PIN (cardnumber is entered and hashed without it's IIN for security reasons).
This part serves as one half of a surrogate key that can be disposed of or unenrolled on demand.
I call that half "The enrollment ID".

After setup the client goes into listening mode...


Now you just go to any merchant that accepts OpenPay, swipe your enrolled card and select OpenPay as your tender type (instead of credit, debit, ebt etc).  

The pin pad would forward the card number and optionally the PIN to a specialized gateway application running somewhere on the merchant's local network.

The gateway application would take the card number, expiration date & pin (optional).
It would perform the same steps the client did during enrollment to generate the static half of the key.
Next it will also add the current timestamp (the other half of the key) and hash it to a valid bitcoin address.  
Finally it would send 0.01BTC to the address.  Along with payment instructions encoded some way in the scripsig.

Back home on the ranch...


The bitcoin client would be spending it's time scanning incoming transactions.
When it sees a new transaction it would look first at the scriptsig to see if it bears an OpenPay fingerprint.
If it does then it would add the timestamp of the transaction to each of it's enrollment IDs and generate new bitcoin addresses (enrollment addresses) in an attempt to determine if the transaction was intended for it, i.e. someone sent it some money.
If it sees that someone has sent it money, then it creates a new spend from the primary wallet based on the rules it's been given about spending limits etc and the instructions in the previous transaction, i.e. send BTC to the merchant if it doesn't exceed previous authorization limits.
Additionally it generates a second transaction using the enrolled key to send the 0.01BTC off to the OpenPay network to help pay for future development (or anywhere else the user chooses).

.....

Meanwhile back at the store, the gateway sees the new spend come in with the required information (probably some merchant unique transaction id) and notifies the pin pad & POS that the transaction is complete.

That's pretty much it except for multi factor authentication...

The SMS option I discussed in my previous posting is still interesting and I see it as a great way to bypass spending limits.  
Basically if the transaction matches without a PIN then the client would...
 
Create a temporary enrollment ID with a random numbered PIN.
Send a messaging containing the onetime use PIN to the user via SMS, email, smoke signal, or whatever method the user sets up in the client.

Once the PIN has been sent off the to user, then the client would send back the 0.01BTC with the message PIN_REQUIRED
This would tell the gateway to put the pin pad back into PIN acceptance mode and the user now enters the one time use PIN.

So that's the end of the "pick a card, any card" method.  I think it would be a great starting point for getting bitcoins into the real world.  The EMV enabled card is still in the works, but like I said before it would take a year or so to implement.

This option looks to be about 400 man hours of work (1 person 10 weeks, or 5 people 5 weeks) to implement.
Most of that (50%) is coding a new tender type for each of the dominate PIN pad models, 25% would be the gateway and another 25% would be modifications to the existing client.

Before I start implementing it though I'd like some feedback to see if I'm making any significant mistakes here.
My initial calculations showed that this could be vulnerable to both denial of service and brute force attacks (we know ahead of time the size of the static portion of the key (PINs will typically be 4 digits, cardnumber minus IIN is 10) and the remainder is a predictable and visible timestamp).
However neither of these are economically feasible if we enforce the minimum 0.01BTC initial spend to initiate a transaction at the OpenPay network level, and enforce daily & transactional spending limits within the client.

Other than that, this feels really solid to me, I'm not seeing any other vulnerabilities.

Anyways, thanks for taking the time to read this and I'm anxiously awaiting your feedback!

Thoughts?

[Elwar]

I like the idea of being able to use any card for the transaction. That would help with implementation by saying "want to skip the bank and credit card companies? run this app".

I was wondering if there would be a way to set up the software so that you just check for that card on the OpenPay network before checking the other (debit/credit) networks. That way you would not need to choose "OpenPay" when paying and it would be seamless for the user. And it would be compatible with all merchant machines that way.


Also, where is that initial .01 BTC sent from and whom to? From the merchant to the customer BTC client?

[Stephen Gornick]

Back home on the ranch...

Whose ranch?  The way I read it, the customer needs a bitcoin client continuously running back "at the ranch" to support delivering that customer's OpenPay transactions.  Is this correct?

So that's the end of the "pick a card, any card" method.  I think it would be a great starting point for getting bitcoins into the real world.

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

[RodeoX]

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

Isn't this a risk faced by all types of magnetic cards now?

[rjk]

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

Isn't this a risk faced by all types of magnetic cards now?

Yeah, except that it isn't as much of a risk because credit cards are reversible. Now that there is more risk because of the irreversibility of Bitcoin, this solution is a little less attractive.

[DeathAndTaxes]

Isn't this a risk faced by all types cards now?

Which is why credit cards are resversible and have fraud protection.

[RodeoX]

Ahh, roger that. So this is a unique risk to be addressed.

[MoneyIsDebt]

Is it possible with the bitcoin protocol, to transfer some money (for a hotdog) from wallet A to wallet B, then spend the money from (throwaway) wallet B in the same block? Or must the first transaction A->B be on the blockchain first? If possible, one could give the merchant the keys for wallet B together with a signed transaction A->B.
Having to wait ten minutes or more in the shop might be a dealbreaker though.

[Stephen Gornick]

Is it possible with the bitcoin protocol, to transfer some money (for a hotdog) from wallet A to wallet B, then spend the money from (throwaway) wallet B in the same block? Or must the first transaction A->B be on the blockchain first? If possible, one could give the merchant the keys for wallet B together with a signed transaction A->B.
Having to wait ten minutes or more in the shop might be a dealbreaker though.

The Bitcoin-qt client doesn't support it, but the protocol allows it.  If I remember correctly, older clients used to not relay these transactions where the inputs weren't confirmed but I believe that is no longer an issue.

I raise this issue (one confirmation required between uses) with another type of payment approach where there is a paper (throwaway) wallet:



 - http://bitcointalk.org/index.php?topic=74978.msg831171#msg831171

[isis]

A carder can install at any one of your merchants a card swiper and pin pad (presumably without the merchant's knowledge).  So the carder will eventually have all the information that the customer has ... card #, expiration and PIN.  The carder then creates a magstripe card with that same info and goes shopping at other OpenPay merchants.

What is the protection then from the carder that does this?

Isn't this a risk faced by all types of magnetic cards now?

Yeah, except that it isn't as much of a risk because credit cards are reversible. Now that there is more risk because of the irreversibility of Bitcoin, this solution is a little less attractive.

No mater what payment method you choose, carders are a risk.  You can't stop every criminal out there all you can do is make it horribly unattractive for them.   

As for reversibility being some sort of protection; in the EU if a transaction is made with a compromised PIN & card the law says it's up to you to prove that you didn't make the transaction, the bank is under no obligation to refund you if you can't prove it was stolen, they may do so as a courtesy but it really is bank policy that dictates this, not network policy.

In the US if you try to dispute a PIN based transaction the bank will generally laugh at you, my bank doesn't allow reversals on PIN based debit transactions at all.  If yours does you're very lucky.  I can't speak for all of them, but I know that of the major banks I've done business with in the past few years, none would reverse PIN debits for any reason even with a police report and newspaper article in hand.  The most they would do is re-issue the card.

You can't have it both ways.  You can't have the irreversibility of bitcoin and the reversibility of Visa, at some point you're going to have to say... Alright this is secure enough for me.

In furtherance of security, the solution includes several safe-guards to make it unattractive to carders & script kiddies.

A 1 time use disposable key generated on the fly to protect your primary wallet.
A tiered set of spending limits (you set) tied to static PINs which you also set.
Multi-factor auth or 1 time use disposable PIN via SMS

Network replay attacks are pointless because the key is disposed of by the client as soon as the request is received.
Brute-force attacks have a significant financial cost.
If someone had the static portion of the key (a carder for instance), the most they could get at is whatever you set your spending limit to for that PIN, for that day, for a single transaction etc.
If a carder were to try a non-pin transaction it would trigger an SMS to you, and it's doubtful they would have both your card and your phone. 

Additionally the carder would have to know that $ome_random_card was actually used on the OpenPay network and not visa/mc or instore credit.  That would require not just a pin pad compromise but a wholly compromised back office.

And if you're really paranoid about the threat of carders, just enroll different card(s) for different merchants and days of the week, a different one each day

[rjk]

To prevent PIN bruteforcing, it seems to me that it would make sense to require that the PIN be verified against a remote server that has limits on the number of PIN submissions per $time_period. If the PIN can be determined with the use of the track data and some cryptographic brute force, I think the project would be lost before it is started, especially since 10 numerical digits are trivial to bruteforce. However, making the PIN completely unrelated to the track data would make it a bit more secure.

However, I'm not sure how to do this. Especially without a central server, although that might be something that could be implemented as a bridge solution.

[DeathAndTaxes]

The pin pad would forward the card number and optionally the PIN to a specialized gateway application running somewhere on the merchant's local network.

The gateway application would take the card number, expiration date & pin (optional).
It would perform the same steps the client did during enrollment to generate the static half of the key.
Next it will also add the current timestamp (the other half of the key) and hash it to a valid bitcoin address. 
Finally it would send 0.01BTC to the address.  Along with payment instructions encoded some way in the scripsig.

Am I reading this wrong?  A pin pad that sends the pin as plain text to the merchant is of no value.  You just gave the merchant everything necessary to spend as the user.

[DeathAndTaxes]

To prevent PIN bruteforcing, it seems to me that it would make sense to require that the PIN be verified against a remote server that has limits on the number of PIN submissions per $time_period.

Which is why I don't see magnetic stripe being useful.  In a pin & chip system (Bitcoin or otherwise) the pin and secret never leave the smartcard.  The pin pad sends pin (hashed to prevent snooping) to the smartcard which verifies it and then performs some action on the secret only providing the output.

For Bitcoin the "secret" would be the private key or possibly deterministic seed for a range of private keys and the "some action" would be generating a signed tx.

[isis]

To prevent PIN bruteforcing, it seems to me that it would make sense to require that the PIN be verified against a remote server that has limits on the number of PIN submissions per $time_period. If the PIN can be determined with the use of the track data and some cryptographic brute force, I think the project would be lost before it is started, especially since 10 numerical digits are trivial to bruteforce. However, making the PIN completely unrelated to the track data would make it a bit more secure.

However, I'm not sure how to do this. Especially without a central server, although that might be something that could be implemented as a bridge solution.

The PIN in this case is just a number you tell the OpenPay client or that it tells you.  It's not stored anywhere including the track data.
It's used to generate the static half of the disposable key (an enrollment id) and that's it.  It's purpose is to ensure that you are in fact in possession of the card and also to help you enforce spending limits in the unlikely event of a compromise.

There is no verification on the PIN itself, if the pin makes the key fit the hole that the client is looking for,  then the merchant (or brute force attacker) will see a properly crafted BTC send transaction come their way.  But if it doesn't work, then they just spewed 0.01BTC into the void with each failed attempt.  There is no "PIN_FAILED" message, however a "PIN_REQUIRED" message might be seen if they stumble upon an address that has a listener at that exact second.

To crack a 4 digit PIN it would cost as much as 99.99BTC with no guarantee that the daily spending limit on a 4 digit PIN is greater than 99.99BTC.  I would recommend a PIN length 2 digits more than the daily spending limit for that PIN, just to keep the security level higher.

[rjk]

Eew, so granny making a mistake will waste money? Is the waste limited in how much? Could it be only a satoshi instead? Or does it have to be the amount of the whole transaction?

[isis]

The pin pad would forward the card number and optionally the PIN to a specialized gateway application running somewhere on the merchant's local network.

The gateway application would take the card number, expiration date & pin (optional).
It would perform the same steps the client did during enrollment to generate the static half of the key.
Next it will also add the current timestamp (the other half of the key) and hash it to a valid bitcoin address. 
Finally it would send 0.01BTC to the address.  Along with payment instructions encoded some way in the scripsig.

Am I reading this wrong?  A pin pad that sends the pin as plain text to the merchant is of no value.  You just gave the merchant everything necessary to spend as the user.

Yes you're reading it wrong.  It's one time disposable and limited by spending limits you set.  This isn't your primary private key, it's a generated ID used by the merchant to send a message to the client as signal to say "Hey look here!"

[isis]

Eew, so granny making a mistake will waste money? Is the waste limited in how much? Could it be only a satoshi instead? Or does it have to be the amount of the whole transaction?

I think you're confused.  The 0.01BTC spend is used to signal the client to look at the transaction.  It's sent from the merchants account to a disposable address calculated independently by the merchant and your client software.  That address is literally one time use and changes every single second.  Thus it's the merchant's money 0.01BTC that gets wasted in this instance.  I think 3 PIN failures is enough for the merchant to tell granny to stop brute forcing her own pin

The purpose of the network fee is to make brute forcing behavior unpalatable and unrewarding.  Doesn't matter if it's granny brute forcing her own pin, or some pimply faced clerk who is moonlighting as a carder.  The system can't tell the difference.

[rjk]

Eew, so granny making a mistake will waste money? Is the waste limited in how much? Could it be only a satoshi instead? Or does it have to be the amount of the whole transaction?

I think you're confused.  The 0.01BTC spend is used to signal the client to look at the transaction.  It's sent from the merchants account to a disposable address calculated independently by the merchant and your client software.  That address is literally one time use and changes every single second.  Thus it's the merchant's money 0.01BTC that gets wasted in this instance.  I think 3 PIN failures is enough for the merchant to tell granny to stop brute forcing her own pin

The purpose of the network fee is to make brute forcing behavior unpalatable and unrewarding.  Doesn't matter if it's granny brute forcing her own pin, or some pimply faced clerk who is moonlighting as a carder.  The system can't tell the difference.

OK, as long as it can't be done in the comfort of some carder's home or in the back office where an unscrupulous cashier doesn't care how much of his employer's money he wastes.

[marcus_of_augustus]

Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.

[isis]

Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.

I haven't taken multisig into account, just two factor.  That's mostly because it's a new concept I'm not sure I fully understand.  Is there a really good explanation of how that would work in the Bitcoin system?  It might be I could incorporate it into this design, or rework the whole concept to leverage it properly.

[marcus_of_augustus]

Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.

I haven't taken multisig into account, just two factor.  That's mostly because it's a new concept I'm not sure I fully understand.  Is there a really good explanation of how that would work in the Bitcoin system?  It might be I could incorporate it into this design, or rework the whole concept to leverage it properly.

https://en.bitcoin.it/wiki/BIP_0010

https://en.bitcoin.it/wiki/BIP_0011

It is at dev stage, afaik, but Gavin has done a lot of work/testing on it and he is the lead dev. so it is probably not that far away ...

[isis]

Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.

I haven't taken multisig into account, just two factor.  That's mostly because it's a new concept I'm not sure I fully understand.  Is there a really good explanation of how that would work in the Bitcoin system?  It might be I could incorporate it into this design, or rework the whole concept to leverage it properly.

https://en.bitcoin.it/wiki/BIP_0010

https://en.bitcoin.it/wiki/BIP_0011

It is at dev stage, afaik, but Gavin has done a lot of work/testing on it and he is the lead dev. so it is probably not that far away ...

Thanks!  You know that was very helpful information and greatly simplifies the design for this... Assuming i understand it correctly.

Instead of a 0.01BTC broadcast to a constantly changing key that then has to be picked up and processed by the primary wallet.

The merchant gateway is actually a fullblown node.

The gateway would initiate a TxDP, essentially just a note specifying where the money needs to go, but the TxIn field is left blank.
This is then signed with the users semi-private key which was generated by a hash of the card details and PIN.

The signing system (primary wallet or wallet protection service or whatever) sees the TxDP then does some confirmation checking either sending an SMS, or popping a message on an android app, or just checking for the presence of a static PIN and if the confirmation checks out.
Fills out the TxInput fields, then signs it and sends it off to the network.

This makes sense to me, except I don't see how the primary wallet is supposed to know to look for the transaction, but maybe I'm just missing something simple.

Still, I'll keep digging.
 

[Elwar]

In theory...would this allow a merchant to pay 0 fees?

[gnar1ta$]

Am I misunderstanding or is the end goal here to get bitcoins to the merchant - which several solutions already exist? I would think there is more demand/need for a solution to get dollars to the merchant from a consumers bitcoins using existing debit/credit card infastructure.

[Elwar]

Am I misunderstanding or is the end goal here to get bitcoins to the merchant - which several solutions already exist? I would think there is more demand/need for a solution to get dollars to the merchant from a consumers bitcoins using existing debit/credit card infastructure.

That would make sense considering it would be much easier to convince a merchant to switch over if you could just say "download X software and you can start getting 0-1% transaction fees on certain transactions".


And it would certainly be useful for consumers by saying "download X software and start converting your dollars to Bitcoins to avoid needing to deal with banks and credit card companies".

[gnar1ta$]

That would make sense considering it would be much easier to convince a merchant to switch over if you could just say "download X software and you can start getting 0-1% transaction fees on certain transactions".

It would be even better to not have to convince a merchant at all.  If it could function with existing merchant solutions and only be a change on the consumer side, I wouldn't need or want my bank accounts.

[isis]

That would make sense considering it would be much easier to convince a merchant to switch over if you could just say "download X software and you can start getting 0-1% transaction fees on certain transactions".

It would be even better to not have to convince a merchant at all.  If it could function with existing merchant solutions and only be a change on the consumer side, I wouldn't need or want my bank accounts.

I don't think these are mutually exclusive goals.
The marketing for OpenPay would have several facets.

The merchant side actually will focus on the severely reduced transaction fees, the lack of charge-backs and the ability to accept merchants without need of new equipment.

The consumer side will focus on the security features (no one can touch your money but you) and of course the ability to spend BTC.  There will also be an attempt to capture some of the un-banked marketshare as well.  Lots of folks don't have bank accounts for one reason or another, lots of others are simply denied the ability to have a bank account without any due process at all thanks in large part to consumer reporting systems like ChexSystems.  Thus for all intents and purposes, a person with an OpenPay card really wouldn't need a separate bank account once enough merchants begin to accept it.

The complete proposal for OpenPay includes creating an infrastructure that allows an easy and seamless standard for transition between BTC , Local fiat, and back again.

OpenPay as I've described it, is intended to be a payment standard AND a payment network.  This payment network functions as a bi-directional, bitcoin to fiat gateway.  It rides directly on top the bitcoin network and uses bitcoins as it's interchange currency.

It is expected that other services will crop up to use the standard and create a healthy and competitive eco-system.

To speed the adoption of, and promote the use of OpenPay, there will be a non-profit organization who's purpose is
To promote the adoption of the OpenPay network by,
#1 Developing the OpenPay standard and providing reference implementations of these standards for free or low cost,
#2 Recruiting users (consumers, banks, exchanges etc) into the network.
#3 Certify experts and provide an exchange of experts in OpenPay to assist incoming users in developing niche applications for the ecosystem.

The proposed name for this organization is the "Open Payments Alliance", yes we've been calling it grandpa around here
The only reason it's a proposed name instead of an actual name at this time is that a trademark search has yet to be completed and the name does seem like something that ought to have been trademarked by someone, however a cursory search shows nothing.

I'm going to keep posting updates here a they happen, so stay tuned!

[marcus_of_augustus]

That would make sense considering it would be much easier to convince a merchant to switch over if you could just say "download X software and you can start getting 0-1% transaction fees on certain transactions".

It would be even better to not have to convince a merchant at all.  If it could function with existing merchant solutions and only be a change on the consumer side, I wouldn't need or want my bank accounts.

I don't think these are mutually exclusive goals.
The marketing for OpenPay would have several facets.

The merchant side actually will focus on the severely reduced transaction fees, the lack of charge-backs and the ability to accept merchants without need of new equipment.

The consumer side will focus on the security features (no one can touch your money but you) and of course the ability to spend BTC.  There will also be an attempt to capture some of the un-banked marketshare as well.  Lots of folks don't have bank accounts for one reason or another, lots of others are simply denied the ability to have a bank account without any due process at all thanks in large part to consumer reporting systems like ChexSystems.  Thus for all intents and purposes, a person with an OpenPay card really wouldn't need a separate bank account once enough merchants begin to accept it.

The complete proposal for OpenPay includes creating an infrastructure that allows an easy and seamless standard for transition between BTC , Local fiat, and back again.

OpenPay as I've described it, is intended to be a payment standard AND a payment network.  This payment network functions as a bi-directional, bitcoin to fiat gateway.  It rides directly on top the bitcoin network and uses bitcoins as it's interchange currency.

It is expected that other services will crop up to use the standard and create a healthy and competitive eco-system.

To speed the adoption of, and promote the use of OpenPay, there will be a non-profit organization who's purpose is
To promote the adoption of the OpenPay network by,
#1 Developing the OpenPay standard and providing reference implementations of these standards for free or low cost,
#2 Recruiting users (consumers, banks, exchanges etc) into the network.
#3 Certify experts and provide an exchange of experts in OpenPay to assist incoming users in developing niche applications for the ecosystem.

The proposed name for this organization is the "Open Payments Alliance", yes we've been calling it grandpa around here
The only reason it's a proposed name instead of an actual name at this time is that a trademark search has yet to be completed and the name does seem like something that ought to have been trademarked by someone, however a cursory search shows nothing.

I'm going to keep posting updates here a they happen, so stay tuned!

Please do, this is sounding good.

[rjk]

I still have major reservations about how easy it is to bolt together the traditional payment systems and Bitcoin, but I too am eager to hear of any progress.

[isis]

I still have major reservations about how easy it is to bolt together the traditional payment systems and Bitcoin, but I too am eager to hear of any progress.

Make no mistake, it's anything but easy.
Technical limitations aside, there are political & legal considerations that must be taken into consideration.

However OpenPay does have one significant advantage.  
This advantage is what has colloquially been called, the "will of the economic majority".  
Most people want to pay with a card.  The majority of bitcoin holders would like to be able to use their cyberspace currency, in meatspace and do so securely and seamlessly.  

The majority of merchants would like to
A) Pay less in transaction fees
B) Never have another chargeback
C) Do so while processing payments electronically
D) Attract an entirely new market of people with money to spend who are eager to spend it
E) Do the above with a minimum of effort
F) All of the above

This means that there is the potential for a lot of momentum and once an idea has significant momentum behind it, it becomes nearly impossible to stop.

[rjk]

Don't forget to figure out some way for the POS owner to process a refund. Even though chargebacks aren't possible, refunds are still necessary.

[keverw]

I've been reading this, and I think this would be really cool. I'm not sure If I could be any help, but I'm guessing it could be a P2P network on it's own, running along side Bitcoin would be a good idea. Maybe getting our own 4 digit network ID would be helpful. I really would love to make this happen, not sure if I could be any help. I would love to learn about how to create a P2P network, I have some ideas on how they work...

Don't forget to figure out some way for the POS owner to process a refund. Even though chargebacks aren't possible, refunds are still necessary.

And I'm guessing it would be like cash. If you spend cash on something at a store and you don't like it. There's no magical button to get it back, you have to tell the store and hope they help you solve it. if not, then maybe you try to sue them. But I guess in the end, It would be just like cash. That reminds me, someone was making Bitcoin physical coins or something, that you could trade offline. I guess it had the key info inside as a QR code, but you could tell if someone attempted to open it or not. Forget who.

[rjk]

And I'm guessing it would be like cash. If you spend cash on something at a store and you don't like it. There's no magical button to get it back, you have to tell the store and hope they help you solve it. if not, then maybe you try to sue them. But I guess in the end, It would be just like cash. That reminds me, someone was making Bitcoin physical coins or something, that you could trade offline. I guess it had the key info inside as a QR code, but you could tell if someone attempted to open it or not. Forget who.

Quite so. But I am working on the assumption that Bitcoin transactions would be converted to fiat instantly to prevent exchange fluctuation risk, and sometimes refunds don't even happen the same day. This also assumes that the customer gets their refund back as bitcoins, and not fiat.

[Raize]

Every time I see these sorts of things it always seems to be that the solution ultimately comes down to a trusted Bitcoiner running their own payment processing network or trusted node. I think multi-sig will fix some of this, but the scale of the Bitcoin network is rapidly outpacing what joe-schmoe can run. What's essentially going to have to happen is that we're all inevitably going to become Bitcoin bankers for our friends and family, and we'll provide lower fees for both them and merchants and slowly replace the banks, too.

Things like Openpay seem to confirm this is how it has to go down...

[Elwar]

This would actually make for a very easy way to exchange BTC for cash if you provided an option for "cash back".

Buy a pack of gum and ask for $20 cash back. They get the cost of the gum and $20 worth of BTC and you get the gum and cash.

[isis]

I've been reading this, and I think this would be really cool. I'm not sure If I could be any help, but I'm guessing it could be a P2P network on it's own, running along side Bitcoin would be a good idea. Maybe getting our own 4 digit network ID would be helpful. I really would love to make this happen, not sure if I could be any help. I would love to learn about how to create a P2P network, I have some ideas on how they work...

Don't forget to figure out some way for the POS owner to process a refund. Even though chargebacks aren't possible, refunds are still necessary.

And I'm guessing it would be like cash. If you spend cash on something at a store and you don't like it. There's no magical button to get it back, you have to tell the store and hope they help you solve it. if not, then maybe you try to sue them. But I guess in the end, It would be just like cash. That reminds me, someone was making Bitcoin physical coins or something, that you could trade offline. I guess it had the key info inside as a QR code, but you could tell if someone attempted to open it or not. Forget who.

You are quite correct, an IIN would be necessary in the long run especially once we go Chip & PIN.
The best way to help is to help. We're in the processing of ramping up and anyone that wants to lend their skills is definitely needed.  
We currently have documents that I used to present the basic ideas behind OpenPay.  I got partial buyin and then I received permission to take the whole thing open. I'm in the process of converting those docs into a standard format and ripping client proprietary info out of to turn them into standards docs.  I'm also working on some baseline marketing docs, but marketing isn't my strong point.  
What we really need for this process are editors (also translators would be nice since all the docs are in english), and a logo would be lovely to have as well.

I'm also personally writing a complete software stack, it's a reference implementation and will be in Java.
Once it's code complete we could use some willing folks to give it a try and provide feedback.  Good coders could help look for security vulnerabilities and bugs and develop patches to fix anything that might be found.  The entire project will be open, probably hosted on github or sourceforge.

The best way everyone can help is to encourage every merchant they know to start taking OpenPay.  Get to know it's strengths and weaknesses and sing it's praises whereever we can.  The more merchants adopt or commit to adopting as a valid method of payment the faster the momentum will build.  If you happen to be a merchant feel free to start talking to your customers about OpenPay and the advantages it will provide. (Transparency, anonymity, security, no fees, no overdrafts etc).

A final way to help is to make a donation to the address in my sig.  That wallet is a completely offline wallet being used to fund the development of open pay.  This includes laying down the basic infrastructure to make it work as well as funds to pay for marketing.  Merchants probably won't take it if they don't know about it.  This is not a donation beg, we do have $10k USD in exploratory funding on hand, more will follow if we can create a proof of concept quickly and meet certain milestones.  Nevertheless it would be nice to have a few hundred bitcoins on hand for testing the network with real funds.  Also participating in the testing would be a good way to help and make money at the same time.  /end beg

Now as to your question about P2P networks, most P2P is really fairly simple.  There is a chat room, for instance IRC on freenode.  All the clients connect to it and listen for events.  They then respond to those events either via the broadcast & discovery channel (bad idea), or via the back channel requested by the peer (In most cases this is DCC or direct client connection).  At this point the peers have all discovered eachother and then do the work that they are programmed to do.

You are also correct that OpenPay will need to use it's own custom P2P network as a backchannel around the speed limitations of the bitcoin network.  This will be used for transaction requests.  The difference is this network is based on onion routing, which is what TOR uses for anonymity.
The specific methods used should provide a significant speed up to the current system and will be light years ahead of either TOR or Bitcoin in terms of messaging speed.  The bitcoin network will still be used to prove all transactions though.  

[isis]

I'm nearly done with the initial design document for the OpenPay reference software stack.
I'll post it here for comment within the next 24 hrs.
In the meantime, the word OpenPay appears to be a registered servicemark of HP. 
I don't think it's in use, nor has it really ever been.

Nevertheless I count HP among my clients, therefore it may put me and even potentially the whole project in significant legal peril if issues arise (no compete, all IP belongs to them etc). 

Let me be clear about this though, HP had nothing to do with OpenPay as we have been discussing it here.  In fact the division I was allied with at HP was printers specifically and I've had no particular contact with anyone outside that division.  It's a coincidence of naming and nothing else.

To prevent any possibility of legal encumberance, I'm willing to consider other names and probably we ought to put it to a vote.  For the record my significant other mentioned that Que Peso might be a good alternative   Nevertheless I'm open to suggestions.

[keverw]

Oh cool. I haven't messed with Java, but I have played with Node.js(Javascript) and I prefer GitHub, and maybe a Node.js implementation would be good, I prefer Node.js to Java. So maybe I or a few other people could attempt to port it to Node.js? Mostly the logic and ideas can be put in to other languages. Then post it on GitHub also. I'm not the best programmer, but want to help. Seems like a good early project to get involved with.

Also, we can use TestNet to test with a POS system, and servers. Just create fake items to buy/test. then once it works, switch over to the real network. For us without POS hardware, and can't really afford them. We should have a emulator. I might be able to build one with Node.js. A little node app someone runs, and opens up localhost on some port, then enters in some info like production, test net, and can enter in card numbers to test with, the item, price. Something really simple, just for testing. then basically the POS would run some similar software, written in like C or something guess, that uses similar code to connect to the network once it sees that it's an OpenPay card. I guess we really need a really good detail spec, before we write any code, in any languages.

Then I guess some of the early contributors can form a organization and have a board, to self regulate the project, and new ideas, etc. I guess Bitcoin is like this. You have Bitcoin itself, and the non profit "governing" it.

[isis]

I'm now working on the reference implementation of the OpenPay software stack.
This software stack will be a complete package of modular components called "services" that all run independently of one another.

The reference implementation will be completely written in Java, although there is absolutely no reason that other languages couldn't be used to re-implement any of the services or components.

I cannot stress this enough, the overall design is extremely secure, but presents the potential for a single point of failure if the implementation does not provide redundancy via multiple instances on separate machines.  (This is true of any distributed computing system).

An ideal professional implementation should be have a minimum of 2 instances of each service, running in geographically distinct areas.

The whole design is intended to provide military grade security and be all but impossible to knock offline. 
Thus the compromise of any single service (however unlikely) will not yield anything of value to a hacker. 
Complete compromise of the entire system could potentially be a problem and for that reason, each piece is broken out as an isolated & low value service with hardened security.

This was done so that all but the most inept IDS could detect a break in attempt before anything of value is compromised.

Beyond the security concerns, Denial of Service just "for the lulz", might cause grief any time there is only 1 instance of any of the individual services running.


Most of what follows here is necessary only for the Magstripe implementation.  However when the EMV, Chip & PIN solution rolls, magstripe may remain as a necessary fall back in the event the chip on the card becomes damaged or the merchant is not equipped for anything but magstripe.

In addition to Magstripe & Chip & PIN modes, there will also be an ultra light weight version of each service to enable full OpenPay usage on a smart phone, such as Android.

We will call this "phone mode" services.

This will allow customers who do not have the resources to host a full OpenPay service stack and who also do not wish to join a participating financial service to still participate fully in the OpenPay network.

We are also exploring NFC options outside of EMV cards.
Now for the design doc.  Understand that this is rough draft, spelling and grammatical mistakes are a real possibility.

The OpenPay stack will be comprised of a collection of low value, hard to crack programs running as a cluster of related services.

Services List -

Signing Service
Authentication Service
   2 factor auth module
   Static PIN module
   Non-PIN module
   Dynamic PIN module

Messaging Service
Balance Service
Enrollment Service
Currency Exchange Service (Cannot be documented at this time but a basic implementation will be provided upon request)
Merchant Gateway Service

Basic Workflow -

Payment Request Messages come in from the Messaging Service (Which straddles the bitcoin network and the openpay messaging network).

Authentication determines if the payment request is for us, by looking at the enrollmentID for a match.
If the enrollmentID is a match, then authentication will query the balance service to determine if sufficient funds are available to complete the transaction. 

If there is insufficient BTC, but the Exchange Service is enabled and configured, then the Exchange Service will attempt to perform a market transaction to acquire sufficient bitcoins to complete the transaction.

Once the service determines sufficient BTC funds are available, then the transaction engine is notified to begin constructing a "BTC spend" transaction. 

Once this transaction returns, then the authentication service sends the transaction, the enrollmentID half of the key and key hash to the signing service.

The signing service signs the transaction and returns it to the authentication service which passes it to the messaging service puts it on the bitcoin network and sends a copy of the signed transaction to the merchant.

(Ideally the merchant's gateway should then verify the transaction using the normal methods of validation)

Transaction Pathway from Merchant - (Happy Path)
Note: This may change in the future once an IIN for OpenPay is created and we move to EMV

1 Transaction is sent to tender via the normal process.
2 The PIN pad will light up with the "OpenPay" option among the list of other MOPs (MOP = Method of Payment), such as credit, debit, ebt etc.
3 OpenPay is selected on the payment terminal by the customer.
3.5 (Optional) - Customer may elect to see the transaction in BTC or local currency

4 The terminal registers a normal cardswipe event.
5 The cardswipe event and transaction amount are routed to the OpenPay enabled MGS
6 The MGS converts the local currency transaction amount to BTC if this was not already done elsewhere such as by an Exchange Connection Service.
7 MGS calculates an enrollmentID and then hands the enrollmentID & amount to the messaging service.
8 The messaging service encrypts the transaction request message and prepends a messageID 
9 Messaging service then passes the encrypted request to the OpenPay P2P network as described in "Messaging Service"
10 Authentication service identifies that the transaction request is intended for it by attempting to decrypt the message, by using the enrollmentID as decryption key. (This only happens if there is only 1 message ID, after the initial exchange it only tracks message ID.)
11 Authentication queries the Balance service to determine if there are sufficient BTC funds.
12 Assuming there was sufficient BTC (or if an Exchange Service was enabled, a market order for BTC buy, executed correctly), Authentication will tell the transaction service to build the transaction.
13 Concurrent to the transaction being built, (assuming some form of secondary auth is enabled) a PIN request message is sent back to the PIN pad via the P2P network and the MGS sets the PIN acquire mode on the PIN Pad.
14 Concurrent to the PIN request message, and depending on the configured module(s) a PIN is either retrieved from the data store or generated and sent to the customer via the enabled modules.
15 The transaction service completes generating the Bitcoin transaction and hands it back to the authentication module.
16 The user enters a valid pin as instructed and this PIN propegates back to the authentication service.
17 Authentication validates the PIN via the relevant authentication module.
18 Assuming the PIN validated correctly, the Authentication service now hands the transaction to the signing service.
19 The signing service signs the transaction and hands it back over to authentication.
20 Authentication passes it back to the MGS via the messaging service.
21 The MGS (optionally, but a good idea), validates the entire transaction and then passes it to the Bitcoin network while sending a transaction complete message to the POS & payment terminal (pin pad).


Merchant Gateway Service (MGS) -
This is a "merchant only" piece of software and the expectation is that this will be the most widely modified & distributed piece of the stack because each merchant will want their own ruleset.  Additionally it is very likely that existing merchant gateway providers will simply incorporate the protocol into their existing products.


Signing Service -
The keys are to be stored and managed by a signing service.  The keys used will be standard ecdsa private/public pairs, but the private key stored on the wallet service is only one half of the key.  The other half is your enrollment ID (a hash generated from the card you registered).  The service itself will not have any idea of any mappings between enrollmentIDs and private half keys.  Instead when the keypair is generated a registration message (hash,hash) is passed up the line to the authentication service.  A complete compromise of the signing service would not do an attacker any good.  There is no money to steal because the keys contained are by themselves invalid, they need the other half of the key to run.  The signing service will be tiny enough to fit on an EMV compliant smart card and could find ample room on even the tiniest of modern devices.

The sole purpose of the service is to accept an input of enrollmentID, private key hash & pre-filled bitcoin transaction.  It's sole output will be a bitcoin transaction signed as per request or an error.  The preparation of the transaction is handled by the transaction preparation service, which is linked to the authentication service.


Authentication Service -
The authentication service is middleware.  It sits directly between the messaging service and the authentication service.
It's primary purpose is to manage communication between the messaging service(s) and the signing service(s).
It will manage the mapping of the enrollmentID to a hash of the signing services private key.  It should be obvious, but this service should never be run on the same physical box as the signing service, even if it's in a different VM.  The boxes should also have completely unique SSH keys.  To prevent a potential denial of service issue, communication between the two services should be via a VPN or other secured and authenticated channel. Preferably this would occur on a randomly assigned periodically changing port.  Port knocking to initiate communication is also a real possibility here.  Authentication is designed to be pluggable to meet the business needs of the entity or person utilizing it.  These plugins are called modules.  They primarily relate to various forms of additional authentication required.
The modules included and enabled by default in the reference stack will be...
   2 factor auth module  (google authenicator, gemalto key fob etc.)
   Static PIN module (Most currently deployed method of ensuring cardholder is present)
   Non-PIN module (Make the card work in swipe only mode, no pin required (insecure)
   Dynamic PIN module (Send a one time use pin via a back channel such as XMPP, SMS or telephone call)

The interaction path for the authentication service is a bit more complex than the others because it serves as a nexus of sorts.  It will not be spelled out here because the individual interactions are identified as each of the other services are called out.


Transaction Service -
The next service is the transaction preparation service.  Once a transaction request has been received it will check the balance via the balance service.  It will then take the output of the balance service and build (but not sign) the actual transaction.
This transaction is then handed to the authentication service which will have the signing service sign the transaction if authentication completed successfully.

Balance Service -
At this point the balance service merits some discussion.  It takes as it's input a public key and returns a list of unspent TxOuts from previous transactions.  Because it needs up to date information, it is quite likely that the balance service will be run as part of a mining pool.  However an exchange may wish to run it as part of their existing infrastructure.  The reference implementation for this will be based on the mining pool concept, but other possibilities would be trivial to implement.


Messaging Service -
The final part of the puzzle is the messaging service.
The OpenPay peer to peer network will utilize XMPP as the transport layer.
OpenPay P2P application layer messages are formated as JSON.

In addition to an SSL connection between the merchant gateway and his/her XMPP gateway, each message will also be encrypted. 
The encryption used will vary depending on the message type.
Every message on the network will have a timestamp, as well as one or two Globally Unique Identifiers (GUID) and an encrypted message body.
OpenPay transaction messaging by default will use Onion routing.  However DCC is a configurable option as well.

Onion routing is the process of passing a message along without any knowledge of it's source, it's destination or it's contents.  This provides very strong anonymity which is one of the goals of OpenPay.  TOR uses this same methodology and it has proven to be a very good method of ensuring strong anonymity.

Nevertheless XMPP (and thus OpenPay) provides a DCC like mode of operation.  In DCC mode, two clients directly connect to eachother to communicate instead of simply passing unknown messages from unknown sources to unknowable destinations.  The advantage of DCC mode is that speed will be greatly increased, the disadvantage is that it breaks the strong anonymity aspect of onion routing.  The choice of modes will be up to the individual or company who is running the messaging service.  The protocol will support both seamlessly.


When a card swipe occurs the Merchants MGS will create a message with 1 GUID a timestamp and a message body (containing the transaction request).
If DCC mode is enabled then the merchant gateway JID will be added to the message body as well.  Otherwise this step is skipped.

The message body is then encrypted using symetric key encryption.
The key to the encrypted portion will be the enrollmentID plus the timestamp.

This message will be handed to the immediate peers of the Merchant Gateway which will hand it to their peers and so forth.
The message passing will continue even if the message is intended for the recipient machine.  This is a security measure intended to prevent a snoop attack that could happen by identification of any particular message service with any particular transaction.
A message will be relayed ONLY if it's less than 5 minutes old and it's ID has not been seen in the last 30 minutes, this is intended to prevent the network from being overwhelmed with messages.

Each peer upon receiving a message containing only 1 message id, will attempt to decrypt it using the enrollmentIDs that it is in charge of.
If decryption was successful, an AES 256 bit key is generated at random and is used for the life of this transaction. 
A message is then created saying that the enrollment ID has been found.

Now at this point there are two possibilities.  If the messaging service is running in peer-discovery or DCC mode then the JID of the messaging service is added to the body of the reply.  If it's not running in discovery mode then that step is skipped, this is the only difference.


In the next step the newly generated shared key is appended to the message.

The message body is then encrypted using the enrollment ID plus timestamp.
2 message IDs and a timestamp are prepended, to the encrypted message body.
The IDs are the original message ID called a replyfor ID, and a second message ID called a replyto ID.

The purpose of the replyfor and replyto ID are for message tracking purposes. 
The messaging service will not try the decryption step on a message containing 2 message IDs (unless it's looking for a specific message reply) since it indicates relay mode only and would be a colossal waste of resources.

The newly crafted reply is then sent along to the merchant gateway using either DCC or Onion broadcast.
 
When the merchant gateway sent the message it began a countdown timer of 1 minute.
If it takes more than 60 seconds to receive a reply it will resend one last time and present alt tender options to the customer after the second minute has expired.
If it receives the intial reply message within a minute then it restarts the timer and updates the payment terminal with a "found" message.

If or when the reply is PIN_REQUIRED, then the merchant gateway will set the pin terminal into PIN_ACQUIRED mode and wait for customer PIN entry.  Once a PIN has been entered a new message is crafted containing the enrollmentID hashed with the PIN and the replyFor/replyTo fields filled out.  The message body is then encrypted using the previously received key and sent back along the network for further processing.

The messaging service will receive the message, decrypt it, compare the hashed enrollmentID with what it was expecting (via authentication service).
Authentication then send the transaction for signing (assuming it was a match)
Or sends a PIN_MISMATCH message back to the gateway (if the values don't match)

Once the transaction has been signed it is sent to the bitcoin network for processing and sent back up to the merchant via messaging (with the same encryption in place as before), for the merchant to independently confirm the transaction and pass it off to their bitcoin processor.

 
That's the documentation I have so far folks.  There are some proprietary bits I'm trying to work out such as the Merchant Gateway Service and the Exchange Connector.  But other than that this is the complete high level design for the OpenPay system.  Let me know what you think.

[Elwar]

Perhaps call it "Secure Open Pay"?

secureopenpay.com

[isis]

Perhaps call it "Secure Open Pay"?

secureopenpay.com

Not a bad idea, but I've been doing some research.  I think a name without the word pay and that can be trade marked might be a better idea.

Since OpenPay is intended to be a network like Visa, MasterCard, Discover, AMEX, it should have a unique name that doesn't nessecarily have anything to do with pay or payments.  I'm content for the term OpenPay to refer to the protocol, Open Payments Alliance to refer to any group that helps develop or steer it.  However a unique name, short, simple, memorable etc should be chosen for the network & tender type.

Thoughts?

[RodeoX]

I'm not particularly good at this but...
Secure-Pay
Safe-Pay
Padlock

I'll edit this if I think of more.

[Elwar]

I do think that giving the user the idea that this payment method is more secure, reliable and easy would help sell it.

Some thesaurus terms for secure:
assured, at ease, balanced, carefree, cinch, conclusive, confident, determined, easy, established, firm, hopeful, in the bag, locked on, nailed down, on ice, reassured, reliable, resolute, sanguine, self-assured, self-confident, settled, shoo-in, solid, sound, stable, steadfast, steady, strong, sure, sure thing, tried and true, unanxious, undoubtful, well-founded

reliable:
   candid, careful, certain, conscientious, constant, decent, decisive, definite, dependable, determined, devoted, faithful, firm, good, high-principled, honest, honorable, impeccable, incorrupt, loyal, okay, positive, predictable, proved, reputable, respectable, responsible, righteous, safe, sincere, solid, sound, stable, staunch, steadfast, steady, sterling, strong, sure, there, tried, tried-and-true, true, true-blue, true-hearted, trusty, unequivocal, unfailing, unimpeachable, upright, veracious

easy:
child's play, cinch*, clean, easy as pie, effortless, elementary, facile, incomplex, intelligible, light, lucid, manageable, mild, no problem, no sweat, not difficult, picnic, piece of cake, plain, quiet, self-explanatory, simple as ABC, smooth, snap*, straightforward, transparent, uncomplicated, uninvolved, unmistakable, untroublesome, walkover

[isis]

For now we should just run with the OpenPay name, if there is an issue later we can cross that bridge when we get there.
In the meantime I've opened up a skeleton project on github for the software stack and will be committing the modules as they are completed.

I will also be posting the url of servers running each module so that they can be properly tested.
Once the reference implementation is operational I would like to see as many different attacks against the system as possible so that we can harden it before we go live.

There will be live bitcoins in the test system, all of them mine, they will belong to whomever can successfully execute any attack and post the method of the attack they used.
Enjoy!

[Elwar]

I cannot wait until this becomes live and I can pay for gas with my Bitcoin card.

I know nothing about the credit card system but will gladly contribute my java programming skills, at the very least to help with bug testing.