Another feature users might like is to be able to set the Hosting Price in line with the competitive average.
I see the 'Estimated competitive price' continuously fluctuating (I assume based on the network available storage and user rates), it would be good to set a +/- variance against this open market rate, so if Im new and want to pick up contracts quickly I can set 'recommended market -5%', or if Im established set 'recommended market', or if perhaps I want to shrink my storage (without dumping all my contracts) set 'recommended market +5%'. I suppose in the early days like we are now, you need an absolute minimum, or everyone sets a percentage and the bottom falls out, perhaps the minimum hosting price should still remain.
This also saves me missing out on lucrative contracts if market conditions means space becomes short (Im not undercharging), and ensures I can pick up contracts if there is spare capacity (Im not overcharging).
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.
What response (if any) do the sia devs have to this claim? Follow the
provably scams link for his analysis.
Storj, Maidsafe, Sia, and Permacoin
(and any other decentralized file system that pays to store a file instead of only paying to serve the file) are all
provably scams.
He seems to be saying (among many other criticisms) that the economics of decentralised cloud storage systems can't work, and storage providers will end up using dedicated servers and smaller opertions will get shut down by their ISP's. He's a wacky guy, but not a light weight thinker. Does he have a point?
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.