[ANN] SuperNET NXT asset 12071612744977229797, SUPERNET KMD assetchain in summer

[shojayxt]

You should add opal

What would be the point of that?

[jl777]

First off I remind you I am just a simple C programmer and not a cryptographer. If anybody has the math background to confirm or deny my experimental finding, please post!

I was experimenting with Curve25519 yesterday and I observed a very useful property that allows the creation of multisig. https://forum.thesupernet.org/index.php?topic=154.msg1262#msg1262

Now I doubt it was just in the few cases that I discovered that works. I bruteforce searched thousands of combinations and found a very simple relationship that I believe can be used for arbitrary M of N signatures.

The fundamental property of Curve25519 is that if A and B know each others public key, they can create a shared secret. Let A and B be the private keys and a and b the public keys:

curve25519(A,b) == curve25519(B,a)

I searched and searched on the Internet to find little actual useful info, so I started with the above and my intuition and searched for combinations that created the same result and there were many, but the simplest and clearest was:

Add C and c to the above and denote S_ab to being the result of curve25519(A,b) or curve25519(B,a) (they are the same)

curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)!

This relationship is quite useful and it is probably obvious to anybody familiar with curve25519 so maybe I am just getting excited over nothing, but the recommendation is to immediately hash the output S_ab. Presumably to avoid any low entropy sections of the point and once you do this, the above relationship does not work as you end up totally scrambling the location of the point in the finite field. I call this the rawsharedkey and maybe it has been explored in depth so we can get some math proofs of the above relationship.

We also know that curve25519(A,curve25519(B,curve25519(C,seed))) is equal to all the permutations of order, I think this is because the field forms an abelian group, but it has been a long time since I did any abstract algebra so I probably have the terms wrong. It is just a fancy way of saying the order doesnt matter.

So how to use these math properties to make multisig?

Since S_xy is constant for each set of keypairs for each node, these values can actually be cached locally. Of course this means that the presence of S_xy in the output does not mean that either X or Y actually signed anything. Turns out this is fine, as the final step requires the signing node to actively participate and the final output can be processed till the dogs come home:

sha256(seed ^ curve25519(A,S_bc))
sha256(seed ^ curve25519(B,S_ac))
sha256(seed ^ curve25519(C,S_ab))

all the above produce the identical result and proves that A, B and C all signed it with the seed (which should have a timestamp in it) and since it goes through sha256 the output gives no useful info about A, B or C. I am not sure if S_xy is leaking any info to the nodes that get access to it, but I dont think so as it is the output of curve25519 and that's supposed to be hard to reverse.

Since it is safe to publish the final number, A, B and C publish it and everybody can verify if 0, 1, 2 or 3 signers signed it. The enforcement of following the result is beyond the scope of this thread, but this can be put into the NXT core and each node can just use the above to verify whether the payment should be released

Now, how can this be generalized? I feel strongly that the "triangle" relationship can be generalized, but so far my experimental results are not finding the right sequence.

Let me ramble a bit, that sometimes helps

Starting with the fundamental triangle:
curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)

Let us replace C,c with D, d:
curve25519(A,S_bd) == curve25519(B,S_ad) == curve25519(D,S_ab)

The problem is these are different values as it is S_ab combined with C vs D, however, we can use the priv/pub equivalence:

curve25519(d,curve25519(C,S_ab)) ?? curve25519(c,curve25519(D,S_ab))

nope, that didnt work, but as expected:

curve25519(D,curve25519(C,S_ab)) == curve25519(C,curve25519(D,S_ab))
which means:

curve25519(D,curve25519(C,S_ab)) ==  curve25519(C,curve25519(D,S_ab))  == curve25519(B,curve25519(D,S_ac))  == curve25519(A,curve25519(D,S_bc))

Hey! That means there is a 4 signer solution, but this requires multiple signings and then correlations, so not exactly what I am looking for. Anyway I hope to get some math help here so an efficient M of N multisig using curve25519 is possible. Experimentally I found the triangle relationship, which I am not sure if it is trivially obvious or something significant.

James

[yeXIABC]

First off I remind you I am just a simple C programmer and not a cryptographer. If anybody has the math background to confirm or deny my experimental finding, please post!

I was experimenting with Curve25519 yesterday and I observed a very useful property that allows the creation of multisig. https://forum.thesupernet.org/index.php?topic=154.msg1262#msg1262

Now I doubt it was just in the few cases that I discovered that works. I bruteforce searched thousands of combinations and found a very simple relationship that I believe can be used for arbitrary M of N signatures.

The fundamental property of Curve25519 is that if A and B know each others public key, they can create a shared secret. Let A and B be the private keys and a and b the public keys:

curve25519(A,b) == curve25519(B,a)

I searched and searched on the Internet to find little actual useful info, so I started with the above and my intuition and searched for combinations that created the same result and there were many, but the simplest and clearest was:

Add C and c to the above and denote S_ab to being the result of curve25519(A,b) or curve25519(B,a) (they are the same)

curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)!

This relationship is quite useful and it is probably obvious to anybody familiar with curve25519 so maybe I am just getting excited over nothing, but the recommendation is to immediately hash the output S_ab. Presumably to avoid any low entropy sections of the point and once you do this, the above relationship does not work as you end up totally scrambling the location of the point in the finite field. I call this the rawsharedkey and maybe it has been explored in depth so we can get some math proofs of the above relationship.

We also know that curve25519(A,curve25519(B,curve25519(C,seed))) is equal to all the permutations of order, I think this is because the field forms an abelian group, but it has been a long time since I did any abstract algebra so I probably have the terms wrong. It is just a fancy way of saying the order doesnt matter.

So how to use these math properties to make multisig?

Since S_xy is constant for each set of keypairs for each node, these values can actually be cached locally. Of course this means that the presence of S_xy in the output does not mean that either X or Y actually signed anything. Turns out this is fine, as the final step requires the signing node to actively participate and the final output can be processed till the dogs come home:

sha256(seed ^ curve25519(A,S_bc))
sha256(seed ^ curve25519(B,S_ac))
sha256(seed ^ curve25519(C,S_ab))

all the above produce the identical result and proves that A, B and C all signed it with the seed (which should have a timestamp in it) and since it goes through sha256 the output gives no useful info about A, B or C. I am not sure if S_xy is leaking any info to the nodes that get access to it, but I dont think so as it is the output of curve25519 and that's supposed to be hard to reverse.

Since it is safe to publish the final number, A, B and C publish it and everybody can verify if 0, 1, 2 or 3 signers signed it. The enforcement of following the result is beyond the scope of this thread, but this can be put into the NXT core and each node can just use the above to verify whether the payment should be released

Now, how can this be generalized? I feel strongly that the "triangle" relationship can be generalized, but so far my experimental results are not finding the right sequence.

Let me ramble a bit, that sometimes helps

Starting with the fundamental triangle:
curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)

Let us replace C,c with D, d:
curve25519(A,S_bd) == curve25519(B,S_ad) == curve25519(D,S_ab)

The problem is these are different values as it is S_ab combined with C vs D, however, we can use the priv/pub equivalence:

curve25519(d,curve25519(C,S_ab)) ?? curve25519(c,curve25519(D,S_ab))

nope, that didnt work, but as expected:

curve25519(D,curve25519(C,S_ab)) == curve25519(C,curve25519(D,S_ab))
which means:

curve25519(D,curve25519(C,S_ab)) ==  curve25519(C,curve25519(D,S_ab))  == curve25519(B,curve25519(D,S_ac))  == curve25519(A,curve25519(D,S_bc))

Hey! That means there is a 4 signer solution, but this requires multiple signings and then correlations, so not exactly what I am looking for. Anyway I hope to get some math help here so an efficient M of N multisig using curve25519 is possible. Experimentally I found the triangle relationship, which I am not sure if it is trivially obvious or something significant.

