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.