Hmm also having issues building pNXT but they are complications with packages in Ubuntu.
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libboost-all-dev : Depends: libboost-dev but it is not going to be installed
Depends: libboost-atomic-dev but it is not going to be installed
Depends: libboost-chrono-dev but it is not going to be installed
Depends: libboost-context-dev but it is not going to be installed
Depends: libboost-date-time-dev but it is not going to be installed
Depends: libboost-exception-dev but it is not going to be installed
Depends: libboost-filesystem-dev but it is not going to be installed
Depends: libboost-graph-dev but it is not going to be installed
Depends: libboost-graph-parallel-dev but it is not going to be installed
Depends: libboost-iostreams-dev but it is not going to be installed
Depends: libboost-locale-dev but it is not going to be installed
Depends: libboost-math-dev but it is not going to be installed
Depends: libboost-mpi-dev but it is not going to be installed
Depends: libboost-mpi-python-dev but it is not going to be installed
Depends: libboost-program-options-dev but it is not going to be installed
Depends: libboost-python-dev but it is not going to be installed
Depends: libboost-random-dev but it is not going to be installed
Depends: libboost-regex-dev but it is not going to be installed
Depends: libboost-serialization-dev but it is not going to be installed
Depends: libboost-signals-dev but it is not going to be installed
Depends: libboost-system-dev but it is not going to be installed
Depends: libboost-test-dev but it is not going to be installed
Depends: libboost-thread-dev but it is not going to be installed
Depends: libboost-timer-dev but it is not going to be installed
Depends: libboost-wave-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
I hate boost even more. Sorry I cant help, I got lucky. I think I installed boost from boost.org, the built in Ubuntu is usually out of date
On a happier note, I am 80% debugged! At least in my one off test cases. Of course more rigorous testing could well find some edge cases I miss, but gotta get these "easy" cases working first.
So decent progress today. The price going crazy was a bit distracting, I really need to close the market pages when coding!
client -> privacyServer selection (non-encrypted) - works
client -> privacyServer encrypted UDP channel - works
client -> privacyServer encrypted TCP channel - works
privacyServer -> client non-encrypted handshake - works
privacyServer -> client encrypted UDP channel - transmits but error decrypting
privacyServer -> client encrypted TCP channel - untested (actually currently this path is not used)
client -> privacyServer -> another client via two layer onion routing - untested
I was thinking about each privacyServer keeping a directory of clients that it is responsible for. Just the public acct # and the public key. However now I am leaning toward just broadcasting any client -> client comms that are not connected via the same privacyServer. This would add bandwidth, but it eliminates a potential attack vector. I cant think of how an attacker can use the directory of public addresses and keys, but if there is no directory, then I think it is one less piece of data that is available. The less data to be correlated, the better.
So the logic will be:
client selects privacyServer. Now most commands are routed through the privacyServer. API calls like getOrderbooks, placeBid, etc. These just go to the privacyServer and it handles it. OK, so that's the easy stuff. The hard part is what to do when you want to communicate with someone else. Let us assume that the privacyServer can magically know how to communicate to everyone, but we dont want other people to be able to snoop and find out that you are.
Is this even possible? Well, this is where the fact that we trust the privacyServer comes in really handy.
Say A wants to send a message to B without letting anybody except the privacyServer know and the only thing the privacyServer will know is that A send something to B, but even the privacyServer wont know WHAT was sent.
A first makes the message then tokenizes it with a timestamp. This both proves that A made the message and at what time. It prevents not only spoofing, but also replay attacks. A replay attack is where the attacker makes a copy of a valid message and rebroadcasts it. Maybe it doesnt do anything bad, but it could certainly confuse things, so I like to timestamp, tokenize and then encrypt. OK, so here is one problem I need B's public key to encrypt the message to him. So I need to magically get that somehow, maybe from a query to the server or simply processing broadcasts of the public keys. Either with pros/cons, I will decide later on specifics for that.
OK, so now we have a time validated, account validated and encrypted message to B. Only the fact that it is addressed to B is possible to be determined by getting this packet.
So can we send that? Well, not quite. What if the attacker has taps into the major internet routers? You dont want to be sending stuff in the clear (unencrypted). That would allow the attacker to know that A is sending something to B. So, we add another layer of encryption by re-encrypting the packet so that only the privacyServer can decode it. Now the attacker that is monitoring all internet packets will only see that you sent something to the privacyServer, but you send everything through the privacyServer, so it really doesnt divulge much information.
If you are with me so far, we now look at what the privacyServer gets. It is an encrypted packet that it is able to decode and it sees that what it gets is another encrypted packet that is addressed to B. So, it then "just" sends it to the privacyServer that B selected, or broadcasts it to all nodes. Now anybody that intercepts this packet will only know that it came from the privacyServer and not A.
So, B finally gets the packet, is able to decrypt it and gets the message from A.
Now that I write this, I do think it is better for the privacyServers to keep a directory of all accts/publickeys and then each client can query the privacyServer for the public key. There is much less info divulged by doing this as each acct can broadcast to everyone its public key when it comes online. So there is no correlation possible and the queries about B's publickey is done under encryption, so no info leaked.
It helps me think about things by writing these long emails. I hope I didnt bore you with wall of text. If anybody can see ANY flaws in this logic, please let me know ASAP. just describing this has not been easy, imagine coding and debugging it!
I hope you can see that once there is this encryption network in place, then all sorts of things become possible, all while remaining private. Businesses can conduct business using a public address, but its privacyServer will route everything to private addresses that only it knows about. This will allow businesses to conduct business without letting their competitors know all their income and expenses and even from whom.
So if you followed this so far, you can see why I am not so concerned about the exact anon algo as any of them will fit nicely into this system, they can even be combined. For those of you waiting for a selloff, I apologize.
James
@Azeh: I think the description in this post is pretty useful to start getting people understanding how privacyServers create privacy, hopefully it is useful for marketing and especially making pretty charts.
Poll
