I just want to start off by saying I love everything about this coin. Are there any timelines up ahead we should be reaching soon?
It is hard to get exact timeframes, but I am working doubletime 7 days a week until I get the tech done. Things are working on a ~20 node network now, though a bit buggy, but there has been quite a lot of new code so it just needs to be debugged. The designs I am feeling quite good about and feel that it will be state of the art in many areas, especially privacy. which after all is what we are trying to do.
If we can get some test programmers writing unit tests and help with troubleshooting, regression tests, then things will go quite a bit faster. As soon as the Telepathy networking is solid, then I will be able to code at a much faster pace. I am testing telepathic transmissions this weekend. I will know a lot more early next week.
longzai understands the API structure and is coding a GUI to that, BTCDdev is doing the Windows build, so all the parts are headed toward completion approx same time. Active testing by different crew will double or triple the speed of completion.
James
Awesome, keep up the good work. Thanks for the hasty response. I'll keep buying as the weeks go by then and Ill keep supporting your work
thanks!
I think I just finished coding low level Telepathy transport layer. Since I am using UDP and many things can go wrong due to no fault of anybody (nodes dropping out, onion hopping to a node that is gone, etc) it is quite likely that a packet sent to a destination might not get there, but ones after it could. So I need to implement some sort of TCP like retry layer on top of UDP. Good thing I already did this earlier this year!
Due to the way the packets are sent, it is quite tricky to get it to work, but finally I managed to achieve this as follows:
When a contact is added (happens every init), the published public key from the NXT blockchain is used to create a shared secret between two accounts. These accounts are totally abstract and are not tied to any IP address at all and it also happens to be the key I use for the DHT traversal.
Now I could send an encrypted message between nodes to exchange the dead drop addresses, but I think using a non-predictable (to anybody else) but deterministically calculated address that only the two nodes can calculate is safe enough. Even if this is somehow compromised, it is only for a bootstrap to get a decent deaddrop address to use. Once the comms are established, then the deaddrop address to use can be updated at anytime and there is a way to get it to the other side.
Each message between the two nodes will get a sequence number and each also gets its own onetime AESpassword that is calculated as follows:
sprintf(buf,"%llu.%d",(long long)nxt64bits,sequenceid);
calc_sha256cat(AESpassword->bytes,(uint8_t *)buf,(int32_t)strlen(buf),shared,(int32_t)sizeof(bits256));
init_hexbytes(AESpasswordstr,AESpassword->bytes,sizeof(bits256));
return(conv_NXTpassword(secret.bytes,pubkey.bytes,AESpasswordstr));
sha256cat is H(m || sharedsecret) where m is the acct number of the sender with the sequenceid
So, this means the password can only be created by the two nodes who know the shared secret. I ran into a problem that the piggyback attachment was a totally encrypted blob with no header info at all. I could have put a onetime pubkey, but since I am using the sharedsecret for AES cipher I didnt want to venture into unsure crypto things. So to keep things totally encapsulated in the onetime AES cipher, I needed some other way to let the receiving end know who was sending it.
Remember that in Telepathy, there is no destination address that is actually real. It is an equidistant (in DHT space) address to N public IP privacyServers. N will hopefully be 20+ and one of these IP addresses is the actual destinations, but it can never divulge which one, so the bootstrap was tricky enough, but I solved that by putting it into the cloud at a location that is the curve25519 pubkey of the AES cipher. Another oneway function and this also combined with the need to protect the sender. After all if the sender is making DHT calls with his address in the JSON, even though it is protected by encryption, the DHT node that handles the hop has to decrypt it and if the attacker is controlling the node, then this leaks the fact that the sender sent to a specific deaddrop address. Far more leakage than I am comfortable with.
I just used the same address for all such Telepathy payload packets. But that is quite redundant and wastes precious space. Also, I use the sender's address as an authentication method and using a static address loses that. Luckily, this protection of the sender can be achieved while also providing authentication by using the "location" of the packet's sequenceid!
Now without modifying the encrpted attachment and without leaking any info, the receiver can use the "sender" field to figure out if a Telepathy packet is meant for him and most importantly what AES password to use. No need to brute force try all the possible contacts sequence id passwords, as we know what the "location"/"sender" will be for all the expected sequence ids from all the contacts.
Still have a few small issues like how to send back retry requests safely, but I am quite pleased at how all the pieces came together. I think I will be able to debug this tomorrow and at that point I will be able to send sequences of packets between any two contacts and have it reliably get there, well, assuming I can get all the bugs fixed. Realistically in complex network topologies there will be bugs, but so far so good.
As you can see, with a reliable low level packet transport, all sorts of things become very simple to do. Like file transfer (say telepod files!) or even low bandwidth audio. That would be cool, to be able to stream voice over Telepathy connection
I know this might seem like a lot of tech babble, so if you dont understand it, just ignore it. If you do understand it, plz feel free to point out any flaws. I tried hard to make sure there arent any, but with something like this it always helps to get as many eyes on the issue as possible
James
#### The following are the externally visible actions:
1. sending out a 1400 byte packet to a random node for the onion layered packet that contains the DHT storedata of the encrypted deaddrop address.
1b. some random hops later a random node will decrypt the DHT storedata and start a DHT sequence, which gets it to the secret location in the cloud.
2. sending out a 1400 byte DHT findvalue request for the secret address directly using the DHT sequence, so the DHT nodes will know that you requested something from the cloud. however, this will just look like all the other findvalue requests as it is just to a random address.
2b. the DHT nodes that are involved will find out the size of the encrypted data that you get. For now I am not making this all the same size, I probably should, but I need to first determine what the max size should be. At some point you get a 1400 byte packet back with the encrypted deaddrop address
3. you send 1400 by onion routed packets with the sender actually being the "location", so as long as the randomly selected nodes along the onion route are not colluding and sharing info about the source and destination, nobody will even know that you sent this packet out. The odds of the attacker control all randomly selected onion nodes is pretty small and they wont know for sure that you were not just forwarding, but in this worst case they will know that you sent some packets to a dead address.
4. your node participates in DHT routing following the same rules as all the other nodes. Even when you get a telepathy packet, there is no visible difference as any actions are deferred a bit and the output timing and even order of packets goint out of your node is randomized.
James
Poll
