Bitcoin Forum

OpenPay will be officially entering pre-launch next week.  I will be posting the URL for the Open Payment Alliance website as soon as the Pre-launch is ready.

Pre-launch will be comprised of 3 primary phases.

The first stage is the "Burn in" phase, we will be laying out the infrastructure and hooking all the pieces together.  It is expected to last 2-4 weeks.  During this time anyone who wants to participate will receive hands on assistance in getting set up and connected to the network.

The second stage will be the "Shake Down" phase, this will be a sort of wargames period.  The Open Payment Alliance will pre-load the network with up to 1000 bitcoins, all of which will be constantly traversing the network.  The bitcoins on the network will all be real and they will be involved in binding transactions that will be occurring during this phase.  The purpose is to try and break (or break into) the system.   Anything you can come up with in terms of an attack will be fair game on the network during this time.  Our goal during this time is to learn how well the network and our reference stack can withstand sustained assaults, attacks and threats.  All the money you can capture during this phase will belong to you, no questions asked.  Our most significant goal is to learn how to analyze and defend against the attacks, so while we would appreciate any information you can provide, it's not strictly necessary.  This period is expected to last 1 to 2 months and during this time there will be a public scoreboard on the OPA website where you can see who got away with what and how they did it, (in as much as we are able to determine these facts).

The third stage is the Alpha test phase.  During this phase we will be primarily focused on bringing real merchants online.  Service providers who wish to bring merchants online during the Alpha test will be given direct one on one systems analysis, IT consulting, software support and even low or no cost custom software development if needed, to hook their customers and existing services into the OpenPay network.  The Open Payment Alliance will cover the software development and customization costs to bring on merchants of any size.****  This period is expected to last up to 6 months or until we have 1,000 unique merchants using the system, whichever comes first.

What is OpenPay?...

For those who do not know about it already, OpenPay is a new EMV compatible payment network that rides on top of the bitcoin network, and uses bitcoins as a currency agnostic interchange medium.
The end result of OpenPay is that you will be able to spend your bitcoins at any merchant that is able to accept Visa or Mastercard.

For the consumer, OpenPay means you will be able to use an EMV chip & pin smartcard, an NFC capable device such as your smartphone (there will even be a magstripe card option for those of us still in the dark ages) to spend your bitcoins at your local merchant.

For merchants, OpenPay means you will be able to accept payment in your choice of currency (BTC, Local, or other), with no network fees* or fear of charge-backs. 
There are also no restrictions on what can be sold or transacted on the network, if it's legal in your jurisdiction then it's allowed on the network (The anonymity and security aspects mean we have no idea who is transacting what, where or why.  We are not encouraging illegal behavior here, just saying that OpenPay is designed to be highly resistant to tin pot dictators, tyrannical governments and peeping spouses.  The only way we could do that is to create a pure common carrier network with high strength encryption, and complete anonymity.  Still the transactions all settle and finalize on the bitcoin network so don't do anything illegal please.) .

For service providers such as mining pools, banks, and currency exchanges (or people that want to start one or be their own), OpenPay is designed to be an essentially unbreakable, low cost business opportunity and value added service for your clients.
This is because the OpenPay stack is comprised of a series of modules aka services that are designed to be highly secure, very hard to crack and of little or no value on their own.
In other words an attacker trying to crack an OpenPay deployment would spend a very long time trying to do so, only to find out they were wasting their time; they would need to compromise your whole deployment before gaining anything of any value and even that would be highly questionable.  OpenPay's security model is not dependent upon any component or collection of components, and even services within a single deployment always assume all the other services are already compromised and therefore it all runs in a 0 trust mode.  There is no security through obscurity,
This means that an entity running the OpenPay stack in it's recommended configuration should not be susceptible to the kinds of attacks and break ins we have seen lately.

Features...

Security -
The OpenPay network is designed to be free of any viable attack vectors by utilizing security industry best practices at each stage of the payment processing pipeline.
The OpenPay network features strong anonymity via the use of a P2P based Onion routing model (similar to TOR).
All messages on the network are encrypted using AES and are unreadable by anyone except the sender and intended receiver**.
Offnetwork (anything not traversing the internet) Interprocess communication is handled via SSL/TLS and a certificate restricted ACL.

Opportunity -
OpenPay is completely de-centralized, the Open Payment Alliance is a volunteer organization tasked solely with the development of the OpenPay reference implementation and standard.  This means that service providers are expected to come online over time and provide the actual services on the network.  In a nutshell, it means anyone can be their own bank, or they can work with their existing institution, it's totally up to the participants.  No centralization means no central bank or other authority to dictate what can and cannot happen to your money.  It also means that anyone with the necessary skills and an entrepreneurial bent can begin offering their own services over OpenPay without the "blessing" of a central authority***.

OpenPay's design and reference implementation are completely open, and will be released under the terms of the GPL.
Anyone can run their own payment processing node on the system, detailed deployment instructions will be made available, along with best practice recommendations.
OpenPay features a built in deposit insurance system.  Service providers who choose to participate will receive 100% deposit insurance coverage for all bitcoins held in OpenPay enabled accounts.


Caveats & Fine Print...
*OpenPay has no network fees, if you choose a service provider they may charge you a payment processing fee, read your contract carefully.
**There is a known side channel attack against AES on Linux servers that use the "Completely Fair Scheduler" (CFS), Windows is well known as a security nightmare.  OpenBSD is our recommended deployment platform.  The reference implementation is written in Java and will run on anything that has a JVM, including *BSD, Android/Chrome OS, all flavors of Linux, Windows and ought to run just fine on OS/X.  Still you need to make sure you properly secure your servers, nothing can protect you completely once an attacker gets root or administrative privileges.  We get around it to a great degree by running several separate, low value services on separate physical servers.  Still if you don't have a computer security background you should hire someone who does to manage your deployment, don't run unnecessary risks.
***No central authority also means no one to vet out scammers and other bad apples.  Please do your homework on any entity before signing a contract or giving them your money.
**** The offer for free development and support is limited to merchants who have a physical retail presence.  We will still assist web based merchants with shopping cart integration etc, but the offer is primarily intended to help offline retailers accept OpenPay & Bitcoins as painlessly as possible.

Oh no, you just *had* to go and say BSD is more secure than Linux!  That caused epic flamewars, back in the Silver Age of Bitcoin (ie last summer).

Good thing that jgraham isn't around to hear about it.  He'd have a conniption fit.  :D

I have crossposted this onto the bitcoinj mailing list as I sure they will all be interested.
More technical/ API details please !
:-)

