OpenPay v1.0 [New Design, Requesting Comments]

[isis]

I've completed the new design of OpenPay and wanted to open a discussion on how I see it working.

As I said in my last post, the new design integrates much tighter with bitcoin itself.

Here is how it will work.

*** The information below has been superseded, please see my next post on this topic.  Leaving this part here for reference only***
Each message on the bitcoin network contains a "magic" value that identifies which network the message is for.
The current known magic values are 0xD9B4BEF9 for Main and 0xDAB5BFFA for testnet.
An OpenPay payment request message would have a magic value of 0x4F50454E (OPEN).

Bitcoin clients currently have a peer discovery mechanism.
Part of the discovery mechanism includes each peer divulging it's user_agent field.

An OpenPay enabled client would look for peers that have X-OpenPay in the user_agent field.
This is so existing clients such as MultiBit can say they are still themselves but with an OpenPay extension, eg user_agent="MultiBit X-OpenPay".

The merchant gateway would remain continuously connected to the bitcoin network and maintain a list of OpenPay enabled clients.
When a customer swipes their card an SHA256 of an SHA256 hash of the card used is calculated.   This is then used to create a private/public keypair.

****
This keypair is not intended for general use, it's only to prove that the customer handed the card to the merchant. It prevents a replay attack by an outside 3rd party.  But you would NEVER send funds to the address generated by the enrollment ID process, since the private key is transient but could be recovered, if the merchant were somehow compromised.
****
The merchant gateway then builds essentially a bog standard tx message with all fields blank except...

magic = 0x4F50454E
tx_in = The public key of the card as calculated in the previous step.
tx_out = A per transaction, unique payment receiving address and the amount to be received.

It would then sign the transaction as per normal using the previously derived private key.  (This will prevent replay attacks from outside listeners)

This is then broadcast ONLY to the nodes that identify themselves with X-OpenPay in the user agent field.
 
OpenPay enabled nodes would add a listener for messages destined for the "OPEN" network and when one arrives, they would check to see if they have the public key from tx_in in their regular bitcoin wallet(s).  if it doesn't have it, it will pass the message along to any other node identifying itself as OpenPay enabled.  Eventually it will hit something or expire out.

Assuming a listening node decides it is responsible for the transaction, it would rebuild the transaction, by

1. Changing the magic value to main.
2. Filling in the tx_in and tx_out fields appropriately.
3. Request a user validation of the transaction via sms, email, popup dialog or whatever other means are appropriate to the wallet (this is optional but strongly recommended)

4. Sign it and send it off.

It would send a copy of the message back to the originating node and another copy to the main network.

The originating node would then perform standard validations against the transaction looking for double spends.  If it finds none then the transaction is considered complete, it also forwards the transaction to the main network, and finallynotification to the merchants POS occurs as per normal.

All of this can be done with only minimal modifications to any existing bitcoin client.  

I think I've already figured out how to make MultiBit aware of OpenPay transactions. (Thanks Jim!)

Getting it into the Satoshi client should be fairly easy, I think the license allows for forking it, but frankly I'd rather see it go into the mainline.

The purpose of the change is to make  OpenPay support trivial enough that anyone who currently writes electronic wallet software could make it OpenPay enabled in a day or two of work.

Thoughts?

[randy-waterhouse]

Meaty stuff isis .... gonna take some ruminating.

As a first blush .... so it is going to piggy-back onto bitcoin network to broadcast "OPEN" tx requests that then get transformed into bitcoin Tx's by the targetted node that has the required keys to sign the bitcoin tx .. and then rebroadcast on bitcoin network proper?

Just a guess here, but I think mainline will resist this ... but should be enough incentive here for many users to adopt it regardless ( I wonder about how many "OPEN" enabled nodes you are going to need for security considerations)

[isis]

Meaty stuff isis .... gonna take some ruminating.

As a first blush .... so it is going to piggy-back onto bitcoin network to broadcast "OPEN" tx requests that then get transformed into bitcoin Tx's by the targetted node that has the required keys to sign the bitcoin tx .. and then rebroadcast on bitcoin network proper?

