Still no joy :/
It's basically complaining about not being able to find the static boost libraries.  I don't think I can downgrade to an earlier version either as they dont seem to be available for Ubuntu 14.  How annoying!

1.55?

You might try to install a vanilla BBR first. That would get all the compiler dependencies out of the way, then pNXTd will build

Long term that could be the preferred solution to simplify the architecture, but I want to get something out sooner rather than later so I plan on doing a "soft merge", so they both coexist. Then again I might just get a flash of insight on how to do something totally original and solve the fundamental problem of privacy. That's really what this is about. If I can create a privacy solution that passes peer review, then the exact algo is not so relevant.

BitcoinDark is committed to continue to advance privacy tech while at the same time providing other valuable services all in a user friendly environment. So, currently ring signatures look very good, but zerocoin threatens to come out with zerocash and if they actually do and their zeroknowledge stuff is really as good as they say, it would make sense to integrate that into BitcoinDark. I like to have different privacy levels, so maybe basic level uses mixing, corporate level uses ring signatures, advanced uses zerocash and total-invisibility level combines all of them.

I want people to be able to choose BitcoinDark and then not have to worry about whether it was the right tech choice. BTCD will be like the Borg, we will assimilate all useful tech. If I made a mistake (I do this on occasion) and made the wrong selection, then I will simply correct it and pop in the better algo.

So things are evolving and will continue to evolve. Privacy tech is like antivirus tech. As soon as you reach a certain level of privacy, attackers start attacking and it is prudent to improve the algorithms.

James

Its ok, like waves. goes up, goes down.
They key is if the tide is rising or not.
Need to average the waves to check this

trying to get the price down :\ not working at all.

Hmm also having issues building pNXT but they are complications with packages in Ubuntu.

Thanks Cloudboy for all the answers

share the article please http://www.coinssource.com/bitcoindark-transitions-from-pow-phase-pure-pos/

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.