Actually I prefer Linux to BSD myself.  But the CFS attack against AES  is specific to linux and it's potential impact cannot be discounted.  It doesn't necessarily require root privileges to execute and can result in the full recovery of the key in just a few minutes, which would be really, really bad, at least for that stage of the pipeline.
OpenBSD is the only recommended platform for deployment at the moment, although I don't see a problem with a properly secured linux such as SELinux so long as the kernel isn't running CFS.

I have been reading some of your earlier posts and this is a very interesting project.
(I don't understand all the POS protocol but then the software stack will hide a lot of that)

I presume that you will initially be concentrating on magstripe for the North American market ?
I am in the EU and it is all Chip n Pin over here now - I honestly cannot remember the last time someone swiped one of my cards.

That's good, the reference implementation is built on top of bitcoinj.

I've already documented quite a bit of the technical details in another thread on this forum, but I'll explain how it works here in a shorter summary.

There are 2 basic versions of OpenPay, these are EMV (chip & pin or NFC) and magstripe.

EMV is by far the easiest from a technical standpoint, we load a transaction signing applet onto the card along with a a standard bitcoin keypair with the private key encrypted with a strong encryption such as AES.  (Card here can also be any NFC device that is EMV compatible such as your cellphone)
The POS terminal queries the card and asks for a list of public keys (bitcoin addresses) that the card can sign for and hands this list off along with the amount of the transaction to the merchant gateway service.  The gateway service queries an exchange (assuming the merchant wants local instead of BTC) to convert the transaction amount from local currency to BTC.  Next the gateway queries a balance service which returns a list of unspent txouts for the addresses stored on the card.  The gateway then assembles the transaction and hands it to the card for signing.  The card tells the PIN terminal to prompt for a pin, this PIN is used as an oncard decryption key for the private portion of the key.  Assuming the key decrypts properly then the card signs the transaction and sends it back to the pos terminal/gateway.  This is now a standard BTC transaction that can be sent off to the network.  Since the gateway is the one crafting the transaction there is no need to wait 10 minutes for verification.
If the merchant is configured for clearing in local currency then after the network verifies the transaction then their service provider will execute a BTC sell to convert the BTC into the merchants local currency.  This could happen periodically say once a day, or really whatever the merchant and service provider agree to.

That was EMV, it's very straightforward, simple and direct.  All we need is to get an IIN for OpenPay from ISO and we can get that service operational in a few weeks.
The more complicated situation is the magstripe scenario.

Magstripe cards suffer from hundreds of different vulnerabilities and yet it's the most popular method of payment (at least in the USA).
We needed to come up with a solution that would be as convienent as magstripe while closing up the gaping security holes.
Also since magstripe is on it's way out eventually, we didn't want to invest in a lot of infrastructure that would be needed to produce magstripes with a custom IIN on them.

To do this we took a step back and analyzed all the known financial attack vectors and engineered a system that we hope is immune to them.

The first thing with magstripe is that ANY card will work, anything with a standard readable track 1 or track 2 data line ought to work.  Yes you can enroll your visa or mastercard, but you can also enroll an old gift card, a loyalty card from your favorite gas station, even your drivers license or library card.  We call this the "Any Card" method.  If it's readable in an MSR, then it will work for you.

When you enroll the card, the card info contained in the track is converted into an enrollmentID.  This enrollmentID is an SHA-256 hash of an SHA-256 hash of the number.  In addition to the enrollmentID your service will assign you a UUID, we've taken to calling this a userID, but it can be literally anything that uniquely identifies you to your chosen service provider (you can be your own service provider BTW).

The enrollmentID is hashed with the userID and used as a seed to an ecdsa key, the private portion of the key is discarded at this time and the public portion is used to calculate a public bitcoin address.
This way no bitcoin private key is ever stored.

Finally the stock enrollmentID is used to calculate an AES key which is used for encrypting traffic on the messaging system.

Now let's see how this comes together from a POS perspective.

Jimmy swipes his card at the POS terminal and selects OpenPay as a tender type (just like he might select credit or debit).
The card number is passed from the POS terminal to the merchant gateway.  The gateway is connected to the OpenPay network which is an XMPP based onion routing network.
The card number is used to generate an enrollmentID and an AES key.  A request for payment is generated by the gateway, and encrypted with the newly generated AES key.  It is then timestamped (default TTL for messages is 5 minutes) and handed to the messaging service.  All the messaging service does is relay any received messages to all contacts in it's contact list.

Eventually Jimmy's service provider (which could just as easily be software running on his phone, as it could be a separate company) pickups up the message via it's messaging service.  All incoming messages are routed to the authentication service which tries exactly once to decrypt the message using all the AES key's it's in charge of.  If the message decrypts correctly then the authentication service begins authenticating the validity of the request using one or more authentication modules.
Planned authentication modules include SMS, XMPP, hardware key based 2 factor, and static PIN.  There is also the possibility of accepting PINless transactions, but that's up to the service provider and the user.

Jimmy was configured for SMS so he receives a message containing a PIN and enters that into the pin pad.  The message follows the same path as before and it ends up at Jimmy's service provider.

From here the path is essentially the same as with EMV, a public key is returned, a list of unspent transactions is queried and used to build a BTC transaction (all using different modules running in their own memory space), finally a transaction is constructed and sent to the signing service along with the enrollmentID and the userID.  The primary difference being that with "Any Card" the signing service is residing on a server somewhere and not on the physical card.  Also the signing service doesn't actually have access to any private keys, unlike EMV where the keys are strored on the card itself.  The bitcoin private key is reconstituted on the fly using the enrollmentID and userID and is then used to sign the transaction.  The signed transaction is then sent back to the merchant gateway, which hands it off to the merchants service provider for validation.

I know it sounds complex, but the implementation is actually pretty simple.  It's more or less a matter of who does what at what stages of the pipeline,
I'll keep everyone informed here as the various modules & services are completed, enjoy!

EMV issuance requires a formal acceptance process and a formal organization.  That will be the purpose of the Open Payment Alliance to advocate and move that process along.
The Open Payment Alliance will benefit from the credibility of it's member base.  As the member base grows so too will the momentum behind it.
Technically it's no problem, but administratively it's a bit of a nightmare.  My guess is they will both go live about the same time though. ;)