Just a guess here, but I think mainline will resist this ... but should be enough incentive here for many users to adopt it regardless ( I wonder about how many "OPEN" enabled nodes you are going to need for security considerations)

Good catch!

I just finished having a rather lengthy discussion about this in IRC.
As it turns out there is no need to create a secondary network, which is what the design above would effectively be doing.
As long as we look ONLY for clients with X-OpenPay in their user agent string, we can just craft a new message type and send it along only to OpenPay enabled peers.  This is the simplest most direct route IMHO.

Honestly I'm divided at this time between a totally custom message type, or just using the already existing alert message.  If an alert is not signed with the devkey, then most clients will just ignore it.  It then becomes trivial to tell the software, ok so it's not an alert from the devs, could it be an OpenPay message?  Then have it take action accordingly.  (see alert.cpp line 116 for the entrance point)

The question then becomes how do we ensure routing and hashing power are in place for OpenPay messages to get from their source to their destination?  In otherwords, if you aren't a merchant, or a consumer why would you bother wasting your bandwidth & cpu on processing these new "OpenPay" messages.

The answer turned out to be simpler than I thought.

From the beginning it has been stated that OpenPay would charge a fee of 1% for commercial transactions.  

This fee is used for a number of things, for instance if an exchange or other deposit taking institution chooses to participate, that fee will be used to back an independent deposit insurance fund to provide liquidity to their customers if they were to encounter a liquidity crisis such as a hacker absconding with the hot wallet, the government stepping in and seizing their bank accounts etc.
(Merchants will demand this feature; Because "Oops I'm a 17yo kid with big dreams who didn't understand basic security practices, but somehow have well connected billionaire friends." Isn't going to cut it when millions of dollars are entrusted to your care.)

In addition to deposit insurance, the fee also goes to cover the current operating expenses and future development costs of OpenPay, this fee is how we intend to pay for things such as the EMV card option (lots and lots of paperwork and lawyers involved there).

Transaction processing costs easily fall under the "current operating expenses" category.

Therefore, anyone who runs an OpenPay enabled node will receive a share of the OpenPay transaction fees in proportion to the time spent on the network.  For instance if we have 100 nodes running 24hrs, each day, each of those nodes would receive 1/100 (i.e. 1%) of that days transaction fees.  If you have a node that was only running 6 hours a day, you would receive 6/24th of 1/100 (e.g. 0.25%) of that days fees.  

We would keep track of this using a handful of regional "super nodes (these are geographically isolated clusters with failover etc)", so if you're one of only 10 nodes in a region, your share value would effectively go up 10 fold.  If you're one of 1,000 it would go down 10 fold, but presumably that means the transaction volume and therefore the amount collected in fees would also go up.

Remember these "nodes" we are talking about here are just bog-standard bitcoin clients, that have X-OpenPay appended to their user agent and have the capability of parsing/passing OpenPay messages.  (I'm targeting Satoshi, MultiBit & the Android wallet, but it should be trivial for anyone to add support to an existing wallet)

If you go to https://github.com/openpay you will see I have forked both MultiBit & Bitcoin, I'm in the process of deciding which Android wallet to fork for this. Frankly mobile development isn't my thing and I may just fork Bitcoinj instead and let the mobile devs implement support in their own way.

[jim618]

Hello Isis,

I need to read through what you are proposing a couple more times before I completely get it but it comes over much more "bitcoin-ey" than before which I think will make it easier to implement.

One thing I wanted to clarify - currently MultiBit is not a full node so it only uses the user-agent when it connects to a Satoshi node. It does not currently announce itself as a peer as it cannot accept incoming requests for anything.

Were you planning to add (Open Pay) transaction relaying ?
Matt Corallo has been working on getting bitcoinj closer to a fully validating node so you might want to talk to him (if you have not already done implemented it) as I would expect he would be beefing up the networking of bitcoinj in this area.

It still would not be a validating peer so I do not think it could announce itself as such without messing up other users.

Also, am I right in thinking that the card reader can send out multiple requests for the same amount of BTC (either maliciously or by design) ? Previously the private key was on the card and the card signed it but is now the backend MultiBit doing the actual signing ?
That changes the potential attack vectors quite a lot as previously if the card was not in a device there was no way the private key could sign anything. If the backend MultiBit is sitting connected to the network 100% of the time listening for relevant OpenPay transactions its attack surface is much higher.

Hope those questions make sense.

:-)

[isis]

Hello Isis,

I need to read through what you are proposing a couple more times before I completely get it but it comes over much more "bitcoin-ey" than before which I think will make it easier to implement.

One thing I wanted to clarify - currently MultiBit is not a full node so it only uses the user-agent when it connects to a Satoshi node. It does not currently announce itself as a peer as it cannot accept incoming requests for anything.

Were you planning to add (Open Pay) transaction relaying ?
Matt Corallo has been working on getting bitcoinj closer to a fully validating node so you might want to talk to him (if you have not already done implemented it) as I would expect he would be beefing up the networking of bitcoinj in this area.

I'm working on a fork of bitcoinj that can handle the messaging and message relaying.  If your wallet knows it got a payment, it will know it got a payment request as well.  What you do from there is up to you as a wallet implementer.

It still would not be a validating peer so I do not think it could announce itself as such without messing up other users.

Also, am I right in thinking that the card reader can send out multiple requests for the same amount of BTC (either maliciously or by design) ? Previously the private key was on the card and the card signed it but is now the backend MultiBit doing the actual signing ?
That changes the potential attack vectors quite a lot as previously if the card was not in a device there was no way the private key could sign anything. If the backend MultiBit is sitting connected to the network 100% of the time listening for relevant OpenPay transactions its attack surface is much higher.

The full node & validation problem are one reason why I made the switch I've mentioned in my last post.

"On Card" validation is something only possible with the EMV card option which is slated for a later release because as I said, "we need to do a lot of paperwork to get ISO to recognize us."  The change here is relevant to magstripe aka the ANY CARD option.

With ANY CARD, a key is generated deterministicly from the numbers on the front of the card and I do mean ANY CARD, I recommend an old expired or spent gift card, or a dead credit card, doesn't matter it's just the seed for a keypair. 

This keypair is not intended to be used as a wallet key, it's just there so the merchant can send a valid message with a "from & to" address and provide a signature on that message that corresponds to something that a client can recognize as "the key to my masters house" so to speak.

Once the "send me money" message hits the wallet software, it is up to the wallet to determine whether or not to fund the request.  I recommend at a minimum, either allowing the user to set a spending limit for when they are away from the keyboard, or popping a dialog box that says "Hey are you really trying to send money to this guy?" 

The funds to be used come from the general wallet, and should follow the same path as it currently does when you want to send someone money.  However the key generated from the card is a marker and should not be a wallet key.

Hope those questions make sense.

:-)

