Topic: [Pre-Announce] OpenPay, use your bitcoins at any merchant that takes Visa! - page 4. (Read 6511 times)

That is a bad analogy. 


I have $1000 cash. I pay merchant for hotdog with a $5 bill my max loss is limited $5 - value of hot dog.
If I pay with cash I only need to trust the merchant until I get change.

I have 200 BTC on my card.  I pay a merchant for hotdog  and my max loss is the entire wallet.  Not just the current wallet value but any value it may have at any point in the future.
If I give merchant my private key I must trust him FOREVER.   Hell Merchant could just record private keys as a rainyday fund.  When he runs into financial trouble he robs 10,000 customers instantly.  Due to the nature of Bitcoin once 2+ parties have the private key proving who made a tx becomes impossible. 

You know those are exactly the types of questions I need to have people asking.

There are various modes of operation available in the EMV standard, the two we are interested in are mag stripe (swipe), and chip & pin.

Magstripe is primary in the United States and that's why I made a provision for it in the design.  It's also going to be the biggest pain to implement (It will require convincing ISO/ANSI to issue us an IIN among other things) and also represents the highest security threat to your wallet since the encrypted private key along with the key to decrypt it MUST be divulged to enable the transaction to process.

Chip and PIN is much easier to deal with, this is because we can do the whole thing "on card" and never divulge the private key.  All we really need to have is a list of the transactions that the card has been involved in.  Since we cannot store the entire blockchain in the available space of the card, we can just ask the gateway for a list of transactions involving the wallet which have occured since the last time the card was used. The card itself can then craft & sign the transaction based on this information.  Once old transactions have been completely spent, the card can delete them from it's memory. (Premature tearing is likely to be a significant problem here)

Chip and PIN also opens up a third option I'm exploring. That option would be a constantly changing PIN sent to your cellphone each time you use the card, but that will require infrastructure that isn't in place and can't be put into place without significant adoption of the Chip & PIN version of OpenPay.  It would be trivial to implement once we get past certain hurdles, but requires externalities & some centralized processing and identity management.

Nevertheless, under either scenario it's best to understand that this is meant as a "spending wallet", you shouldn't leave it laying about, and you shouldn't keep more funds in it than you can afford to lose.  You keep your local currency in a bank, and only carry cash on you when you need to spend it.  An OpenPay card should be thought of the same way, only load it with the funds you need for right now (a day, a week whatever) and leave the rest in your bank (even if the bank is just an offline bitcoin wallet somewhere).

Bitcoin is irreversible just like cash, and the purpose of this whole exercise it to allow you to take it offline and spend it at your local merchant, like cash.  If you would trust this merchant with your cash or credit card, you'll be able to trust them with your OpenPay card.

Wait what?  Why use a smartcard then?  If both the pin and private key will be given to the merchant then the merchant can create any tx they like.

Buy a 0.3 BTC hotdog get home and find out 500 BTC tx was made emptying your wallet.   Oops.

Is the PIN encryption combined with some kind of provider based encryption, or is it standalone? If someone obtained the track data from a malicious POS or some other method, would it still be hard to bruteforce the private keys?

As I posted in the original announcement in "offtopic" here
https://bitcointalksearch.org/topic/btc-payments-coming-soon-to-a-store-near-you-88073

I've been asked by a client (Who makes POS software) to find a way to enable BTC transactions at the POS.
At present I'm working on getting the documents for the proposal into a publish ready state, which is itself a fairly big job.

The system will require some momentum to become adopted and I would like to ask the assistance of the community in spreading the word as it comes to life.  That's why I'm going to give the readers digest version of it here.

The crux of the concept I'm tentatively calling OpenPay (because it sounded like a good name), is to form a bridge from the online world of the bitcoin ecosystem, to the offline world of daily transactions.

When complete, you'll be able to spend your bitcoins directly (no intermediary organization is necessary) at any merchant, POS, ATM, gas station etc that takes Visa or Mastercard.

It's a card based system that will utilize an EMV compatible payment card (you probably already have one of these, it's sitting in your wallet or purse right now).

For OpenPay purposes the card will contain an encrypted private key (crafted in such a way that it matches track 2 requirements)
A 4 to 10 digit PIN would be set by you and would be the decryption key.  A standard wallet id would also be stored on the card for loading & refunding purposes.  For daily spends you would be able to handle the loading of the card through standard bitcoin means, or buy coins from your friendly neighborhood merchant.
 
Due to economies of scale, It's unlikely that people would want to purchase their own cards and all the bits and pieces to get it into a "ready to spend" state.  But cost issues aside, there is no real reason why you couldn't.  The cards themselves (any EMV compatible card) are between $15-$20 on the open market and the readers are about $100, but after that you really are your own bank.

It makes sense that card issuers would crop up around this, my planning anticipates that the primary issuers would be existing exchanges and banks that deal in BTC.

I will explain in more depth in another posting about the intermediate steps that occur, but in a nutshell the private key & wallet file are read by the acquiring software (same process as an import), which will then determine the balance, string together a standard bitcoin transaction, sign it and send it off to the network for completion.  (either the merchant will be running their own node, or their payment processor will be running one).

The plan also makes provisions for the merchant who desires to allow their customers to spend BTC, but who themselves needs to receive payment in local currency.  This will be a software setting of the reference implementation of the acquiring server, but would require the merchant to have an account with a company that provides exchange services, so they could run a daily settlement.  Again I'll go into greater depth on this in a few days.

That's the jist of it.  I'll be providing more details in later postings on the subject and will be posting all future developments in this thread, so please feel free to bookmark it.