Let me know what I can do to help.
With MultiBit being written in Java there is an obvious synergy between the two projects.

I just love the idea of bridging together the EMV network and the bitcoin network.

Thanks for the offer!

There are a few things.

First off the documentation as it comes along will be written in english, but will need to be cleaned up and translated.  I noticed MultiBit is available in various languages, if you have translators that would like to help with the translation effort that would be great.
Second, your website is clean and looks really good.  Would you mind seeing what you could do for the Open Payment Alliance website?

Thirdly, we've been talking about an app for self issuers (people who want to self bank) and retailers such as check cashers & money changers (retail bankers) who may wish to issue & enroll their customers onto the network.
MultiBit looks like it might be a good place to implement that type of functionality.  OpenPay transactions shouldn't be too difficult to integrate into multibit.  We should explore that path once the reference implementation is complete.

RE: languages
The crowdin.net framework that is used in MultiBit is very easy to use and set up. For open source projects it is free. Recommended. I can certainly mention it to the MultiBit translators but it very much depends on their overall interest in the project as to how much time they have free.
The secret with internationalisation is to start with property files for UI elements right from day one as it is a (very boring) task to retrofit it afterwards.

For open source projects I think there is a limit as to what can realistically be translated (due to manpower and money constraints). For MultiBit I just concentrate on the UI being localised - the help and documentation is all in english and, realistically, I would expect that to be the case for the immediate future. As all the translators time is donated, to localise 400 phrases is 'doable' but no-one will translate a 10,000 word document for nothing.

RE: website
The MultiBit website is pretty much all static HTML and thus pretty easy to copy and change. If you want a more dynamic website it would not be a very good starting point - it is basically handcraft HTML and CSS. I am not sure I would want to do the upkeep of the whole of *another* project website but would be happy to contribute to get it started. Do you have a domain and somewhere to host it ? I can certainly 'clone' the multibit.org website and then we can start reworking it.

RE: integration of enrollment and self issurers.  I think there is potential there definitely.  MultiBit is aimed for new bitcoin users so it might end up better to fork the code and rebrand it as something OpenPay. MultiBit is all opensource (MIT licence). We can see how that pans out - it primarily depends on what user storys you have to implement. Certainly using/ reusing the maven build and the installer work would save you a lot of time.

You might also want to start up a Twitter feed for your project as that is quite a good way to keep everyone informed on progress.

As I understand it, soft marketing ("presence") is fairly important for this project as you want to have enough of a critical mass that retailers and equipment manufacturers want to include OpenPay functionality by default on their smart card readers.

@Isis

Hey. As a non techie it all sounds very interesting even allowing for my limited brain capacity. The sort of thing that you know needs to come along in order for Bitcoin to evolve but have to wait patiently for the clever people to come up with.

Re: the insurance. How does that work? Does the network take a fee as an insurance premium?

Also, if this or a similar project acts as a gateway to a wider audience for Bitcoin it would be a good opportunity for those involved to get together and work on a better visual identity that projects a more suitable image of the technology than that damn coin.

