Dealing with NAT connectivity issues and other messy networking, slow progress. So, I decided to just see what happens if I ran the following API:

./BitcoinDarkd SuperNET '{"requestType":"teleport","coin":"BTCD","amount":".0001","contact":"s0"}'
now I have about a dozen telepods on my s2 server and already added contacts on both for the other. Now once you have a contact, it is put into the database, so it automatically loads. also, both servers have no connection issues.

the teleport command uses a simple genetic algorithm to select the telepods to use:
start evolving.14 at 384601.546000
     hwm {"c":"BTCD","tpd":"{\"v\":\"0.00010000\",\"t\":1414326260,\"c\":1538090497,\"x\":\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\",\"p\":\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\",\"a\":\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\",\"o\":0,\"s\":\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\"}"}
-> evolved with bestn.1 0x7f952c0a7d50
finished evolving 1 at 384601.846000

Once it finds the telepod, it encrypts it using a shared key and a one time password:

private_publish({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) -> s0.7
decrypted.({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) len.479
location.374764261261180465

telepathic.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) len.495 -> 140279230066432 374764261261180465

Now it sends it over the network using a findnode command:
telepathic send to s0.7 via 8447171643292973228 using 374764261261180465 (af79ca8f7e1eee29af74a8db4a12a8527e41613d975f3406e61487b955e26797)

Basically it is pretending to be acct #374764261261180465 and searching for node 8447171643292973228
You have to keep in mind that the actual destination's node address is 10694781281555936856.

####################### on the s0 machine, it receives a findnode for 8447171643292973228
but while it processes it, it notices that it is "from" 374764261261180465, which just happens to be in its list of possible senders that means it is really the 7th message from the s2 server acct 13434315136155299987

myNXT.(374764261261180465) kademlia_find.(findnode) (8447171643292973228) data.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) mynode.0
updated.1 (8447171643292973228)
saved parsed decrypted.({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"})
DECRYPTED expected (s2.7) ({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) lastrecv.6 lastentry.191
updated.5 (s2)
(s2.7) pass.(af79ca8f7e1eee29af74a8db4a12a8527e41613d975f3406e61487b955e26797) | process_telepathic: key.(8447171643292973228) got.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) len.495 from 374764261261180465 dist 28 vs mydist srv 32 priv 32 | 209.12


So a telepod went from one computer to another without any node knowing the actual IP address for the destination! Then I realized that I didnt actually hook it up to the telepod processing, so the sent telepod is now in limbo. I guess this will help test the teleport cancelling logic.

Still quite messy and many loose ends, but the fundamental process is working if all the conditions are met. Now I have to get the telepathic transfers much more reliable and of course activate the reception side of teleport, eg. cloning.

James

P.S. wc *.c *.h ->    34611  118707 1286274 total, yes that is 34000+ lines of code mostly written by me and it doesnt include:  wc cstdlib/* gzip/* includes/* libtom/* platform/* -> 53810  236325 2181668 total
almost 90,000 lines of code is compiled into SuperNET, this is over and above the libwebsockets, libuv and other libraries

Dealing with NAT connectivity issues and other messy networking, slow progress. So, I decided to just see what happens if I ran the following API:

./BitcoinDarkd SuperNET '{"requestType":"teleport","coin":"BTCD","amount":".0001","contact":"s0"}'
now I have about a dozen telepods on my s2 server and already added contacts on both for the other. Now once you have a contact, it is put into the database, so it automatically loads. also, both servers have no connection issues.

the teleport command uses a simple genetic algorithm to select the telepods to use:
start evolving.14 at 384601.546000
     hwm {"c":"BTCD","tpd":"{\"v\":\"0.00010000\",\"t\":1414326260,\"c\":1538090497,\"x\":\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\",\"p\":\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\",\"a\":\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\",\"o\":0,\"s\":\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\"}"}
-> evolved with bestn.1 0x7f952c0a7d50
finished evolving 1 at 384601.846000

Once it finds the telepod, it encrypts it using a shared key and a one time password:

private_publish({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) -> s0.7
decrypted.({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) len.479
location.374764261261180465

telepathic.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) len.495 -> 140279230066432 374764261261180465

Now it sends it over the network using a findnode command:
telepathic send to s0.7 via 8447171643292973228 using 374764261261180465 (af79ca8f7e1eee29af74a8db4a12a8527e41613d975f3406e61487b955e26797)

Basically it is pretending to be acct #374764261261180465 and searching for node 8447171643292973228
You have to keep in mind that the actual destination's node address is 10694781281555936856.

####################### on the s0 machine, it receives a findnode for 8447171643292973228
but while it processes it, it notices that it is "from" 374764261261180465, which just happens to be in its list of possible senders that means it is really the 7th message from the s2 server acct 13434315136155299987

myNXT.(374764261261180465) kademlia_find.(findnode) (8447171643292973228) data.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) mynode.0
updated.1 (8447171643292973228)
saved parsed decrypted.({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"})
DECRYPTED expected (s2.7) ({"deaddrop":"8201588598475185021","id":7,"time":1414960364,"type":"teleport","attach":"{\"c\":\"BTCD\",\"tpd\":\"{\\\"v\\\":\\\"0.00010000\\\",\\\"t\\\":1414326260,\\\"c\\\":1538090497,\\\"x\\\":\\\"70d63e7c807a4734080e91ef05fc77ad151ed1cde6410bf201b06f98df1cfabe\\\",\\\"p\\\":\\\"UqoYd3rocuGrN4XdA6smBdQx4BTeeDqpBTgtq2B8N94LNCQR6ifC\\\",\\\"a\\\":\\\"RDqzsrkE6Th8rFZqJUfYdo99hzSJu1khuo\\\",\\\"o\\\":0,\\\"s\\\":\\\"76a9143214e137b7bf0c3cf7172d3e13a3b146c00e318f88ac\\\"}\"}"}) lastrecv.6 lastentry.191
updated.5 (s2)
(s2.7) pass.(af79ca8f7e1eee29af74a8db4a12a8527e41613d975f3406e61487b955e26797) | process_telepathic: key.(8447171643292973228) got.(1e3190d8212ed742060637316591a2cc5bc75871a6f311ee836f226970536548695eb51a5996da1 3027644556411630cdf320a31949af01f8bd2ffca9d946b855ac5ddc78dc3e8cd80c386736a2328 e28ceed4e793bbeba63f897064f0eef802abf01f0bf21f16d97da9441a7070ab8e043f4da1e5953 8ead72f53540c224d6ad1d00a8caf8e7d88b65785cda44be9a20675e83fafddac150d0b250e8184 9bbe135e0f0d7ebf10f1b593a903bf3a01423a0d5da94cabb2c1a2ac7b6c2f40a4bc7d4a06327c6 8a3aa0970d97c78b6f3dca1316a628a2f803876163e293640f5391a661aad3d170f89c0999398d7 bfce99523ba2257d18f56ef56730209162a4c41963567920482a8a03ccc9f12be8020d5d8e51184 49acc94319c8c7e42acbd3b16672fa73131149d2b470149a14320285c6c6d09924bfe892ef86fd8 b501daaea40e28694ea329a3da7e00300c3303587dec31509b14572bb79499fc481a7e0193beccd 544cce79910fbd8012bc62255637547b955cc1dae41ac73a4230030f9ff6dfe917e1bfbcaec4f0f 2c926b3254dd4a98b644071cde9c1ad272bb91d5e22947c93f55c148ae207fb281f02b7182dfbba 85086fdf38cb5370fc95c13b810b815c77c30bcbe895efeafe82f698b446b227e7d095e50073886 50d62046acbf1056e09e16eccecd3db592f457e87d) len.495 from 374764261261180465 dist 28 vs mydist srv 32 priv 32 | 209.12


So a telepod went from one computer to another without any node knowing the actual IP address for the destination! Then I realized that I didnt actually hook it up to the telepod processing, so the sent telepod is now in limbo. I guess this will help test the teleport cancelling logic.

Still quite messy and many loose ends, but the fundamental process is working if all the conditions are met. Now I have to get the telepathic transfers much more reliable and of course activate the reception side of teleport, eg. cloning.

James

P.S. wc *.c *.h ->    34611  118707 1286274 total, yes that is 34000+ lines of code mostly written by me and it doesnt include:  wc cstdlib/* gzip/* includes/* libtom/* platform/* -> 53810  236325 2181668 total
almost 90,000 lines of code is compiled into SuperNET, this is over and above the libwebsockets, libuv and other libraries

I havent seen how he behaves on the buy cycle, so not sure
if we can predict how he will trade, then he can become a money pump
eg. pumping money into our wallets

they key is to figure out its algo

Our wally bot seems to want to set the price at .005
it pushes the price down to .005 and then it starts doing the same on the buy side
this bot has a lot of capital, probably funded by the massive gains it has made over the months
just look at the side of the orderbook that is changing all the time to see which way the bot is pushing

so it is playing a game of attrition. insisting the price is .005, until everybody just accepts it. then when enough people sell to it at that price, it will flip directions.

anyway, i dont have time to figure out how best to beat the bot. now that you know what it is doing, hopefully someone will figure out a strategy and we can all adopt it and break the bot

James

I got making telepods working, and sending them is just a matter of reliable communications. I have it automatically monitoring and changing the status of telepods. The accounting is a matter of scanning the database, which is in place, so making Telepathy is the critical path for Teleport now. Anyway, this is weekend so I think I deserve to do some fun coding, instead of work coding.

Got some INVALUABLE feedback from zahlen on Telepathy
No giant flaws, but now there is a way to have out privacy without massive redundancy

turns out I had been using a hamming DHT distance function instead of the more pure Kademlia xor value as a number metric
intuitively it seemed so much better to have bitweight being metric, probably due to my obsession over the privacy issues.

Anyway, I have confirmation that in a network topology with enough connections, my approach will get rapid convergence and minimal redundancy, while still allowing the destination node to process each packet.

Also, zahlen has some advanced math method to find deaddrop addresses efficiently, so for now I will just use a fixed distance address, but we will eventually have deaddrop addresses that are shared among all nodes that are inside an H-ball. that is all the nodes within distance H of the deaddrop address. So, the intended destination node can be any of the nodes inside the H ball.

by using the hamming distance metric, this maximizes the number of nodes inside the 64 dimensional H-ball.

The sender is protected by using multiple onion packets to inject a DHT search thread. These will be started from the known nodes that are maximally distant from each other and the deaddrop address, but with no direct relation to the sender. So, after a few hops, nobody will know who started the findnode thread. and each thread dead ends at one or more terminal nodes that are closest to the deaddrop address. Until then, the routing is the very steep "send only to nodes that are closer than me" method. I also put in a duplicate packet filter so you dont end up sending the same packet to the same destination. This means network traffic will be at most alpha * log 2 of N, where N is the total nodes in the network and alpha is some small number 3 to 7. the duplicate filter will usually reduce the packets required to reach the terminal node.

Now at the terminal node, it will send the packet to all the nodes within distance H, so all nodes in the H ball will be guaranteed to handle the packet. the duplicate filter will again limit things, but the max would be alpha*number in H-ball extra packets at the end.

So, it will be like fireworks that shoot to a point and make a starburst. with 3 to 7 for each telepathic transfer it will get the packet to the right node, but only the actual destination will know the packet was meant for him

Some possible issues with AES key exchange, but that is all in a single function, so if any changes are needed, just a matter of improving it.

Now, if you use DHT based torrent programs, you probably notice sometimes it takes forever to get a transfer started. This is because nodes get clumped into sets and these sets are not guaranteed to have any overlap. This is really the only issue remaining, but the design of having a whitelist of servers should solve this nicely as all nodes will have a shared subset of the whitelist nodes. and by starting each DHT search from maximally distant points, odds are quite good to find at least one path that reaches the destination node.

I will have to run simulations on various network topologies to verify this and this ties into having each node create a good map of the existing network. This doesnt have to be done quite at this stage, but we really should validate the larger network sizes before we deploy to much larger scale.

James

tl:dr Telepathy will be a fantastic improvement in privacy and it will scale to any sized network

I pushed a version that supports both http and https, via 127.0.0.1:7776 and 127.0.0.1:7777 respectively
this is required to allow the GUI to access both SuperNET and BTCD from the same HTML.

I also added GUIpoll task in the SuperNET app, which will allow for unit tests and other programs to be written that uses feedback from the other nodes.

That was required so I can automate the laborious and error prone process of establishing a telepathic link between two nodes. I did manage to get it to work, but it required a lot of things to be done correctly and in the right sequence. Since we need to get the GUI and test programs done, it made sense to make this now.

So many details...

Anyway, I am getting some invaluable feedback on Telepathy from zahlen and will be incorporating that. Things are getting very close and I could get some manual point to point teleport working, but I'd rather get a semi-automated one if only to save time while debugging.

James

I suspect the latter

Not sure, but now that the bot is low on BTCD, it seems to be starting operations on the bid side. so maybe it works both directions?!

That would make sense. When it runs out of ammo, it has to reload. Now that the price has broken all the technical analysis downtrend indicators with a strong uptrend, maybe the bot will just start pushing the price up for a while.
I havent paid much attention to the price last couple months and this annoying bot wasnt around then.

after all this battling the bot, I need to rest for a bit before debugging the last part needed. telepathic transfers used to work, but I must have made some change along the way, but too tired to remember what it was. Shouldnt be too hard to find and fix. I got the teleport all happy on the send side, so once the telepathic send works, the final piece of the puzzle is the receiving and properly processing the telepod. The reception used to work, but probably got disconnected along the way too.

James

There is a bot that is ACTIVELY manipulating the price.
quite effectively too.
If you look at the price on bitcoinwisdom, you will see that there is a pretty even spread of asks all bunched together, within 10 satoshis!

About 5 BTC. This makes a barrier and also crowds out the orderbook so you cant see what is really going on. It is also chaging things several times per second to create the impression of a lot of activity. What it does is pushes the price down by clearing out small bids and making lower and lower asks.

Earlier there was about 10 BTC in 30+ orders around .0049 and 3 BTC between that and .008

So, there is no investor panic going on. It is just one guy running a bot. And he is doing this on many different coins.

His game is this.

Have the bot on bittrex and cryptsy, but run just one of them at a time. Create some FUD push the price down on one (easier to create fear, especially in a bear market) then as people get convinced everybody is selling, they start selling. Remember this is just happening on one market. So soon the sell price on one exchange is lower than the buy price on the other exchange where the bot is idle. Guaranteed profits! Then the bots switch.

so first one exchange price is pushed down. arbitraged, then the other. Doing this it creates these mysterious price declines as we are making such good progress. All the way down to .005! But there was really very little for sale below .008 as this operation is being done on dozens of coins, so only so much budget per coin.

Now this bot is not caring about price at all. Whatever the price is, it just picks the exchange with the lower price, pushes is down until it can arbitrage. The arbitraging evens the price out and then the pushing starts again. Now this bot stays away from even a 1 BTC wall from what I have seen and certainly anything larger it stays about 10% away from. However if there is no big wall, it happily startings pushing the price down, even filling some orders if they are small enough.

These bots are probably on autopilot, so that means a clever person will be able to trick the bot.

tl:dr now that whale dumper is gone, recent price decline is caused by one guy's bots and a few BTC wall will keep it at bay. Maybe we can come up with a way to beat it and win 1 BTC per day from it. then it will certainly go away

James

figured it out
there is an "immediate or cancel" mode that seems to be a new feature and somehow it got selected
so no bittrex conspiracy, just my not noticing the new button

bittrex is not allowing me to put in bids
I am able to put in any sell, but not bids
my orders appear in the "your orders" section and then just disappear as if I cancelled them

the steady drop due to bots pushing the price down and also "bugs" with placing bids...
maybe I am the only one with problems placing bids?
if not, then, well, conspiracy theories abound

James

did I mention I am pretty sure I will get a telepathic teleport working over SuperNET today?

James

I confirmed there is a bot or trader that is pushing the price down. As a seller, you want the highest price, well at least if you are not trying to manipulate the price. So if there is a bid at X and ask at Y, maybe you would put in an ask just below Y. But our bot is putting it just above X.

What this does is create a constant downward pressure as logical buyers see the lowest ask drop so near the highest bid, they pull their bids back.

And the cycle repeats. So at the cost of a few BTCD at a bit lower than market price and over a week, you can push the price down quite a bit. I think I will do something about this

James

pushed a version that displays a simple debug HTML at http://127.0.0.1:7777
I cant quite test it as I cant build the mac wallet with CORS support yet, but at least it looks like it should work

it will look for the html files in a html directory relative to where SuperNET is run from.

James

no problem. I feel like I am not making much progress as I never get to where I can debug teleport itself, but all these other things need to be in place for a user friendly GUI based solution.

I added a mode with "settings" API that allows the entire SuperNET.conf file to be replaced, so the first time you run the GUI, it can walk you through the basic variables that are needed and make a working SuperNET.conf. Then it can automatically relaunch the SuperNET, so from the end user point of view, it should just look like it works.

Then there will be a settings page where you can see and change each setting, so the forms on this page just call the settings API to update a specific field.

James

Added "stop", "start", "GUIpoll" and "settings" API calls

This allows the SuperNET to be stopped and restarted. Especially useful after the settings API is used to modify the SuperNET.conf. GUIpoll allows the GUI to receive the results of pending requests. With these, I believe all the interface API are in place, so the GUI can be completed.

Now I go back to debugging teleport, current status there is that maketelepods creates telepods and telepodacct displays the telepods that you have, including the changing status. It should also display all the transactions relative to a specific contact or coin or everything.

Also, the contacts API appears to work fine.

James

P.S. also fixed a subtle and small info leak in onion construction, thanks to discussions with Cassius

I intentionally didnt over-market SuperNET
This ensures that a large percentage of people have not even really found out about it and represents future investors.
Once you saturate the market, then who is left to buy it afterwards?

After market support is quite important. Now in a bear market like we have now, it is tough for everyone, but with very little overhead, it is just a period of lower prices that will pass.

I keep coding away

James

you can stake with encrypted wallet
just unlock wallet and make sure the "for staking only" is selected

Internet of coins published a similar concept a couple weeks before I announced SuperNET, but their solution wasnt described and it turned out to be a totally different approach.

After getting 5700+ BTC and almost 1000 different investors and about 6 weeks later, we are seeing projects with similar approaches to SuperNET or at least in the same space.

I have opened sourced even my active dev branch. https://github.com/jl777, so no need to infiltrate a spy, just follow my commits.

If there are any clone devs who are able to keep up with me, I want to hire them! A privacy solution that is closed source is DOA in my opinion. Any single subtle bug and all the anonymity is gone. Even Tor, which is a significant project, is always getting this attack or that. Imagine a closed source project, anything would be possible. So, any anon tech that is not open source, I recommend to avoid.

Now, if anybody wants to use a clone of BTCD with a clone of SuperNET using a clone of NXT using a clone of the SuperNET GUI, instead of the original, well, why would they? What happens if there is a bug due to a mistake in the cloning or some subtle algo problem that requires the original author to fix it? it is quite likely that if any significant part of the total solution is changed, nothing will work.

I dont think you realize how difficult it is to get a stable system as complex as what I am building. Even timing dependencies are important. It is like taking the engine and transmission from one car and just expecting to pop it into another. will it work? probably to some degree. will it perform at maximum levels where the wind resistance is tuned along with using the heat output to recharge the batteries to give extra battery voltage, which allows some extra feature, which is needed for another, etc.

Since I am coding and coding and not spending the time to document the specific reasoning for all the choices, that means just cut and paste will make, another SuperNET node!

Now LTC has maintained 1/100 to 1/30'th of BTC value and this is probably about right for a clone. With SuperNET worth several million, that means a clone will be worth less than $100K
It takes a lot more than 1000 hours to create something like BTCD + SuperNET.

Also, the 5700 BTC gives some protection to SuperNET and thus BTCD as without it, I just dont see getting many coins to cooperate. Without significant funding, there is no "glue" to bind together a supernetwork and after the blocknet result, I doubt any clone scammer will be able raise any significant amount of funding.

James

PM me your email if you need an invitation to slack.