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

[Garrett Burgwardt]

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

[1713505844]

1713505844

[1713505844]

1713505844

[1713505844]

1713505844

[jim618]

@Isis,

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


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

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


REBASE
You can rebase onto master like this:

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

Then you can squash commits with:

  git rebase -i bitcoinj-upstream/master

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


WHITESPACE
git show <commit hash>

or just :

git show

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


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

git config --global color.ui true

[marcus_of_augustus]

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

#openpay

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

[isis]

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

#openpay

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

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

[randy-waterhouse]

following.

[isis]

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

[isis]

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

[isis]

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

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

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

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

Thoughts?

[Serith]

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

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

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

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

Thoughts?

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

[jim618]

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.

[isis]

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.

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!

[streblo]

I say this because I don't expect a merchant to sweep each transaction, but simply to run a single sweep at end of business day. 
Thoughts?

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.

[isis]

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

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

[streblo]

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

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

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

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

[isis]

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

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

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

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

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

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

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

[isis]

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!

[isis]

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

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

[isis]

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.

[randy-waterhouse]

Are you going to make an interim commit to github?

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.

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.

[isis]

Are you going to make an interim commit to github?

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.

Share the load and we might be able to help ....

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.