Mangled Blue, I know you missed the BTCD PoW train.
Now sit back in your losses and relax.  

better read the comments below the article.

The nested encryption will not be easily cracked even if somebody had access to the packets at the router level. They would need access to all the privacyServers in the path and the destination computer. Basically short of an incredible amount of password stealing, not very possible. Especially as we gain more and more nodes as each packet will take a randomized path to the destination and enough of the multisig packets need to be captured and decrypted. Each one being encrypted with a different onetime keypay and nested

James

What you wrote is about btcd or all altcoins in general?

thanks

you still have time too...

BTCD

If you read the darkpaper (link from OP) and last dozen or so pages of the thread, you'll get a good idea of what's going on.

How true!

OK. Now I believe you have investors.
go back to your cage, now! 

This multisig is really fun. After taking all this time to get working, now I just cant stop trying many combinations. All looking quite stable and very solid, but of course it is using localhost, so no real networking errors.
UDP sometimes is pretty finicky, but that is another advantage of the shared secret multisig. It essentially acts as an error correcting code, well at least as long I dont mix in packets that are corrupted. If even one bit gets changed, it will not match the packet crc and so just get ignored, then the decryption will also fail, so I would say the odds of bad data getting processed is ignorable, even using UDP path.

So, that means based on network error rate, we can set the M of N ratio and no only does the multisig give us a lot more privacy, it makes Teleport more reliable. Just imagine 100 rabbits being teleported and if only 40 survive, then the real rabbit can be recreated. That is M of 40, N of 100.

I dont think there is any other crypto that has up to 254 multisig and it is all configurable each time you do a teleport:

{"requestType":"teleport","secret":"","dest":"RUHAPSpJDHeFgFd1J34WHJ69TpkMBsWtBt","amount":".1","coin":"BTCD","minage":"1","M":"128","N":"254"}

The above is the JSON text my code looks for when doing a teleport. The "dest" is the public address and that is something you need to know somehow via different channel. "amount" is the amount of "coin", in this case 0.1 BTCD. "minage" is the youngest telepod you authorize to be used. Remember, the younger the telepod, the higher the attacker's chances of getting some statistical correlation. I would certainly not recommend minage of 1! Then there are the "M" and "N" fields, which are the multisig M of N and that's it. So you can control the teleport's most important parameters, of course we need to get a GUI so you dont have to be editing JSON, but I hope you can understand the basics of using Teleport.

I think I will skip the local encryption and go straight to a linkable library. I want to do some testnet teleports sooner rather than later! Since it is testnet, it wont matter if the telepod file format changes and I cant really test the third onion layer. OK, you convinced me, time to port into BTCD core.

James