Topic: [ANNOUNCE] OpenPay - Entering Burn In, Shake Down & Alpha Test phase. - page 3. (Read 19448 times)
August 14, 2012, 08:17:24 PM
It's also august, some people usually have holidays during this time
August 14, 2012, 07:51:35 PM
The dude hasn't ben active on the forums since August 1st so I doubt we will hear anything
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
(your signature says you are looking for java work ... go at it, dude.)
I don't work for free pay me and I will work on it.
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?
August 14, 2012, 08:38:23 AM
The dude hasn't ben active on the forums since August 1st so I doubt we will hear anything
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
(your signature says you are looking for java work ... go at it, dude.)
August 13, 2012, 11:12:12 AM
Oh yes I remembered this.... It's the 13th, maybe today or tomorrow we can know? 
August 13, 2012, 03:21:23 AM
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...
August 09, 2012, 12:59:01 PM
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...
July 29, 2012, 10:21:21 PM
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
July 29, 2012, 10:03:42 PM
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?
July 29, 2012, 10:02:23 PM
For the record, there is no compensation for my time to develop the QuickBooks POS & Intuit Integration. Therefore donations are gladly accepted
July 29, 2012, 09:54:31 PM
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.
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.
July 27, 2012, 12:33:37 AM
My condolences, it's a shitty situation all around.
^Any updates? I am super excited about OpenPay.
July 25, 2012, 12:46:48 PM
Any new developments on this one?
July 18, 2012, 12:59:50 AM
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.
July 17, 2012, 05:17:19 PM
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.
July 13, 2012, 07:55:39 PM
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!
July 11, 2012, 03:48:44 PM
**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 http://www.cs.huji.ac.il/~dants/papers/Cheat07Security.pdf">another attack that can be used to stealing large amounts of CPU time, 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. July 11, 2012, 09:53:10 AM
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?
July 10, 2012, 09:10:29 PM
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
July 10, 2012, 05:43:07 AM
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?
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).
July 10, 2012, 01:28:29 AM
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?
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.
Jump to: