Topic: [ANN] SuperNET NXT asset 12071612744977229797, SUPERNET KMD assetchain in summer - page 116. (Read 736772 times)

Cheap credit with the aid of BTER deception! Copycat 

When the fund start to buy coins?

jl7777 can you add coin magi $xmg to the lineup? its new m7m algo for entry or advanced miners that haven't had the fair advantage to mine, can do so now, from what I'm learning, should look into it yourself I think.

The bounty is for a method to deanonymize the telepods.

just did the first telepathic transfer!

try AESpassword.(113d4aea6f1e699670deaa0a647850305466d4d8760b5c34cad4ccc3aef6cc30)
couldnt parse decrypted.(deadbeef)
(s2.4) pass.(113d4aea6f1e699670deaa0a647850305466d4d8760b5c34cad4ccc3aef6cc30) | process_telepathic: key.(1415731214146562750) got.(7fc0f15c70b0) len.25 from 11843209251668136103 dist 38 vs mydist srv 28 priv 36 | 209.126.70.159

That is what was received by the .170 server

>>>>>>>> directsend.[[{"requestType":"findnode","NXT":"17982454456787380714","time":1413700907,"key":"1415731214146562750","data":25},{"token":"c4vm81rl4m295gbb34o4fgbtrfsihonndahasqg54jltspsnm5peo2maetp81381lh002jcn58e9d22 ufa6g6i8em7eqs71cdhscqhfremmgfn0r186dmg3oc3ko1nhpm6v7tqmj9vnejghdirghbada1t4g6m 9r"}]]

the above was send from the .159 server whose pubid is 13434315136155299987 and the private addr is 482478496576188177

The deaddrop address was obtained via need to get s0 deaddrop from 3078458623062153086, which was independently calculated by both nodes and the 170 server published  1415731214146562750

Ran into a bit of a snag as each relay retokenized each packet, so I had to make a passthrough, this actually makes things a bit more confusing as now the same IP will have quite a few different acct #'s

So neither node communicated to anyother node it's IP address, but the message still got through. Instead of broadcasting to achieve this (like bitmessage does), the DHT mechanism is used, and it is log2(N)*K, which is much less than N for any reasonable N and K values.

Now I can add some higher level logic to the IP-less routing, very good progress!

James

Fresh board, just got started.
I've been sidetracked by writing up James' thoughts on anon communication. I'd really love for people to pitch in and leave their thoughts on the API in those threads. It would make my job a lot faster/easier, and there is a 1000 BTCD bounty if you can break the API. Just play with it, jot down any notes, and see what damage you can do

      profit    

people might be selling unity to sell their NXT. you can still sell at a profit from ICO if you got in early enough

i think it's because supernet hasn't released anything yet (that the average person can use) and the quick buck investors are bored with it

is there any sane reason why the supernet price dropped suddenly ?
Because of what XC is doing ?

Not yet, but you can certainly install VirtualBox and run a linux instance.

Do you have a build that is running under Windows Server 2008?
Then I could rund some nodes, too...

that would be great!

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 going out of your node is randomized.

Hey James, I'm currently helping with some VRC projects, but I could set up some VMs to test with next week.  Maybe this weekend if I'm lucky.

Lol.

I believe over a dozen people have compile and run recent versions. the build process is not as streamlined as it should be, but it is still evolving.

anybody that can issue command line RPC call can test the SuperNET API and this testing is what is needed most now. Things would go significantly faster if there was some organized testing of the API going on. At the API level, it can be treated as a blackbox, so no need to understand how it does things, just what it does

James

https://github.com/jl777/btcd

we'll just have to watch what happens with supernet and blocknet. until one produces something the average crypto user can use then it is all speculation

supernet does has some code that a literate person can look at though, which is nice if you can read it (i can't)

are people currently able to compile the available jl777 code and get a glimpse of what is being created? i would be interested to know if this is the case




for those who might be interested...

Supernet API thread on supernet forum
https://forum.thesupernet.org/index.php?topic=154.75



user Cassius is documenting API progress here https://forum.thesupernet.org/index.php?board=41.0
appears to be a fresh board




i never noticed this thread was in the market place. why is that?

I've been hearing about how clonenet is going to destroy superNET. It's a done deal.

This should be very easy when clonenet members consist of glorious Bitcoin forks with innovative features such as CoinShuffle implementations, lite web browsers built into the wallet, VPN services that are probably honeypots, facebook groups, and last but not least hype and deceptive marketing. It even contains a NXT clone with much less adoption than NXT!

SuperNET only has Teleport, reduced-bloat CryptoNote ring signatures, and NXT. Not to mention it can use CoinShuffle when Darkwallet implements it. It was also the original (dinosaurs go extinct!!).

But clonenet's vaporizing multipathway giga internet 103.0 new paradigm shifting hype autocloning technology is clearly going to win!



This picture looks cool. This picture is clonenet. clonenet is cool buy now!! --subliminal uber-innovative app encrypted SMS routed TOR-sent message

What if Burger King replaces McDonalds? What if t.v. replaces talking to real people? What if vibrator replaces boyfriend?

Nevermind. It's not funny anymore. Now I'm just depressing myself.

What if LTC replaces BTC?

Maybe they will merge and become a superduperNet!