Topic: Solution to Sia/Storj/etc DDOS issues and Sybil Vulnerability - page 2. (Read 3269 times)

That only applies in a bounded opportunity cost scenario, because it pays Sybils to reveal themselves in exchange for losing the opportunity they would have gained by not revealing themselves.

The profit potential in Sybil attacking the decentralized file system is unbounded up to the total value of the expenditures for file storage.

Also the research paper quoted does not solve the problem that the Sybils can take the payment and then reestablish themselves as another Sybil identity (because the protocol hinges on the fact that Sybils don't reveal any permanent identity) and take payment again over and over until the system is drained. The paper is nonsense.

I wouldn't say "Period", read https://www.researchgate.net/publication/220797029_Informant_Detecting_Sybils_Using_Incentives and reconsider your position, please.

That doesn't prevent a Sybil attack to remove redundancy.

TPTB_need_war explained the technical reasons in February. You can search his archives. I don't have time to dig it up right now.

Edit: super3, you were discussing it with TPTB back at that time:

https://bitcointalksearch.org/topic/m.13833591
https://bitcointalksearch.org/topic/m.13814104
https://bitcointalksearch.org/topic/m.13650450

Edit#2: now I remember my rebuttal to section 4.2 of the Storj whitepaper. Yes you can encrypt files and trick the nodes into being forced to store more than one copy of the file, but this does nothing to prove that all those copies are not stored all on one hard disk. The problem is insoluble. There is no way to insure redundancy. Period. Sorry all decentralized file systems are insolubly flawed.

Again the nodes can Sybil attack the system and all be sharing the same hard disk on some centralized server. That was my entire point.

As I said, I (AnonyMint) invented proof-of-diskspace/storage in 2013. And I also proved it was insolubly flawed. Now you copycats come here 3 years later and don't even check my prior art. So you deserve to lose.

Please read the Storj whitepaper, Section 4.2. "Each shard[of the file] is uniquely encrypted. This means that malicious farmers cant pretend to have multiple redundant copies of a file when they only have one."

You have to encrypt the file anyways, so just make each piece unique. This solves the problem.

Even assuming you are right about all of this (which I think you may be), I still don't think this will stop the coming bull market for file storage coins; speculators don't care about functionality, they care about hype!  Now that Ethereum is just about dried up, they need a new fantasy to cling to, I think this might be it.

No decentralized storage can solve the Sybil attack on storage where many nodes are sharing the same storage, but collecting payments or otherwise deceiving the claimed redundancy as if they have multiple copies of the storage.

It is a fundamental weakness that can not be fixed. Decentralized storage can not work. Period. End of story.

Latency is not reliable enough to be used as an indicator.

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.

I wrote those same criticisms many months ago. And you didn't even deal with the copyright issue and the fact that ISPs/hosts will block protocols that promote theft of copyright.

Decentralized file storage is a non-starter. The speculators are willing victims. My popcorn is ready to watch them blow up.

The person doing the downloading is the one paying for the bandwidth, you pay for them in the same network connection. Downloading a file does not take funds from the renter, otherwise the host could just lie about who had downloaded the file (or download from themselves repeatedly from a cheap local connection). No DoS attack here.


You are misunderstanding how the Sybil defense mechanism works. Having multiple VMs, or even multiple full machines on different IP addresses, is not sufficient. You also have to have a history of burning coins, and there's a linear relationship between how many coins you've burned and how likely a renter is to select you. If you want to be as likely to be selected as a 10,000TB host, you need to burn enough coins to keep up, and they are (per the siafund fee) burning approximately 10% of their income.

And if you actually have 10,000TB, you haven't performed a Sybil attack at all you're outright a legitimate node on the network.

You can leverage identity to manage the Sybil attack as well, but right now the only real solutions to identification that we have are all centralized in some way. Burning coins is decentralized.

You merely need to download the file over and over... which causes the renter to run out of money.   Same as a DOS attack downloading a web page.


Attackers always spend the same money that legitimate hosts spend.   The "attacker" here is running completely legitimate, full copies of the protocol.   The only difference is that they are running multiple docker containers on the same machine... rather than running on multiple machines.   There is simply no way to know that outside of IP.   Just like a DOS attacker runs a fully legitimate client, so too a Sybil attacker runs a legitimate server.


I think that succinctly sums up what I meant in the original post.

Since DDOS and Sybil are inverted forms of similar attacks (multiple clients vs multiple hosts), these decentralized storage networks haven't introduced a "new" problem to the domain of hosting.  Indeed, any existing cloud hosting provider could, today, "claim redundancy" on your data... but physically locate it on the same machine.   The solution to this problem lies in the transport and social layers... not the consensus protocol.

There are bugs in Sia wallet.

I think that you are bringing up a couple of separate concerns, and that they cannot be collapsed into a single concern.

For example, a host or a renter might be subject to a DDOS attack (especially a host) that makes business difficult. But it's much easier to DDOS a single host than it is to DDOS an entire file, because you need to know all of the hosts that have that file (not always public knowledge), and you need to have enough resources to DDOS a large enough number of hosts to make the file inaccessible, and that number could be dozens of different hosts, which is a different level of attack than DDOSing a single host. As far as I am aware, there's not a whole lot that you can do about DDOS attacks (other than work with a service like CloudFlare) - if someone wants to send you network traffic, there's usually a way for them to do it.

The Sybil attack, or 'not really redundant storage' is a different concern. When uploading files to the network, you want to upload to many different hosts (as a part of the security model), and you want to be sure that these different 'hosts' aren't all putting your data on the same physical disk. There are two components to this. We can solve one of the problems pretty easily by encrypting the redundant pieces using different keys. So, we can force the network to store the full redundancy of the file, though this technique is not enough for guaranteeing that the data is not on multiple separate physical drives.

You can introduce a monetary component to make Sybil attacks expensive. On the Sia network, for example, all money transferred between renters and hosts is measured on the blockchain and includes a component of proof-of-burn (in the form of siafund fees). The proof-of-burn component means that this activity is expensive to spoof, mitigating simple Sybil attacks and forcing attackers to spend significant monetary resources executing an attack.

Depending on how much you trust something like an IP address, you can use IP addresses to get a sense of the actual physical location of the data. But you can also do better than that if you've got multiple servers spread over a large geographic area. You can do ping-time challenges to the hosts that are storing your data. If a host claims your data is in China, and another host claims your data is in America, and you've got a server in each, you can do challenges that require the host to respond in under X milliseconds. The laws regarding the speed of light give you a way to be absolutely certain that your data is being stored in both China and America, because the ping time on the challenges from your server in China to the host in China will be very small, and the ping time on the challenges between your server in America to the host in America will also be small.

So, if you are willing to use a more elaborate setup, you can definitely get proofs (based on the fact that data cannot travel faster than the speed of light) that your data is in two different geographic locations. And depending on your trust model, you can outsource these challenges to the network (have someone else do the challenges on your data and trust their results).

The really nice thing about both DDOS and Sybil attack prevention is that it's not a consensus layer problem. Consensus protocols are notoriously difficult to upgrade, and even more difficult to get right, but we don't have to worry about maintaining consensus. We can update nodes and improve techniques in ways that don't require the whole ecosystem to upgrade simultaneously, so as we continue to think of better ways to handle DDOS and Sybil attacks, we can incrementally push them out to the network.

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.