James

  It looks good I take some UNITY

[jl777]

I pushed a new version with findaddress API

./b SuperNET '{"requestType":"findaddress","refaddr":"8894667849638377372","dist":24,"numthreads":20,"duration":6000,"list":["13434315136155299987","8894667849638377372","10694781281555936856","18429876966171494368","16163006958863727986","1838354277347686608","17572279667799017517","14815310753561302584"]}'

The refaddr is your privacyServer's NXT address, dist is the distance in bits (after xor), numthreads is the number of parallel tasks doing the search, duration is in seconds and list is the reference list of public server addressees

This will run in the background until the time runs out and it will print out a password and stats for your super private account. I havent done the storing in encrypted file or anything else yet. while it is running, if it finds a better acct, it will print:

>>>>>>>>>>>>>>> new best (super secret password) ...

so you can always search for this and get decent accounts to use while the findaddress keeps working in the background. It is kind of like mining! But what it is doing is actually very useful. It is finding the perfect address for you to use by making it look like an address that could be linked to any of the other public servers.

Due to the way the accounts are created, bruteforce random guessing is the best way to find such an address. This is a good thing as it means that the encryption is quite good. After all if the distance between the mined acct and the reference account went to zero, we have effectively hacked it!

The search is creating an N dimensional space where each dimension is the distance from one of the server accts in the list. The metric function is a bit more complicated, but conceptually we want a point in N-space that is equidistant from as many public nodes as possible. With the current number of nodes being so small, it is hard to come up with any address that meets this criteria, but at a distance of 24, given enough time, it should be possible to find an address that is +/- 3 distance from most of the list.

I am hoping that with more nodes, it will be possible to find addresses that are around 20 bits distant and still have the above characteristic.

Now why on earth do we care about such things?

The reason is that this solves the "last mile" problem of how to establish totally private comms without resorting to broadcasting to everybody. My coding the DHT is what allowed me to solve this, so those that think these seemingly unrelated things are slowing down the progress, it is quite the opposite. It is helping achieve the ultimate goal!

To understand how this allow comms without divulging the IP address, requires a bit of background on DHT, especially the Kademlia XOR distance method. Using XOR as a distance function sounds so simple, but it has some very powerful mathematical properties. Namely, you can know if another node is closer or farther away from the desired location, totally in the abstract. Imagine that you start searching for something. It gets a delivery address (in the abstract not IP). Now you find all the nodes you know about that are closest to this address and ask them to deliver it. You only know they are closer to the destination that you are.

That's it!

Of course a lot more details, but this is emergent behavior, eg. out of very simple behavior at the local level, some powerful global functionality emerges. Imagine you got the packet from someone that was farther away than you are. Now you do the same thing and the packet keeps getting closer and closer to the destination. Finally it gets to the nodes that are as close as possible that are in the network.

All the SuperNET nodes are part of this "bucket brigade", each passing the packet one step closer to the destination. This means that your node is also going to be involved in this and everybody knows your public server's acct and IP address. If not because you publish it, but if they wanted to the attacker can do sybil attacks and get this info. It is simply unavoidable to get an account linked to the IP address if you are transacting with it.

However, we have the private address that only people you transact with know. Your privacyServer's acct is known along with its IP address, but as long as you are careful with who finds out your privateaddress, then it is just an address that happens to be equidistant from N other privacy servers. Which one? Could be any of them as the way the DHT works is that it replicates the info to all the nodes closest to the destination, which in this case is your address. Taking advantage of this property of the DHT and the fact that your privacyServer will be handling the routing allows packets that are encrypted to your private address to be received by your computer and you can decrypt it as it is sent on to the closer nodes.

As the network grows, it will become harder and harder even to identify the set of possible nodes your private address belongs to. So even if your private address is compromised, there isnt a way to link it to any IP address!

James

[jl777fan]

when superset  go to  btc38.com trade？

[yeXIABC]

I pushed a new version with findaddress API

./b SuperNET '{"requestType":"findaddress","refaddr":"8894667849638377372","dist":24,"numthreads":20,"duration":6000,"list":["13434315136155299987","8894667849638377372","10694781281555936856","18429876966171494368","16163006958863727986","1838354277347686608","17572279667799017517","14815310753561302584"]}'

The refaddr is your privacyServer's NXT address, dist is the distance in bits (after xor), numthreads is the number of parallel tasks doing the search, duration is in seconds and list is the reference list of public server addressees

This will run in the background until the time runs out and it will print out a password and stats for your super private account. I havent done the storing in encrypted file or anything else yet. while it is running, if it finds a better acct, it will print:

>>>>>>>>>>>>>>> new best (super secret password) ...

so you can always search for this and get decent accounts to use while the findaddress keeps working in the background. It is kind of like mining! But what it is doing is actually very useful. It is finding the perfect address for you to use by making it look like an address that could be linked to any of the other public servers.

Due to the way the accounts are created, bruteforce random guessing is the best way to find such an address. This is a good thing as it means that the encryption is quite good. After all if the distance between the mined acct and the reference account went to zero, we have effectively hacked it!

The search is creating an N dimensional space where each dimension is the distance from one of the server accts in the list. The metric function is a bit more complicated, but conceptually we want a point in N-space that is equidistant from as many public nodes as possible. With the current number of nodes being so small, it is hard to come up with any address that meets this criteria, but at a distance of 24, given enough time, it should be possible to find an address that is +/- 3 distance from most of the list.

I am hoping that with more nodes, it will be possible to find addresses that are around 20 bits distant and still have the above characteristic.

Now why on earth do we care about such things?

The reason is that this solves the "last mile" problem of how to establish totally private comms without resorting to broadcasting to everybody. My coding the DHT is what allowed me to solve this, so those that think these seemingly unrelated things are slowing down the progress, it is quite the opposite. It is helping achieve the ultimate goal!

To understand how this allow comms without divulging the IP address, requires a bit of background on DHT, especially the Kademlia XOR distance method. Using XOR as a distance function sounds so simple, but it has some very powerful mathematical properties. Namely, you can know if another node is closer or farther away from the desired location, totally in the abstract. Imagine that you start searching for something. It gets a delivery address (in the abstract not IP). Now you find all the nodes you know about that are closest to this address and ask them to deliver it. You only know they are closer to the destination that you are.

That's it!

Of course a lot more details, but this is emergent behavior, eg. out of very simple behavior at the local level, some powerful global functionality emerges. Imagine you got the packet from someone that was farther away than you are. Now you do the same thing and the packet keeps getting closer and closer to the destination. Finally it gets to the nodes that are as close as possible that are in the network.

All the SuperNET nodes are part of this "bucket brigade", each passing the packet one step closer to the destination. This means that your node is also going to be involved in this and everybody knows your public server's acct and IP address. If not because you publish it, but if they wanted to the attacker can do sybil attacks and get this info. It is simply unavoidable to get an account linked to the IP address if you are transacting with it.

However, we have the private address that only people you transact with know. Your privacyServer's acct is known along with its IP address, but as long as you are careful with who finds out your privateaddress, then it is just an address that happens to be equidistant from N other privacy servers. Which one? Could be any of them as the way the DHT works is that it replicates the info to all the nodes closest to the destination, which in this case is your address. Taking advantage of this property of the DHT and the fact that your privacyServer will be handling the routing allows packets that are encrypted to your private address to be received by your computer and you can decrypt it as it is sent on to the closer nodes.

As the network grows, it will become harder and harder even to identify the set of possible nodes your private address belongs to. So even if your private address is compromised, there isnt a way to link it to any IP address!

James

    Inquiries looking

[josegines]

