Quote from: earonesty on June 06, 2016, 03:57:01 PM

All cloud storage networks, coin or otherwise, are vulnerable to DDOS attacks, where attackers cause renters or hosts to spend enormous sums of money by repeatedly downloading the same files.

The typical solution to these DDOS attacks remains "IP blocking". For TCP/IP, this can be effective, and when coupled with some sort of tracing back to the source, results in DDOS attacks that wane and can be responded to fairly rapidly.
The practice of IP blocking has spawned an open and somewhat contentious network of public and private IP blocklists. While it is likely that these blocklists will be relevant for storage coins, there will be undoubtedly be a need for blocklists to be maintained that are specific to cloud storage protocols.
Blocklists, even if fairly maintained, are centralized and many use DNS for distribution (see https://en.wikipedia.org/wiki/DNSBL). A blockchain protocol for blacklisting may be ideal, with nominations, evidence, voting and expiration all occurring "on chain". (It should be obvious why blocklists would greatly benefit from decentralization)

All storage coins are additionally vulnerable to a "not really redundant" Sybil attack.

Any attacker can quite simply spin up many instances of the protocol on a single host - increasing his exposure and income - while completely defeating the purpose of redundant storage.
There is currently no way for a renter or user to know where its hosts physically reside, and whether they are on the same machine or not.
One way of mitigating this is to publish IP addresses of hosts as a part of file contracts or storage advertisements. Renters should then prefer IP's that are somewhat distributed across the IP space. This can, of course be defeated by routing diverse IP's to the same data center. But this can be trivially detected and violators can then be published via the same IP blocklists above... using either DNSBL or blockchain tech.

In summary:

Any time you are "hosting" data, you need to deal with DDOS attacks.
However you solve it, I don't care: this solution will, de facto, provide an analogous solution for Sybil attacks on storage network redundancy

So don't worry about Sia/Storj sybil attacks. They are just inverted DDOS attacks, and those have to be solved anyway.

These are issue that thought about and solved early on. We tend towards micropayments, so the attacker would have to pay for all of the downloads. So this would be less of the farmer being attacked, and more of the farmer getting rich.

As far as DDOS attacks, good luck. Only the renter should know where all ~40 of the pieces are. Even the the unlikely event that the renter has exposed the location of all the shards to the farmer the odds are way against the attacker. The farmers will reject connections from the attacker, so the attacker has to execute a pretty massive attack to have any impact. Sia checks the file every ~2 weeks last time I remember, we can check up to 10 minutes or less. It takes seconds to spin up a new storage contract for DDOSed shards. This is what happens if execute a DDOS attack and the user is using our service in the worst case:

1. You start a massive DDOS on all 40 farmers that store the data.
2. Most of them are behind tunnels, so their tunnels reset. Now only us and the renter know where the new locations are.
3. The ones that you are currently attacking, have already been replaced in a few seconds.
4. No data is lost, although the file might be inaccessible to the first few seconds as we tunnels reset. Once we know a DDOS is happening, we can spin up nodes and tunnels faster that any attacker can find and DDOS.

tldr; DDOS works because its a distributed network attacking a centralized network. Distributed network attacking a distributed network is as effective as trying to drown a glass of water in a lake.