[ANNOUNCE] OpenPay - Entering Burn In, Shake Down & Alpha Test phase.

[isis]

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.

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!

[1714026075]

1714026075

[1714026075]

1714026075

[gweedo]

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?

[Boussac]

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

[isis]

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?

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.

[isis]

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

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!
 

[isis]

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.

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!

[rjk]

You do know you can run each of those things isolated yet in the same application.

XMAPP is very wrong for this type of application, sockets with self signed SSL would be the best.

P2P and client/server models can do the same thing just like bitcoin is P2P yet it has a server and client model, with nodes.

I am disappointed that this cool project doesn't have a higher caliber of programmer running it.

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

[jim618]

You do know you can run each of those things isolated yet in the same application.

XMAPP is very wrong for this type of application, sockets with self signed SSL would be the best.

P2P and client/server models can do the same thing just like bitcoin is P2P yet it has a server and client model, with nodes.

I am disappointed that this cool project doesn't have a higher caliber of programmer running it.

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.

[streblo]

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

[bangers]

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

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.

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.

[Vitalik Buterin]

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?

[isis]

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!

[isis]

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

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!

[ripper234]

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!

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.

[isis]

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!

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

[isis]

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?

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

[Vitalik Buterin]

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?

[makomk]

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

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.

[isis]

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?

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!

[isis]

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.