RESERVESHARE
@Jl777News is a follower of the twitter @reserveshare



Between yesterday and today massive selling has taken place, that joined the absence of news on the part of the dev, they do that we do not know exactly that it happens with the AE called RSUnit.

The price of the AE RSUnit has fallen down in 2 days from 1 up to 0.02 of now.(-98 %)

A clarification would be interesting on the part of Supernet, as for relation that joins her at present with Reserveshare, to prevent the people from coming to buy seeing that Supernet is a follower of Reserveshare.

If there is relation, already to communicate it and if it is not, it would be suitable that they were withdrawing the pursuit in Twitter so that the people do not take to trick and we could lose more than in this moment we are losing.

https://bitcointalk.org/index.php?topic=734477.msg9174887#msg9174887

[Este Nuno]

RESERVESHARE
@Jl777News is a follower of the twitter @reserveshare



Between yesterday and today massive selling has taken place, that joined the absence of news on the part of the dev, they do that we do not know exactly that it happens with the AE called RSUnit.

The price of the AE RSUnit has fallen down in 2 days from 1 up to 0.02 of now.(-98 %)

A clarification would be interesting on the part of Supernet, as for relation that joins her at present with Reserveshare, to prevent the people from coming to buy seeing that Supernet is a follower of Reserveshare.

If there is relation, already to communicate it and if it is not, it would be suitable that they were withdrawing the pursuit in Twitter so that the people do not take to trick and we could lose more than in this moment we are losing.

https://bitcointalk.org/index.php?topic=734477.msg9174887#msg9174887

People trade follow for follow all the time on twitter. I wouldn't draw any conclusions from that at all.

[jl777]

Each node runs a public IP privacy server. this means people will be able to link your IP to your servers' NXT acct number, so it is suggested to just use an acct without anything in it, maybe a few NXT just so you can lock it in as yours.

This IP/acct will then participate in the DHT routing for all SuperNET packets.

To transact privately, you let people you are dealing with your public NXT acct. this is another throwaway acct, but it is used for authenticating that it is really you doing the transactions.

Here comes the magic!

Each session, you generate a new keypair and without the current keypair, nobody can transact with you. So you publish your session's pubkey into the cloud. Now anybody that knows your public NXT acct can get your current pubkey. If you want to prevent this, you can encrypt the pubkey and only share this with a small number of people, but divulging the pubkey is not so bad, so additional steps are for the truly cautious.

For super private comms, both parties generate a "sphere" of deaddrop acct numbers that minimizes the distance difference between your privacyServer's acct # and its neighbors. What this means is that even if the deaddrop acct number(s) are compromised, there is no direct link to your IP address. This exchange is done under encryption and is automated process and only needs to be done once per session.

Each side would split up each packet into M of N fragments, M of N chosen so enough of the packets are within the maxdistance limit of being routed the DHT packets. From the natural DHT routing process, your server will route these M of N packets to the closest nodes to each deaddrop acct #, but there is not even an acct behind the deaddrop acct. it is just an address that just happens to be close to your server's address, but far enough away that it could be close enough to any number of other IP addresses. Using M of N, allows the sphere of addresses to be significantly larger than what is hardcoded to be routed to your node. This is build into the DHT, eg. sphere of radius 28, and all packets destination within 24 bits guaranteed delivery.

Now the packets that are flowing through are fully encrypted so only your node can decrypt it. Output packets are randomly delayed so timing analysis cant determine if your node decrypted it or not based on packet traffic. All packets (other than ping) are fixed size 1400 byte UDP packets. Using UDP prevents TCP DOS attack locking up the sockets for the tcp timeout.

James

TL:DR it is possible to transact with someone without ANYBODY actually knowing the IP address of the destination, and therefore very private comms are possible. If these comms happen to have telepods and funds are being transacted, then commerce can happen using this method.

[Este Nuno]

[jl777]