Hope my answers make sense.  BTW still can't get MultiBit to compile, looks like it depends on a version of bitcoinj "0.3-SNAPSHOT" that maven can't resolve.  Any ideas, please PM me.

[isis]

Almost forgot to mention, we get around an accidental replay attack (i.e. a double charge), by only allowing a one time spend to a single address when funding a "send me money" request.  We can also limit it so the same amount can only be charged once per day or something.  Both of these options would be up to the wallet implementer/maintainer to enforce. 

The modifications I'm making at the present time mean that the merchant would tie a unique transaction to a one time use bitcoin address.  This will invalidate the signature hash on the "send me money" message and thus make it much harder for someone to attack.

It would take a compromise from inside the merchant themselves to pull it off because an attacker would need to have captured the private part of the key which is never broadcast and is only a transient variable stored in RAM long enough to calculate a public key and sign the message.  To attack this way you would need to have wire level snooping between the POS terminal and the merchant gateway (such communications are supposed to be encrypted) or a completely compromised gateway to pull it off (not impossible, but hardly easy).

[Deafboy]

To attack this way you would need to have wire level snooping between the POS terminal and the merchant gateway

I read somewhere about merchant gateway machine infected by virus infected by virus.
Yes. Some simple trojan was infected by some custom build sophisticated code to sniff transactions

Isis, I love to read your posts about OpenPay. I hope to see it in the wild soon.
Btw. good luck in you new job.