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