running some simulations and when we get to ~500 nodes, within a few minutes I am finding a deaddrop address that has the exact distance to ~20 nodes. this is at distance 24, which I believe is about 1/256 of total nodes and with a K factor of 7 even without any special relaxing of distance requirements, the packets will automatically arrive at your IP

The larger the distance, the easier it is to find matches. At bigger distances, 10% or even more of the sample set are exact matched. The good thing is that when the total network size is small, we can just cache all the nodes so big distance wont matter.

I also got it so that each node creates a list of addresses to match against and when the network is bigger, each node will hav a slightly different list it will be optimizing against.

It looks like we can have a set of deaddrop addresses that each have exact distance match to 10 to 100 public privacy servers and also decent distances to a lot of other nodes. Then we can choose 64 of these deaddrop addresses to establish a super secure link.

Since the only one that actually knows the IP address is the person running the node, I think that short of it being compromised there is no practical way of correlating your IP address. keep in mind that packets are sent to 64 different deaddrop addresses that dont really exist, so I am not sure how anybody would setup a sybil attack or any other attack to link your IP address to your acct.

Now even if somehow this info leaked, just knowing your acct # and IP address is still not enough as you would be transacting with telepods which themselves have no acct linked to you. Since people had a hard time understanding the simpler form of Teleport, I fear that few will be able to understand the new deaddrop approach. Hopefully somebody will provide some feedback on its weaknesses, if it has any.

I feel this is a fundamental improvement in privacy. In all prior versions, there was at least a statistical linkage of your acct # with IP address. Now, all that is happening is that packets are being sent to dead addresses so there is nothing to correlate. Other than the distances to the other nodes, but with the mining of equidistant addresses, this only gives a statistical correlation, and that is a dynamically changing thing, especially with the randomized sending of packets to the set of deaddrop addresses.

This is a bit of unexpected extra work, but the qualitative increase in privacy is well worth it. A key thing to realize is that all of the SuperNET just gets this level of privacy for all comms

James

[amytheplanarshift]

Thanks for the updates James. Really excited to see SuperNET in action! I assume the price will jump quite a bit once people see it working and in the wild.

[jl777]

Thanks for the updates James. Really excited to see SuperNET in action! I assume the price will jump quite a bit once people see it working and in the wild.

I concentrate on increasing the value. The price, it goes up and down and cant be directly controlled. however, by creating more and more tech which can be used to create more and more useful end user solutions, the value of SuperNET will continue to grow. The price will oscillate around the value

James

[Hotmetal]

running some simulations and when we get to ~500 nodes, within a few minutes I am finding a deaddrop address that has the exact distance to ~20 nodes. this is at distance 24, which I believe is about 1/256 of total nodes and with a K factor of 7 even without any special relaxing of distance requirements, the packets will automatically arrive at your IP

Are you going to be looking for people to contribute hardware/bandwidth for masternodes?

[jl777]

running some simulations and when we get to ~500 nodes, within a few minutes I am finding a deaddrop address that has the exact distance to ~20 nodes. this is at distance 24, which I believe is about 1/256 of total nodes and with a K factor of 7 even without any special relaxing of distance requirements, the packets will automatically arrive at your IP

Are you going to be looking for people to contribute hardware/bandwidth for masternodes?

there are no masternodes
every wallet will be equal, it is totally decentralized

The BTCD community is financing 50 to 100 VPS that will be community nodes and any additional nodes will be much appreciated!

Things are rapidly evolving, but you can get the current version from https://github.com/jl777/btcd
it is only for linux now, windows and mac builds are being worked on by others

James

[ASICHEAD]

Thanks for the updates James. Really excited to see SuperNET in action! I assume the price will jump quite a bit once people see it working and in the wild.

I concentrate on increasing the value. The price, it goes up and down and cant be directly controlled. however, by creating more and more tech which can be used to create more and more useful end user solutions, the value of SuperNET will continue to grow. The price will oscillate around the value

James

Hi James,

Thanks for creating the superNET and teleport.