In regards to translations, Bitcoin itself uses Transifex.com (https://www.transifex.com/projects/p/bitcoin/resource/tx/). Looks like a good platform, and it's free for open-source projects.

So I could just use ANY of my credit cards (Master, VISA,..) and do not need to have heard of bitcoin before in order to use it right?
So ANYONE with a credit card could just go up to a merchant that uses your network instead of the traditional bank ones and without even knowing pay with his/her credit card?

Pls correct where wrong, thx

Openpay is just what Bitcoin needs

Watching... awaiting the URL!

Sounds great. Will be following your project closely. Let me know when the "Shake Down" phase begins... bitcoins or not I would love to test your security.

The way I interpret the OP, you would be able to swipe a bitcoin card? at any merchant that allows visa/mastercard paypoints and online gateways, please correct me if Im wrong Isis.

This all sounds great to get bitcoin moving into the "real world".

That's not quite correct. 
OpenPay's primary purpose is to allow the spending of bitcoins in meatspace. 
Most merchants probably don't want to be stuck with large quantities of bitcoins, similar to how a US merchant wouldn't want a bunch of Euros sitting in the til, nor a European merchant want to be saddled with a bunch of USD.

Therefore bitcoins in this scenario are being used as a common interchange currency.
The merchant would have an exchange rate of BTC/Local, this exchange service would be provided by whomever setup their merchant services account.
If the customer has an account with funds denominated in local currency, then his/her provider would also provide an exchange service for the local currency amounts in excess of their BTC balance.
Multi-denominated accounts are also a real possibility, but it's just up to the implementer's and service providers.
So in a nutshell at least 1 and possibly 2 or 3 conversions are going on.
First the merchant needs to convert his local currency based transaction amount into BTC.
Next the customer may not have sufficient BTC in his/her account to cover the transaction and may wish to buy some BTC so they can complete the transaction.
Finally the merchant will probably wish to have the BTCs they have earned throughout the day converted into local currency, that would be conversion 3.
All of these conversions would be handled by exchanges that wished to join the OpenPay network and offer these services to their customers.
I'm working on a gateway (released separately), that will work with MtGox, but it's unofficial.

Back to the card thing.
For the magstripe option you can use any card you wish that has track2 data encoded on it.  It doesn't need to be a mastercard, visa, it can be an old expired gift card or just about anything else with a stripe on it.
The card just serves as an enrollment identifier and is used to identify you to your service provider (bank, credit union, eWallet service, even an app on your phone). 
By definition you would need to know about bitcoins to enroll right now, but it is possible that service providers may come online that never actually mention bitcoins, and never denominate accounts in BTC.  I don't like that idea, but how the service providers run their business is up to them.

Mostly you're correct Clipse.  Depends on if you're talking about EMV or AnyCard.

With the EMV option it's completely compatible with the EMV standard and any place that takes NFC or Chip & Pin based EMV payments.  However we will need to acquire an IIN from ISO first and that's going to take some time.
Also EMV isn't a popular option in the US and there are lots of merchants that are magstripe only, hence the need for the "AnyCard" payment option.  With AnyCard, the merchant will need to have their payment terminal re-configured to allow OpenPay as a method of payment.  This is why the offer of free custom programming for merchants that want to begin accepting OpenPay.

That's exactly correct. 
Every transaction originated from the reference software, has a small fee of 0.01 BTC, half of the fee goes to the Open Payment Alliance to cover operating expenses, the other half of the fee goes to the deposit insurance program.

The purpose of the deposit insurance program is to allow people to get their money back should their service provider encounter some unforseen difficulty. 
If you are running your own provider dealing with your own funds, there is no need to contribute to this fund (it's pointless, why would you rob yourself) so you can just disable it. 

However for providers that wish to carry the OpenPay logo and show the "Deposits Insured by" logo, it's mandatory. It's basically a free value add for the provider and gives them a new no-cost tool they can use to market to their target audience. 

The fee goes to a completely offline address that can only be accessed by a committee comprised of members of the Open Payment Alliance and these committee members would be elected annually by the member body. (Which reminds me we need to start having nominations for committee members soon).

If there is an event, a provider would file a claim (or if they were shutdown the individuals affected could file their own claims), the validity of the claim would be vetted by the committee and funds dispersed to the effected parties.

To some extent this program does run on the honor system, but it's assumed that if you go through the steps to join OPA, then you'll abide by the terms and conditions of it.

The deposit insurance program came about from discussions we had in the beginning with several merchants that were interested in accepting Bitcoin for payment. 
This was after the linode issue and right before the first bitcoinica break in, about this time Tradehill and their problems were mentioned as well.
The consensus was basically that for merchants and consumers to really feel comfortable with bitcoin there would need to be some sort of deposit insurance that was completely separate and independent from the service providers.
Thus we came up with the idea of making deposit insurance a feature of the network and to have the insurance program managed by the operators of the network instead of the service providers.

Source code is being released daily and is nearly complete.  Each module should be able to stand-alone.  I need to document each service, but if you can read Java code you should be able to mostly get a deployment going now.

The sources can be downloaded from github...
https://github.com/openpay/OpenPay

Anyone with Java experience is welcome to start giving more eyeballs to the code.  I should have a running deployment for burn in & shakedown by the end of the week.

Enjoy!

I don't understand why each module should be able to stand alone? That makes no sense, I am going to use the chat but not the rest. Also it makes more sense to do one version that is a client version, and one that is a server. Everything is together kinda makes no sense. Also you need more comments, also you need to tell people to org.jivesoftware.smack library in the readmd. Why you using XMPP, why not just use sockets to send around the information?

@OP

I am skeptical about the EMV part.
In Europe, a POS terminal must be PCI PED compliant, meaning neither Visa/Mastercard nor any bank will allow the POS to install a new module, specially a bitcoin module.

The implication is that the merchant needs to get a separate, openpay-enabled POS terminal and hook it up to her checkout system (expensive proposition) OR ask a value add reseller to install the OpenPay module in the existing POS (also an expensive proposition).

Therefore I fail to see where this scenario improves on the merchant simply integrating a bitcoin acceptance feature (essentially currency, conversion, QR code display) on said checkout system.

What I do see is the user experience of a customer carrying the card you describe: if the merchant is equipped with the openpay-enabled POS (that the big if) the customer can make a partial redemption of his bitcoin balance to settle his purchase transaction, then reload his card as needed.

In a nutshell, the card makes sense only if you can get "free" access to the POS terminal.
A project that entails having merchants putting money in yet another POS terminal or another POS software is doomed to wait a long a time before gaining a large acceptance.

Each module should stand alone because they will be running on their own server, in their own memory space, isolated from the rest of the system.  
This breaks a whole bunch of attack vectors, you can't just compromise 1 machine or 1 service and have anything of value.
Furthermore, the reference implementation is just that, a reference for building your own.  We want people to take what we have, slap their business logic onto it and get going, but the fact is most service providers will probably want some serious customization for their own offerings.  Having each module stand on it's own allows a company (or person), to replace a small chunk of functionality at a time, test it out and ensure it works they way they want it to before moving onto another chunk.

As for XMPP...
XMPP is only used for network communications between deployments.  XMPP was chosen because it's clean, simple, extensible and fast.  With XMPP, multiple deployments can receive and process the same messages without a bunch of excess configuration.  For instance if I am running a service provider I only have to publish one address, openpay@mydomain.com and payment requests will automatically be broadcast to all of my deployments.

Also securing jabberd is a known quantity, whereas handrolling a messaging protocol along with a model client/server implementation has the potential to introduce new vulnerabilities.

Inter-module communication is handled using SSL and sockets.

In regards to comments, you're correct the code needs more of them. In the modules I'm committing tonight I've tried to be much more explicit.  I'll get a tidy pass in before we start burn-in and shake down to go through and clean it up.
You'll also notice I'm missing unit tests, I'm probably going to end up paying for that in the end.  Frankly I hate writing JUnit tests but it does need to be done.  I'm considering adding JML as well.  

Again this will be done during the tidy pass, but it's exactly the type of reason we have open sourced it.

You are correct payment terminals must remain PCI compliant and that does generally mean it is locked down to some degree. 
There will be merchants who will need to invest in new hardware/software to process OpenPay transactions, and we have a plan to deal with that by working one on one with merchants & their service providers to minimize the impact as much as possible.

The piece of the puzzle you are missing here is that PCI compliance for a payment terminal means that it is running a locked down and signed firmware from the merchant service provider or the manufacturer. 
Switching providers allows the merchant to load (or have loaded) new firmware from their new service provider.  Fortunately we are working with one of the largest makers of POS terminals, to ship their new products with OpenPay EMV & AnyCard enabled by default, so I doubt it will be much of an issue.

Also I'm not sure about PCI compliance requirements in Europe but I assume they are universal.  I do know for certain that state side merchants who own their equipment are allowed to run apps on their terminals to support any payment type they wish.  The apps just need to be blessed or signed by either the manufacturer of the terminal or the merchant service provider.  Most terminal manufacturers make software development kits available and will either provide a signing key, or sign off on the app with very little hassle.

Either way, the change to method of payment isn't really an app in the strictest sense of the word, depending on your configuration, the capabilities of your terminal/gateway and whatever agreements you may have in place with your merchant service provider, the "app" simply routes the payment flow through a different network for processing.  Ideally this would be completely seamless for the merchant because most of the heavy lifting is actually done by the service provider.
Think about it this way, you can generally use Discover or American Express on the same terminal as you would use a Visa or Mastercard.  The only difference between swiping a Visa and swiping a Discover or AMEX is what network the transaction is run over.  Same deal with OpenPay.

Now back to the point about POS systems, i.e. the software running on the cash register, not the software running on the terminal.  The client who gave me the initial idea to pursue this, is one of the largest producers of this type of software in the industry.  While I can't disclose the client's name nor can I disclose who runs their software, I can safely say that at launch we will have 4 nationwide retailers on board and you will be able to use OpenPay to buy auto parts in the US, Canada, Mexico and get automotive services such as oil changes, break jobs etc.  We're actively looking for general merchandise retailers to sign up to accept OpenPay once the whole thing launches, each one will have unique needs and challenges. and OPA will actively support that effort by providing whatever support the merchant may need to get going,

I hope that's helpful!
 

I just noticed that I failed to address a significant part of your comment in my last post.

I already explained the reason for running stand alone.  And being able to use the "chat" but not the rest is precisely one reason for running everything as a series of standalone services.
As far as a client & a server version, this is a network protocol stack, client or server is a matter of how you bundle it, but strictly speaking there is no client or server it's all P2P with onion routing.

The product is currently built from the standpoint of multiple service providers all working to try and process a payment.

It starts with the merchant gateway application which talks to the PIN pad and Messaging.

Messaging then forwards the message to everyone it (or the service provider) knows about.  At this point you are no longer under the control of the service provider, but it is assumed that the customer has an account with some service provider somewhere (even if it's just an app on their phone) who is looking for a payment request message.

So at this time we've sent a message and it's "in the cloud" (my term for we really have no clue where it's at).  Eventually it get's picked up by the customer's service provider, i.e. their bank, their cellphone, whatever.  Some authentication takes place and then a standard bitcoin transaction is built, signed and passed back along the XMPP network.

Where it eventually lands in the lap of the merchant service provider, who notifies the merchant that the funds are good and then submits the bitcoin transaction to the normal bitcoin network.

So you see it's really more of a P2P model rather than a client/server model.
I hope that makes things a bit clearer!

Maybe you could contribute or come up with reasons that your suggestions are better, instead of tossing around insults?

You do realise the size of the task the OP is trying to achieve ?

The whole point of having a clearly defined set of services in a reference implementation is that each service can be engineered, or re-engineered, as required.

A reference implementation that successfully bridges the 'consumer payments' networks and the Bitcoin network would be incredibly useful.

Yes, yes, we all wish we were all better at the things we do. Lack of programming ability or not, isis is making a best effort attempt at bringing something great -- disruptive, even -- to merchants and consumers. And he's making it open source. And he has backed by large POS companies which will help overcome rather large hurdles. So whether we want to work on systems that allow for widespread, rapid adoption of ubiquitous multi-currency transactions or camming sites, is our own decision (with it's own, respective thread). I am truly sorry to hear other projects are taking your time.

Has OpenPay considered a percentage transaction fee (with a minimum of 0.01BTC, perhaps)? In my anecdotal experience, merchants abhor per-transaction fees. Just look at the success of Square (https://squareup.com/). By the way, partnering with square would be an enormous boon to OpenPay. Does your business partner compete directly with them? Square has (easily-modifiable) software and magstripe readers at many locations. I'm sure they would love to take their 2.75% without having to pay any of it to Visa, etc.

Sadly, I wish I had more to offer this project. Hopefully I can send a donation here in a month or two.

EDIT: VVVV  Okay, fair enough. I apologize if I was brash.

Thanks for the clarification. Not sure if you think this is something that should be built into OpenPay but, just thinking as an end user, it would be good to see a network managed escrow feature that tied in with courier tracking systems. E.g. Funds from purchaser held centrally in escrow which are then either automatically released to the vendor once the recipient has signed for their delivery or returned to purchaser if delivery fails. One trusted escrow service on a trusted payment network might do a world of good for Bitcoin's "trust" issues. Just a thought.

So,  do I understand the following correctly?

1. OpenPay is a system which merchants will have to have a specific setup to be able to take advantage of, although you are working with a large company to make it default for a large number of merchants.
2. It allows you to "enroll" a standard card (eg. gift card) which you can then use to send money to a merchant without paying the 3% (or whatever) fee.
3. It does so by having the card swipe perform a credit card system-style authentication and then creates a Bitcoin transaction from you to the merchant.
4. The merchant can choose to keep the money as bitcoins (in which case there's a deposit insurance program) or have it immediately converted into local currency (into their bank?), so the whole thing is essentially a BitPay equivalent for meatspace.

One question: where do the funds for the consumer to pay for the Bitcoin transaction come from? I understand that you can have a Bitcoin balance, and if you don't have enough you can automatically buy it from an exchange, but where is the value to do that stored, and how do you fill it up?

Yes you understand correctly.

As to the question about where funds for the exchange process are stored that would be at the customer's service provider.  Just like how your current visa card might tap your savings if you don't have enough in checking, the goal is for places such as MtGOX or whomever else wishes to participate to have an integration pathway between the local currency denominated account and the BTC denominated account.

Thanks!

This is one of those times I really wish I wasn't bound by NDAs.  Square is known to my client, they have worked closely in the past.  They aren't competitors and I believe they are aware of OpenPay already, that's all I can say about that topic right now.
The business side of things such as bringing on Hypercom, Ingenico, Square etc is being handled outside the scope of what I'm doing here, but yes it is being handled.

As far as charging a percentage fee, the fee is paid for by the consumer not the merchant.  Hence the fixed fee, however I have considered the implications of 1% fee with a max of 0.01BTC, this is basically the opposite of what you're talking about and the problem with it is that it doesn't provide enough resources to back the insurance program.  Charging a 2% or whatever merchant gateway fee like Square, PayPal or Authorize.net is a real possibility and would probably be an important source of income for those service providers, not having to pay any of that fee to the network is a real deal sweetener for them I imagine.  Don't forget though, that anyone can be their own service provider.  They just need to put up the infrastructure that they want to run and find someone else to fill the gaps.

For instance the reference implementation will include 2 service provider deployments, one targeted at merchants and one targeted at consumers. 

The consumer side will essentially turn their MtGOX account into a bank account.  They will have their BTC balance and their local currency balance.  As the need arises, bitcoins will be purchased to fulfill transactions.  This handled through an exchange connector I'm working on, MtGOX really has no part in it.  The connector is just automation service that works with their existing API.

The merchant side will feature a gateway application with another exchange connector which is also tied to MtGOX, this is used for clearing BTC balances back to local currency.  All a merchant would need is a MtGox account and the gateway app which includes, the messaging component and the exchange connector.  No other infrastructure would be needed for them.

Hope that helps!

The above explanation by Vitalik Buterin should have started this thread. I've been trying to figure out what OpenPay means, and this thread has made it really hard. I suggest a wiki article.

Actually, I think you're probably right about that.  If someone has the time to take that and put it into a wiki article I'd be much obliged, otherwise I'll do it when I have some time (not going to have time for a couple weeks though).

Hey Gweedo, I just wanted to take a moment and say thanks.
I decided to re-read all the forums topics regarding OpenPay, go back to my original design notes and compare everything.
Basically your rabble rousing forced me to have a nice long rethink of the way this whole thing is being architected, and I've come to the conclusion that you're probably right.  
It is a bit of a mess.  (I still think I'm right about XMPP as a back channel though)
No matter what we do here, we can't cover every possible edge case against an attack.

The current design, the one we've been talking about with multiple modules, separate services, hyper anonymity etc.  
It's totally overkill for what we're really trying to accomplish here.

It's too focused on the needs of service providers.  
Frankly if there are services to be provided the service providers can figure it out.  
What OpenPay needs to figure out is how to get bitcoins from cyberspace to meatspace as painlessly as possible.
Therefore I think a greatly reduced in scope, merchant & consumer focused design that allows for a simple yet secure deployment is in order.

Keep your eyes on the git repo, I'm going to create a new branch in the next day or two and take a completely different tact.

In the meantime, thanks for helping me design a Porsche instead of a Volkswagon ;)

One more question: if everything's done between the terminal and the card, which essentially functions as an independent Bitcoin wallet, in the EMV system, how can someone use the system with an exchange and store funds in local currency rather than BTC?

Are you sure that's a good idea? The paper in question references <a href="http://www.cs.huji.ac.il/~dants/papers/Cheat07Security.pdf">another attack that can be used to stealing large amounts of CPU time</a>, which apparently worked on the BSDs at the time of writing and could presumably be used to launch a very similar side channel attack on BSD systems.

Different things are going on.

Consumer HAS sufficient funds

#1 Card Swiped & Pin Entered
#2 Terminal handshakes card and gives PIN number to card.
#3 Card returns a list of public bitcoin addresses.
#4 Terminal sends those addresses to it's gateway.
#5 Gateway checks total balance by looking for unspent TXouts on the blockchain.
#6 Gateway puts together a transaction sufficient to cover the amount due.
#7 Gateway passes to terminal, terminal passes to card.
#8 Card signs the transaction and hands it back.

Consumer DOES NOT have sufficient funds.
Identical until step 6.  If the gateway cannot find sufficient unspent Txouts then a payment request is created by the gateway and passed to the card for encryption.

The payment request is then passed along the OpenPay network until it finds it's home or times out.
A BTC buy occurs on the exchange and the resulting TXout is sent back along the network to the gateway (the content is all AES encrypted and sent along SSL channels BTW).

Now we go to the original step #6

Hope that makes sense!

I apologize for the delay in release.  A young couple who were close friends of mine died suddenly in a head on collision last Friday.  I've been in a state of shock.  They left behind 4 young girls.  The funeral will be this Friday after which I plan to put a whole new bundle of code into the git repo and we can start shaking it down for bugs.

My condolences, it's a shitty situation all around.

Any new developments on this one?

^
Any updates? I am super excited about OpenPay.

Hey everyone,

Thanks for your patience!  So here's what's been happening on the OpenPay front.
My contract to develop this had some wording in it, standard legalese along the lines of "All work performed under contract remains our sole and exclusive property."  So we had to have their legal department rewrite the contract to allow for the release of the code and the designs.
Anyways, we have the approval, it'll get the stamp of approval tomorrow and there will be a rather significant commit sometime in the next 48 hours.

Now one caveat...
The merchant gateway application was designed to interface with Pincomm from ISD (now ACI) and we couldn't secure the rights to release that portion quickly enough.  Therefore I'm working on an integration pathway with QuickBooks POS and the Inuit Payment Network since they have a readily available and open API.

Switching the gateway over to QuickBooks POS is one of the things that triggered the need for a new contract since QuickBooks POS is actually a competing product (in the loosest sense of the term).

So keep your fingers crossed and stay tuned.

For the record, there is no compensation for my time to develop the QuickBooks POS & Intuit Integration.  Therefore donations are gladly accepted ;)

There was another thread in which someone was asking about an app for Radiant systems. Do you have any experience with those, or do you feel that it could be an option?

Because of contractual obligations I cannot comment on that until after August 13th ;)

tick tick tick... :)

Tock! So is it Radiant systems?

Oh yes I remembered this.... It's the 13th, maybe today or tomorrow we can know? ;D

Big deal, he hasn't said anything for 13 whole days ... he's been more than generous with everything else he's put up, considering the possibilities of what this stuff could do for bitcoin.

Maybe you could put your spare code cycle time to good use and have a look at the github project? https://github.com/openpay/OpenPay (https://github.com/openpay/OpenPay)

(your signature says you are looking for java work ... go at it, dude.)

It's Open Source. If you don't work for free then maybe you should have to pay to complain .... or you could politely stfu?

It's also august, some people usually have holidays during this time :)

Nah I just had to wrap up some legal stuff and wait for an NDA to expire so I could start disclosing and discussing again.
All of that wrapped up yesterday.  Initial code drop of the new stuff is happening tonight. 
Sorry for the delay.

So for those of you who have been waiting for further updates here's what's going on...
OpenPay was commissioned by a company that has been a client of mine for a couple of years.  At first they were all for it, but when we started talking about setting up a new payment network and opening the source etc there was heavy opposition from upper management.  Mostly they were frightened that secret sauce recipes might accidentally be disclosed.

Eventually it was decided to just rescind the project and take it private.  This means I had to re-imburse the company for the time I billed them developing it.  Effectively I bought it out.  In the meantime certain sections of the code were determined to be touching on trade-secrets and those had to be re-implemented.

Finally what I ended up doing is doing a from scratch re-write of the initial re-write.
I apologize for being so tight lipped, it won't happen again.

Tonight you will see the merchant gateway module drop.  This will include a MtGox exchange connector, a balance check module, a module to connect the merchant to the OpenPay network and fallback signing module.
Tomorrow you will see an enrollment module and some pieces intended for service providers to connect an online wallet to OpenPay.

In the next couple of days you will start seeing modules for QuickBooks POS and other POS systems that will add OpenPay as a tender type.

Thanks again for your patience!
 

Yes there will be support for Radiant Systems.

Great. For me, this is probably the next most important project than bitcoin itself. Terminal whingers aside, any code that can do what you are proposing would be huge step forward, the enemy of function is perfection ... or something like that.

Big kudos to you "isis" for trucking along with OpenPay against the adversities. Too bad management couldn't get their heads out of the old ways of thinking to fathom the potential.

I'm doing a little investigation to see if I can bring some resources to bear on OpenPay.

Great work Isis !

Look forward to perusing your code.

What hardware will a developer need to get started ?

If you could recommend a card supplier and card reader that you know is reliable and usable on all of Win/ Mac / Linux that would be very useful. I am thinking EMV.

I imagine until we get an IIN it will have to be a testnet but I would like to get familiar with the kit.

If successful will this be cheaper than buying a prepaid VISA with Bitcoins?

Likely, though you would have to do a lot of the leg work yourself to get the cheapest rate (running your own bitcoin transaction server, setting up your card...).

More than likely there will be services out there that set things up for you and it will be close to the rate of a prepaid card.

I'm having some problems with getting the code up on github.  I think it's a failed merge, I get the feeling I'm missing something simple and stupid.  Anyways the code is ready to drop.  If you can't wait to get it from github shoot me an IM and I'll send you a zip.  In the meantime I just need to figure out what I'm doing wrong with this commit.

Sincerely,
Isis

p.s. Thanks for all the props to all the supporters out there.  It keeps me motivated to keep working on the code.

p.p.s.  I'm setting up a test gateway on AWS, will post a link to it as soon as it's up.  The test gateway will allow you to perform real transactions without all the headache of setting up the entire system locally.  Since no information is actually stored at the gateway I don't see any sort of security issue putting it on AWS, but if anyone finds something let me know and I'll either fix it or take it down.

First time back to the forums in months, happen upon this thread! Exciting things, I haven't looked at the code (or lack thereof, given your recent hiccups), but I'm cautiously optimistic about this thing.

@Isis,

My gitfu is not great, so I have a little cheatsheet for when I am committing into bitcoinj. I thought it might be useful to you in your merging:


UPDATE
Ensure local repo up-to-date with remote bitcoinj target:

git remote add bitcoinj-upstream https://code.google.com/p/bitcoinj/
git pull bitcoinj-upstream master


REBASE
You can rebase onto master like this:

    git checkout -b new-branch-1           <<< You will probably already have a branch you are trying to merge so won't need this.
    git fetch bitcoinj-upstream               <<< Fetch upstream bitcoinj to local repo.
    git rebase bitcoinj-upstream/master  <<< Work out differences of local to target upstream

Then you can squash commits with:

  git rebase -i bitcoinj-upstream/master

which will allow you to interactively choose commits to squash. Handy to squash multiple commits into one so that you can see them all together.


WHITESPACE
git show <commit hash>

or just :

git show

for the current commit. Gives very useful list of all additions and deletions.


COLOR
Very useful to see adds/ deletes/ whitespace in color in a console:

git config --global color.ui true

IRC chat for this project on irc.freenode.net, hashtag

#openpay

webchat link
https://webchat.freenode.net/?channels=openpay&uio=d4 (https://webchat.freenode.net/?channels=openpay&uio=d4)

Great idea, thanks!  I'm in as Isis, realname is someip.slkc.qwest.net

following.

So I think I've found the problem with git merge, it appears to be related to credentials.  I changed them at github after my last laptop burned up, then restored the project directory from a backup and I think it had the old credentials.
Has anyone experienced a similar issue in the past?

I want to take a moment and thank everyone who has been helping with this project so far.
Even without the sources on github those of you who have been requesting a zip via email or irc, or IM have been a tremendous help.
Thanks!

Ok I wanted to pose a quick question to everyone interested in the development of OpenPay.

One of the most important components of OpenPay from the perspective of a merchant will be the exchange connector.
The exchange connector's job is to receive quotes from an exchange (default is mtgox), and convert local fiat prices into btc amounts so the transaction can be priced appropriately.

Up until now I had been using the "last price", but the recent volatility makes me question the wisdom of that decision.

I'm considering using the Volume Weighted Average Price instead.  I say this because I don't expect a merchant to sweep each transaction, but simply to run a single sweep at end of business day.  I have a hunch this would provide a more stable & predictable sweep at the end of the day.

Thoughts?

Get bid side quote of market depth from mtgox, and then calculate how many bitcoins you would need to sell to get X amount of USD.

I think you can get MtGox market depth data from Tim Molter's XChange (https://github.com/timmolter/XChange/wiki) - this gives you a nice Java object model to use.
I use it in MultiBit to get the exchange rates.

Ya know, that is actually perfect.  Wish I would have found this one before I rolled my own a few times.  Still I think I'll switch over to it, it already has everything I wanted from an exchange connector right out of the box.

Thanks!

Considering BTCUSD's volatility, it may make more sense to sweep each transaction (or each ~40$ once small transaction amount to that much). The exchanges, MtGox for example, don't have per trade fees so I see little reason not to? BitInstant's recently-announced debit card (https://bitcointalk.org/index.php?topic=101838.0) -- which by the way, overlaps with OpenPay to a small degree -- converts BTC on the spot (ie, instantly for each transaction).

On the other hand, if the exchange gateway (is this the right terminology?) has both buyers and sellers of BTC at the end of the day, it could use whatever it wants for the BTC price, e.g., the 24hr average. This is what the clandestine Silk Road does, base prices off the 24hr BTCUSD average and has plenty of BTC coming in and out to balance large BTCUSD swings.

BitInstant has a good idea, but it's not the same thing that OpenPay is trying to achieve.  What they are doing is a single provider btc to mastercard gateway service.  It's admirable and cool, but it's not the same thing that OpenPay is trying to achieve.  You can do pretty much the same thing today by getting a pre-paid debit card from Walmart or wherever and then going to btcpak.com and trading some bitcoins for a money pak to load on the card.

With OpenPay the goal is to establish an entirely new payment network that uses the bitcoin network & currency, allowing direct spending of your bitcoins in the real world without relying on a third party eWallet service if you don't want to.  In otherwords OpenPay's goal is to keep you in control of all your bitcoins, always.

The way we plan to do this is to eventually get an IIN and allow anyone to issue EMV compatible cards that function as little portable transaction signing engines.  However obtaining an IIN from ISO is a long drawn out process with lots of paperwork. 

So in the meantime we are using a system that generates a keyset from any Track 1 or Track 2 compatible card + pin, the signing to be done by the users choice of either a service provider or a standalone payment gateway application.

I hope that clarifies the differences. 

p.s. I'm mostly posting this info for the umpteen million people that have been emailing me since the story broke on reddit and slashdot asking the same questions ;)

Thank you for the clarification, although I realize that behind-the-scenes OpenPay is completely different than BitInstant's proposed credit card. Perhaps I should have emphasized "to a small degree." Where they overlap is as a business/consumer solution for spending BTC at stores and in both of their codes they need to convert small amounts of BTC to USD at a known exchange rate.

Could you explain the downsides of not having an IIN and not being able to issue EMV compatible cards? Does the "anycard method" just require more extensive POS re-programming? Thanks

You know that's a good question.  But in a word, it's for future proofing.  The down side of not having an IIN is that you are not able to issue EMV compatible cards. In the USA, EMV is nearly unheard of however elsewhere in the world this is not the case.  Furthermore s time goes on, the magstripe infrastructure will be going away.  As it stands now there is a real push from Mastercard & Visa to shift liability for chargebacks 100% on to the merchant if the transaction is magstripe.  This is a real incentive for merchants to begin dumping the magstripe infrastructure and move to Chip & Pin systems or NFC based systems.

Since "AnyCard" piggybacks on a side effect of the magstripe infrastructure, it just makes sense to ensure that OpenPay has a future once magstripe begins to fade into the sunset.

There is one other critical difference between OpenPay AnyCard and OpenPay EMV.  That is, for a merchant to support OpenPay magstripe they will need to have a new payment type added to their terminal.  Credit/Debit, EBT, OpenPay.  For a merchant to support OpenPay EMV they shouldn't need anything added to their terminal since it's just a regular Credit/Debit transaction same as Visa / Mastercard.  Basically the goal being for OpenPay to become supported the same as AMEX or Discover, the only difference being which network it runs over and this is determined by the IIN.

The other day I had a very interesting discussion with the VP of my bank.
The bank already does currency exchange services and he has had several customers asking if the bank was looking into crypto currencies such as bitcoin.  He had only a cursory knowledge of it but we had a great lunch talking things over.  When we were done he told me to expect a call from the company that develops their forex software.

While this isn't strictly related to OpenPay, I thought I'd mention that bitcoin is starting to get some serious consideration from financial institutions.

Now for the OpenPay news.  The current software started making a bunch of invalid transactions in test so I've decided to simplify the design yet again.  I'm going to gut much of the functionality that's in the current Java implementation and instead rely upon the bitcoin rawtransactions api for most of the heavy lifting there.

Also I finally fixed the git commit issues, so you should be able to pull down sources now.

Enjoy!

I've removed my previous post because it caused mass confusion.
I'll just keep my updates on the progress of OpenPay in this thread.

Anyways hey everyone!  OpenPay has been nominated for project of the month!
https://bitcointalk.org/index.php?topic=108803.0

Hey folks,

OpenPay is "mostly" there now.
The final piece of the puzzle is signing the transaction.

How we want to do the signing service is a bit of a struggle for me. 
Programmatically speaking it's simple but something somewhere is going to have to sign the transaction.

I'm of two minds on it, either one or both of these are possible.  But I'm ONLY writing one or the other and I don't want to end up in a position where I'm the sole maintainer.

One possibility is an app you carry around with you.  I have an android phone, an extension to one of the existing android wallet apps is the most natural thing since it doesn't require infrastructure to be present.  Just a listener on the phone sitting there subscribed to a pub/sub messaging network.

The other possibility requires infrastructure but would allow confirmation via sms, that actual signing to be done by a service.  This service could be running on your computer, or it could be hosted by your favorite eWallet service.  Same basic pattern though.  A listener is subscribed to receive messages requesting payment.  When the message is recieved some authentication is performed such as an SMS message or email, when the reply is recieved the transaction is signed and sent back.

So the question at hand is do we want yet another android wallet app, or do we want a standalone service that could be integrated into someone elses infrastructure?

Let me know and we'll get the final piece of the puzzle in place and get this puppy shipped.

Are you going to make an interim commit to github?


Share the load and we might be able to help .... at the moment your are just talking in abstracts and it makes it difficult to follow along.

OMG, that's embarrassing.  I never thought to check that my commits were going through.

Most folks have just been emailing me for the binaries.

*facepalm* do you even know git? Cause if people are submitting pull request are you going to know how to safely merge them into the master? Do you know branching so you can have a development, master, and production branches with tags?

not helpful.

Actually very helpful, how will i submit my fixes when i find bugs ;) and how will people know what is the dev build, and not production, or master build? And with tags you will be able to find what version of the software you want. So now tell me how it is not helpful again :) ok

