Code that describes the tech in detail

The above is the key code that is updating the raw statistics. basically if the previous node is a brand new one, a new uaddr structure is created and then in either case the number of packets received and the lastcontact time is updated.

Now this is only done when a packet is fully decrypted to a parseable JSON so the originator of the message is known (and validated with a token).

The idea is that with a random number of hops, it is possible that the previous node was the actual originator, but there is no assurance of this as it could have been forwarded and there is (hopefully) no information available to know anything more.

using the above, before sending out any packet, I calculate a fitness metric for all possible IP destinations and send the same packet to the top N:

Currently N is just hardcoded to 8, which will be sufficient in small topologies, but with larger ones without some active conditioning of the raw data with some clever method, it is quite possible to require some large N to assure each hop will get to the right IP address.

The easy solution is for all private nodes to just communicate through a small number of public privacy Servers (~8) but this requires divulging a private node's IP address. So if a public server is compromised, this is no good.

What I need is an algo that seeds the public server's statistics tables in a way that guarantees (nearly) that it will be able to route to the proper destination, but without any high confidence level as to which of the N nodes it was. So if the tail of the histogram is too long, then the routing failure goes up, the the histogram tail is too short, then the anon set of possible IP addresses is getting too small

James

P.S. The degenerate case is to use a loopback server (which is trustable since it is your own computer) and only establish strong statistical signal with it. Maybe it is as simple as that? Then the statistical correlation by other nodes will have a stronger correlation to your loopback privacyserver as all packets are routed from it, but people wont know if you are using a loopback privacy server or some external public privacy server (Source )

Okay, it's late and been a long day, but let me try and get this.

1. User packages up a transmission, multiple layers of encryption included 2. User sends to a public node 3. Node generates fitness metric for servers it has contact with, weighted by last contact and traffic with server 4. The N highest ranking nodes get sent the transmission 5. Receiving node X decrypts 6. If encrypted, loop to 3 7. If JSON, send to receiving node if in peer list, otherwise, fail transmission

I don't think this system description is right based on what you're asking for, but this is the best I could do at this late hour :/

there is actually no difference for any of the nodes, just the state of the internal statistics

Whenever nodeA wants to send to nodeB, it makes 0 or more layers extra. Each layer is encrypted with a onetime keypair so only the actual node for that hop can even decrypt anything. For all intermediate nodes, all they would see is the forwarding address and the onetime pubkey used to encrypt and the length of the data (this will be needed when the packet is padded and would probably indicate the unpadded len as the packet size would have the encrypted len)

so once the onion layered packet is created, all transmissions use the same route packet function:

for the case where the next hop is a public privacy server, there is no need for any statistical metrics as we know exactly the IP address, so the first half of this code just does a direct send.

It is when the next hop is just a NXT address without knowing its IP address that we need to do the metric sorting and this is where we have to make as high of a probability of successfully guessing the right IP for the NXT address

On receiving, all packets are decrypted. If that fails, no more needs to be done. If it decrypts, the content is JSON parsed. If that fails, then it is routed as above. If it parses, then the token is verified to eliminate spoofing. Only if it gets through all this is the packet interpreted using the SuperNET API command processor, which does an API specific statemachine process for each peer<->peer combo, but that is for later.

If anybody sees a flaw in this, please speak up!

James (Source )