Please explain me how do you want DDoS a decentral system ? The whole idea about crypto currency is that it is a decentral system not like the FIAT one. The only thing you can DDoS is Central Exchange system as far i know is Supernet part of NxT exchange system which is already decentral and leaves the Attackers no chance for them to do anything.
Of course it is possible. You flood the network with transactions. The network should be able to respond to this and black list the node doing this though.
But, I can't take a sockpuppet account seriously. Be a man and post under you main account "youareanidiot" or whatever you name is.
I wrote "DDoS the anonymity". If you had any technological clue, you would understand that James' proposal to broadcast to all nodes such as Bitmessage incurs a resource cost that rises as the square of the number of nodes. Surely James has by now realized this, as we notice he has stated this mode might be used only sparingly. I've been waiting months for him to realize this. Next he will realize some more technological problems he may not yet realize, e.g. Sybil attacks. This is the problem with trusting someone who can't write a coherent whitepaper outlining all the technical issues and his specific solutions.
Nodes Squared = Messages sent on the network
1 x 1 = 1
2 x 2 = 4
3 x 3 = 9
4 x 4 = 16
256 x 256 = 65,536
1024 x 1024 = 1,048,576
only the directory info is broadcast and only within each coin network.
Now when a new node appears, it will need to have its info sent to N nodes, but this propagates using the standard bitcoin message protocol.
As far as overall network bandwidth load, a new node appearing adds a minimum N/2 kilobytes of bandwidth as the pubaddr info packet is about half a kilobyte. Assuming 8 to 1 redundancy to fully propagate (I am expecting a lot smaller number) this is an average load of 4 kilobytes per node per new user joining the network, since the total bandwidth is spread across the N users.
So, how much load is this?
Let us assuming that 10,000 users are exiting and rejoining everyday. Pretty extreme case as I personally keep the wallets running nonstop to stay in sync. Since I am being super conservative on the 8:1 and 100% users, let us ignore population concentrations during certain GMT times and see what the average load is for the entire day:
10000 * 4KB (32 kbits) / 86400 = 3.7 kilobits per second
This is no big disaster as even if it is 10 times more, 37 kilobits/sec is not great, but still not anything close to a problem.
Also, this is assuming 100% of the user's of the participating coin networks are actively using SuperNET. Since it is an option the actual number will be less than 100%.
Once the directory info is broadcast, then the privacyServers are making direct UDP routes between any two SuperNET nodes.
Please explain to me a specific method of attacking using Sybil. Each SuperNET API request is signed by the sending account and if it is not from the expected acct, it would be ignored. Unsolicited requests would be associated with the sybil'ed acct which by definition would have no history, so I am looking forward to how a smart guy like you is able to make a sybil attack.
It is possible for a specific privacyServer to be flooded, but in this case the user can switch to a different privacyServer. If hostile forces are starting to attack the SuperNET, then there will be a new market for privacyServer vendors offering hardened privacyServers for SuperNET users to use. If these attackers are just hypothetical, then people can run with the localhost privacyServer. Maybe I will just make it so that the users are randomly selecting from the list of all available privacyServers for each request. Actually this is a good way to increase the anon factor by delinking comms between a node and its privacyServer.
Thank you for your criticisms! They might not be so accurate, but they are making me think to improve the SuperNET. I look forward to the detailed explanation of the method for a sybil attack.
James
See ladies and gentlemen, James is always two steps ahead. He actually created a sockpuppet account to troll himself so that he could add even more innovation to Supernet.
I have never made a sockpuppet, no time for such games, but I do appreciate the humor
This poster is suffering from a well known condition called dev-envy, this is when one dev wishes his ideas were as big as another devs. It is hard to think logically when in an emotional state, but still when a smart dev is making some analysis I am always careful to see if there is some truth contained in the missive.
Now the security and privacy is of course of paramount importance and I am publishing all the source code in realtime. Since Friday I have made over 200 commits, mostly tracking down some system incompatibilities. Turned out it was some change made in libuv over recent months! Now libuv is a fantastic package and I love it, but it is quite complex and quickly changing, so I made a snapshot from the version that is compatible with SuperNET and added that to the repo. I also added the libnacl source to the repo so that the only requirements for the system are clang and curl.
Now I am somewhat concerned about this "sybil attack" as I do not understand how it is possible. So maybe I am totally an idiot like my critic says and I am hoping for some clarification. This is the perfect chance to prove that I am indeed an idiot, so I hope this is enough incentive for the posting of these details. When I dont understand something, it is quite possible I am missing an obvious thing. So if anybody can conceptualize a sybil attack against any part of the SuperNET, please post.
I am reworking this code today, so this is perfect timing.
I debated the requirement for every SuperNET API call to be tokenized, but the support is there and it does add some CPU overhead to the creation of it, so this makes any sort of flood a bit more expensive. Also the encrypted packets are ignored by all but the node it is addressed to, so it will cost a bit of overhead to verify it is not intended for the particular node, but this also means a tokenized and properly encrypted packet must be made to each node.
So, we have this sybil using S different accounts, but all of these need to be real accts and if there is no history (or funds) in it, then the dest node would just ignore it.
Anyway, I look forward to be shown an idiot as this will make the SuperNET stronger. SuperNET should not just be what I envision it to be. Already I am seeing many ideas I never thought of and probably never would have. At some point I would just need to approve already working SuperNET API additions based on common sense and test results. This is as it must be! I look forward to that day.
James