Yes I do know how to use git.  Everyone thus far that has been helping has stated explicitly that they have no development experience but are willing to help test.  That translates into binary builds since I don't have a lot of time to help others figure out their dev environment issues.

Right now the software development aspect of this has been a one man show.  I've been commiting changes to my local repo but simply spaced on comitting to the master branch on github.

If it were a situation where there were other developers involved I probably would have either noticed it or at least had the stale repo issue brought to my attention much sooner.

So any ETA on when new source might be up on github?

Thanks.

There seems to be a lot of developers interested, and I am trying to help you so don't get a ton of merge conflicts and everything is nice and tested, before people use it, but you seem to know everything so I guess I am not needed. BTW make sure you using JUNIT to add test.

I would keep it simple.
Write a utility that people can run in a terminal window on their home computer that signs the tx.
Don't bother with a fancy UI or anything. Just write the reference implementation.

That way you are inviting people to take your code and rework it up to something fancier/ more integrated/ Android smartphone app.

So, when will the "Shake Down"-phase commence? I got /r/netsec (http://www.reddit.com/r/netsec/comments/w8ipz/payment_processor_openpay_testing_their_system/) all worked up about it, I sure hope it will become reality. :)

@Isis. Can you recommend a reference EMV USB card programmer and a brand/ card type that I can buy to try things out ?

There are bound to be various differences here and there so it would be good to have a reference hardware platform to work with.