Bitcoin Forum
December 02, 2016, 08:32:22 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 »  All
  Print  
Author Topic: [ANNOUNCE] OpenPay - Entering Burn In, Shake Down & Alpha Test phase.  (Read 17903 times)
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 09, 2012, 06:00:49 AM
 #21

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

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.

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
1480710742
Hero Member
*
Offline Offline

Posts: 1480710742

View Profile Personal Message (Offline)

Ignore
1480710742
Reply with quote  #2

1480710742
Report to moderator
1480710742
Hero Member
*
Offline Offline

Posts: 1480710742

View Profile Personal Message (Offline)

Ignore
1480710742
Reply with quote  #2

1480710742
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480710742
Hero Member
*
Offline Offline

Posts: 1480710742

View Profile Personal Message (Offline)

Ignore
1480710742
Reply with quote  #2

1480710742
Report to moderator
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 09, 2012, 06:29:18 AM
 #22

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!

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
July 09, 2012, 06:49:22 AM
 #23

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?

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
Boussac
Legendary
*
Offline Offline

Activity: 1173


e-ducat.fr


View Profile WWW
July 09, 2012, 01:16:56 PM
 #24

@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
Full Member
***
Offline Offline

Activity: 154


View Profile
July 09, 2012, 01:34:03 PM
 #25

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.

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 09, 2012, 02:09:53 PM
 #26

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




Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 09, 2012, 02:33:19 PM
 #27

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!

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
July 09, 2012, 05:15:30 PM
 #28

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

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
July 09, 2012, 05:34:10 PM
 #29

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

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
July 09, 2012, 05:37:51 PM
 #30

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

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
July 09, 2012, 05:45:04 PM
 #31

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

I realize the size of this project that why this cool idea has to have an amazing programmer behind to make it work.
So then he should just write some RFC documents then using code.


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

I can't contribute I have my own projects, if only there was more time in the day I would LOL, I am not insulting anyone, I just telling him and I can see he is not a strong Java programmer, and I am trying to point him in the right direction.

So anyone with a jabber client, can easily DDOS or fake flood a server with fake request that the server would see as valid commands.
P2P and client/server can be the same thing
Java has process builder and can spawn other processes.

I am still disappointed that a non higher caliber programmer is project leader, maybe he should start looking for a better project leader.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
streblo
Full Member
***
Offline Offline

Activity: 165


View Profile
July 09, 2012, 06:29:03 PM
 #32

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.

gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
July 09, 2012, 07:12:20 PM
 #33

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.

You completely misunderstood anything I have said in this thread. I think his idea is on point. The execution of the idea is very wrong and lining up to be a mess, where if he went and found a project leader who has experience leading open source projects it could be done greatly. I just am sad that this project is going in a direction that is very wrong and the code is a mess. XMAPP for communicating the commands, is a disaster and needs a real programmer to handle. Just like when bitcoins used to use IRC to find peers, that is asking to be hacked. Thank god they fixed that.

Second I am not the programmer or have any involvement of http://cam4btc.com other than another idea that I thought was a good idea, so get your facts straight. Right now I am working on 2-3 projects that would be more important then some kids trying to make a good idea that is over their heads. I think this project needs a real coder. BTW streblo go look thru my post, they pretty smart, and usually right about these things just saying.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
bangers
Newbie
*
Offline Offline

Activity: 16


View Profile
July 09, 2012, 10:31:41 PM
 #34

@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
Sr. Member
****
Offline Offline

Activity: 331


View Profile
July 10, 2012, 02:02:22 AM
 #35

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?

Argumentum ad lunam: the fallacy that because Bitcoin's price is rising really fast the currency must be a speculative bubble and/or Ponzi scheme.
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 10, 2012, 02:47:42 AM
 #36

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!

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 10, 2012, 04:27:04 AM
 #37

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!

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
July 10, 2012, 05:28:29 AM
 #38

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.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 10, 2012, 09:43:07 AM
 #39

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

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
isis
Full Member
***
Offline Offline

Activity: 154


View Profile
July 11, 2012, 01:10:29 AM
 #40

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 Wink

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
Pages: « 1 [2] 3 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!