Topic: [ANNOUNCE] OpenPay - Entering Burn In, Shake Down & Alpha Test phase. (Read 19484 times)

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

So, when will the "Shake Down"-phase commence? I got /r/netsec all worked up about it, I sure hope it will become reality.

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.

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.

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

Thanks.

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.

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

not helpful.

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

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.

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.

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.

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://bitcointalksearch.org/topic/re-bpm-bitcoin-project-of-the-month-2012-11-nominations-108803

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!

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.

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

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

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

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!

I think you can get MtGox market depth data from Tim Molter's XChange - this gives you a nice Java object model to use.
I use it in MultiBit to get the exchange rates.