Topic: BTCD is no more - page 460. (Read 1328490 times)

Enjoy your well deserved rest man, the speed by which you deliver is mindblowing.

OK, that was spooky. It seemed to just work! The first time, so I think this is good place to stop for today. Low level comms all encrypted and even a single hop onion routed doubly encrypted packet came through:

QUEUEALLMESSAGES.({"requestType":"sendmessage","dest":"8989816935121514892","msg":"test","time":1406023635}) size.0
QUEUE MESSAGES from NXT.8989816935121514892 (test) size.1

I am sure there will be some edge cases, but those only possible to find under heavier load than just me testing.

Finally, tomorrow, order matching can be started

James

InstantDEX is the most direct asset that is publicly traded now. NXTprivacy and Privatebet are still private assets not for public, only for whales who buy big gobs of assets

James

It was looking like "privacyServer -> client encrypted UDP channel - transmits but error decrypting" was a tricky memory trashing issue, so I was going to call it a night, but turned out it was just a simple control flow issue, so:

privacyServer -> client encrypted UDP channel - transmits but error decrypting works

Now I will test the doubly encrypted message, but from my acct to privacyServer back to my acct. Not exactly useful, but will test out the software paths. It will probably not work, and then I will call it a night

James

I'm loving this shit, it's seriously interesting ! I also loved the IRC chat you had and would like to participate in testing and running a privacyServer! I'll be watching for the info when you're ready! (never done such a thing before but I hope it's not that complicated to learn)
Also james, what are your NXT AE related to this? I'd like to purchase some too

Boy was I wrong about this one...
Luckily I trusted James and Hodled! (although just 2000 BTCD, that's all I could afford)

The volume has picked up quite nicely. Good call on this one James  

thanks!
I try to do my best to make sure people that believe in me, end up making money.

James

Holding my btcd like mad. Just withdrew all from bittrex, I was planning on day trading but seeing the potential here I won't risk it. James my man, you seriously rock.

  ，Miss the train

This coin's cray.

I just thought of a small leak of info
If I allow different length messages, then an attacker could deduce the type of message you are sending by tracking the size of the packets. Not sure how big of a problem this is. The problem with fixed sized messages is that it will waste a fair amount of bandwidth.

Ah, maybe this is one of the differences in privacy levels!
Yes, I like that. At lower levels of privacy, such small info leakage is accepted,but at higher levels of privacy, all messages will be of fixed size

James

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.

I think BitcoinDark is too much Bitcoin. Let's use DarkNotes and it will help to understand the connection between the coin and the Cryptonote technology: https://cryptonote.org/inside.php

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

mymenace has shown some awesome work for XXXCoin banners and infographics.

The premine holder should contact him directly and offer a bounty... as his work is top notch.

https://bitcointalksearch.org/user/mymenace-114706

Thanks Cloudboy for all the answers

Look what I found on Twitter: https://twitter.com/CryptoTherapist/status/491482611714621442
That guy is right, someone should make Bitcoindark accepted here banners (I would but my PS skills suck)

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

This coin is looking more and more promising with each passing day

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