I got half the atomic exchange working, but the problem is that I dont have the pubkey to properly encrypt it, so like I was saying yesterday I need a way for the pubkey to get propagated. For now, I am using a single hub for testing, gotta get the easiest case 100% solid before going to multihubs.
Anyway, routine API's like "getpubkey" become a little trickier if it needs to handle BTCD or NXT address, so might as well make it handle pNXT and BTC addresses. The flip side is a "publishaddresses" API call. This is where you tell the privacyServer what addressees you dont mind being public info, along with the public key for the current session. It could well be that no funds ever actually go in the public account as there will be provisions to tell the privacyServer to bypass the public acct and send to a private acct. I am waiting for possible attacks on this method. It is kind of like onion routing, but applied to acct numbers. Maybe we call it "onion accounts"?
A -> B's public address
B's privacyServer (the only one that even knows the private acct #) reroutes to the private acct
Now on the blockchain people see that A sent to some acct, but even if the actual private acct it ended up in is able to be determined (doubtful), what is the consequence? I like to have contingency plans, so that lets assume the private acct becomes known, but WHO owns it?
Originally A sent via its privacyServer which then got it to B's privacyServer, which then put it in a private acct. But only B knows whose acct that is. Now B can send instructions to B to spend from this private acct and people could see that funds were spent, but still only B knows who is doing this.
So I think this setup is adequate for the first release. I can always add the superprivate acct that not even the privacyServer knows the number of, well once I figure out how to do that.
Should have this done first half of the day, then I can do the receiving half of the "makeoffer" API. I already have it generating the data needed to do an atomic swap:
(8989816935121514892) -> (8989816935121514892) _tokbuf.[[{"utx":"0201140d3d01d00225c5fed2690701cf06f267e7c227b1a3c0dfa9c6fc3cdb593b3af6f16d65302
f8c71b555df3ec27c000000000000000000e1f50500000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000
0000444a53bf9828e869e80300000000000031007b22617373657442223a2231363339323939383
439333238343339353338222c2271747942223a2231303030303030227d","sig":"ac01a7493ef9e833fa6c80b67ae1694ba93c0a80e4e08e8a86a492f5e2c1a124","ref":"","time":1406072660},{"token":"d79fth95u83cu087m4js5pr7oqktvg537dctmf7sclmv3thq7k6h8bpgsr1it701h67f7h1a4k39p0j
koob8s7n9tnjg7kfeph5i26ldr14059pskm96sb199j701nud85pj2cetoocpvvk20vp5ohhuae9ifa
28"}]]
But planning ahead I will need to support a large variety of packet types, right now there are just a few, unencrypted intro packet that is needed to establish contact, encrypted and tokenized JSON packet, encrypted but not tokenized JSON for routine non-sensitive comms, and the middle one goes into an API processor that has both local and remote instantiations (that was confusing to get right). Clearly, it would be nice to be able to easily add a new set of API commands without messing with the core API set. Sort of an plugin system for related API command, dont you agree?
So, I will do that too. Will slow me down a bit, but will payoff the first time I want to add another set of APIs. I surely dont want to have to dive into all the packet processing logic again, so many special cases.
Next weather update later tonight
James
Poll
