We have plans to support algorithmic adjustments to the host price, depending on a variety of configurable inputs. We expect that, in the long term, hosts will have a large number of tools to help them set the price. More flexibility will be provided as the product continues to mature. For the time being, other features are taking priority.


He makes a few valid points about the potential pitfalls of building systems like Sia. Sia has either already addresses most of these problems, or has plans to address them in the near future. I don't want to do as much as point-by-point, but I'll address the big things that stood out to me. If there's something else in his post you would like addressed, let me know and I'll go into more depth.

1. Sybil Attack

This is probably the biggest thing we haven't fully addressed. While we do some IP address gating to help minimize the Sybil attack, we're not doing as much as we could be. Storj requires everyone to have 10,000 Storjx coins, which is not a bad defense mechanism. You can also use web-of-trust style barriers-to-entry, or use trusted whitelists to fill out a large portion of your hosts.

We have not worried about it too much up to this point because it's both annoying to execute and the payoff is very tiny, at least while the network is small. We will have stronger defenses in v1.0. We are planning on introducing a 'burn' that hosts can participate in to be put on a priority list, from which renters will be drawing a large number of their hosts.

Ultimately, the way you fight a Sybil attack is by making identity expensive. In Bitcoin, a Sybil attack is fought using POW. To submit a new block, you need a massive amount of hashing power. Sia takes a similar approach. To make an identity, you must demonstrate expense. Expense can come in many forms. The simplest is burning some volume of coins, which I think we're going to call 'cryptographic advertising' or something similar. Another form of expense is owning an IPv4 address. While it's not that expensive, most people already have 1, which means you can costlessly give power to legitimate users while adding expense to Sybil users. Unfortunately, there are not many costless things that we can leverage to prevent Sybil attacks, which is why we are probably going to resort to cryptographic advertising (also called proof-of-burn).

2. Deduplication Attack

An attack was mentioned where you can't be certain about the redundancy of your file. Maybe all of the redundant copies are lies? This is an actual attack, and I usually call it a deduplication attack. If you upload a bunch of redundant pieces such that anyone on the network can repair them, then one person can gather a single copy and pretend to store at maximum redundancy, receiving pay for lots of storage that they actually aren't participating in. Sia prevents this by encrypting each piece separately, using a random key. This completely stops the deduplication attack, but has a tradeoff: only the uploader can repair the file if pieces start to go offline.

Sia's reliability is very good, however. Even if you are only logging in every few weeks, there should be no issues with uptime. And eventually, we might be able to implement a pass-the-hat type of protocol that allows for files to be refreshed for as long as there is money. (though, that would require a soft-fork).

3. ISP issues & legality

We've gone over this a few times, and there are some threads dedicated to it at https://forum.sia.tech, but the quick version is that it's legal for hosts to accept random files from strangers, even if they are illegal files. If the host is caught with an illegal file, they are required to remove it within a certain period of time (usually 24 hours). Sia v0.5.0 (recently completed, though we haven't finished updating all the links yet) has support already for complying with these types of requests, though no host has ever been asked to remove a file thus far.