SuperNET and teleport are both very unique and exceptional project .

Your name will be recorded in the history of cryptography sciences  .

[jl777]

Thanks for the updates James. Really excited to see SuperNET in action! I assume the price will jump quite a bit once people see it working and in the wild.

I concentrate on increasing the value. The price, it goes up and down and cant be directly controlled. however, by creating more and more tech which can be used to create more and more useful end user solutions, the value of SuperNET will continue to grow. The price will oscillate around the value

James

Hi James,

Thanks for creating the superNET and teleport.

SuperNET and teleport are both very unique and exceptional project .

Your name will be recorded in the history of cryptography sciences  .

Thanks for your support!
I am not a cryptographer, but I do have a knack for doing creating things with existing tools.

The whole deaddrop routing I think is quite significant as I cant figure out how it can be attacked. once the network gets a critical mass of activity, it will look like everybody is sending to everybody, which is the same as nobody sending anything. As close to white noise as can be.

I am having cassius write up a paper to explain the whole deaddrop method using DHT and n-space equidistant addresses

James

[ASICHEAD]

Thanks for the updates James. Really excited to see SuperNET in action! I assume the price will jump quite a bit once people see it working and in the wild.

I concentrate on increasing the value. The price, it goes up and down and cant be directly controlled. however, by creating more and more tech which can be used to create more and more useful end user solutions, the value of SuperNET will continue to grow. The price will oscillate around the value

James

Hi James,

Thanks for creating the superNET and teleport.

SuperNET and teleport are both very unique and exceptional project .

Your name will be recorded in the history of cryptography sciences  .

Thanks for your support!
I am not a cryptographer, but I do have a knack for doing creating things with existing tools.

The whole deaddrop routing I think is quite significant as I cant figure out how it can be attacked. once the network gets a critical mass of activity, it will look like everybody is sending to everybody, which is the same as nobody sending anything. As close to white noise as can be.

I am having cassius write up a paper to explain the whole deaddrop method using DHT and n-space equidistant addresses

James

You're a Super Grandmaster of Privacy policy.
I love your job.

[Cassius]

Hello everyone
I have started a SuperNET API documentation thread here: https://forum.thesupernet.org/index.php?board=41.0
I have begun populating it, though am still wrestling a little with the installation and update process myself. If anyone gets an automated process up and running - Linux or Windows - that would be fantastic and would no doubt enable many more people to do some testing and experimenting with it. Remember: James has offered a 1,000 BTCD bounty if you can find a way to break it...
I will be taking a little break from this for a while to get my head around DHT routing and N-dimensional space equidistant addresses and write up James' new plan to send messages to people without even knowing their IP address. 'Imagine being able to send email to someone without knowing their email address and without spamming everyone. This is on that level of crazy.'
Assuming I survive this, I'll get back to the API documentation afterwards. In the meantime, please feel free to add material to the documentation threads above. When I get back from my trip to N-space I'll incorporate any new information into the OPs.

[youngmike]

Thanks for the updates James. Really excited to see SuperNET in action! I assume the price will jump quite a bit once people see it working and in the wild.

I concentrate on increasing the value. The price, it goes up and down and cant be directly controlled. however, by creating more and more tech which can be used to create more and more useful end user solutions, the value of SuperNET will continue to grow. The price will oscillate around the value

James

Hi James,

Thanks for creating the superNET and teleport.

SuperNET and teleport are both very unique and exceptional project .

Your name will be recorded in the history of cryptography sciences  .

Thanks for your support!
I am not a cryptographer, but I do have a knack for doing creating things with existing tools.

The whole deaddrop routing I think is quite significant as I cant figure out how it can be attacked. once the network gets a critical mass of activity, it will look like everybody is sending to everybody, which is the same as nobody sending anything. As close to white noise as can be.

I am having cassius write up a paper to explain the whole deaddrop method using DHT and n-space equidistant addresses

James

Nice!