1) Your scenario includes simple redundancy, whereas in the spec we have k-of-n erasure encoding. This increases the number of floating pieces, and reduces the probability significantly. 2) Users and applications are able to control their redundancy. Our networking testing data will tell us the recommended numbers. User with a large amount of redundancy will shrug this off 3) I can host my files with known peers. For example, I could send some of my chunks with my friend Bob or a known datacenter. 4) 1% of the nodes going down as the same time has two possibilities: a problem at the DNS or backbone level, in which case we can expect those chunks back when that recovers, or a coordinated attack. 4a) Using the psuedo-reputation and token system we can keep botnets from joining the network. They would have to pay even to be peers, and if they have poor uptime(it is a botnet), they won't earn anything or get any contracts. 5) The ultimate solution is smart contract based SLAs. We can cover as many technical ways of doing, but incentives are the best way. Lose all the chunks and the user gets a $10k check. Creates huge financial disincentives for an attacker. Cover it well enough? Let me know if you have any questions.

Well all files are redundantly stored in small chunks around the network. We do realtime auditing of all those chunks, and recover any ones that drop. If you have a MegaUpload like incident, or a major datacenter/switch failure your files are bye bye. But on this network the files could be hosted at hundreds of different places. Traditional SLAs are pretty empty. They just say oops we have no liability. But with smart contacts being built we could do some cool stuff. At the protocol level if X hoster lost a portion of your file he would have to pay you $100, and the protocol would pay that out. We can create SLAs with actually financial teeth.

We do not use network consensus because it opens you Sybil attacks. Our code is available on Github, free and open source. FileCoin seems to YC backed, and taking a more closed approach.

We only want cryptocurrency nerds at this point as we slowly scale out the system. That is a purposeful barrier to entry. We will lower it as we scale out the system. Well its just a scale issue, you can't put a hash in the Bitcoin blockchain. Due to tx fees this is prohibitively expensive. Florincoin was a good temporary solution to get it working for one of our sample applications. This worked great as a proof of concept, but we need to support more than 7 Transactions per second(TPS). The Factom system we plan on using is quite simple. Give me a few beers, and a could probably program the base concept in a weekend. Take your metadata, hash them up into a merkle tree, add the merkle root in OP_RETURN of a bitcoin transaction.

We are going to be using the cryptocurrency as a pseudo-reputation system(writing a paper on this), and a software license. At this point we don't want everyone and their uncle trying to join the network. The cryptocurrency serves as a barrier for now. We get the right type of crypto nerds to get early access to the software, and give us good data and feedback. Based on demand we will lower the barrier of of entry. I understand the hesitance, but I'd wait till I produce another paper on that. I've written two on the system itself so far, and I can only write so fast.

This kind of attack is covered in the whitepaper: http://storj.io/storj.pdf

Well we have incentive for bandwidth as well, and we will have some controls in the applications as well to limit bandwidth. If you are accepting data contracts that are more backup related, you just have the initial download, then the user might not ever access that data again. In that case, we can work with very low bandwidth easily. I'm currently writing a whitepaper on the incentives and token system. Basically you have to buy a "software license" of sorts to participate in the network, and establish reputation by hosting shards of files well. This is unlike Bitcoin where compute power has a direct correlation to earning potential. The bot master would have to spend a small fortune on licenses for that many nodes, and I assume botnet nodes are not the most stable in terms of uptime. This is a great edge case though, and I'll write it into my paper.

We don't implement a cost per GB, although someone at the application level is free to do that. Space sellers are able to set their own pricing and they can factor in costs like drive wear and bandwidth costs. You have the buyer on the other hand who is trying to find the most reputable peer, with good uptime, at the lowest cost. Amazon S3 uses a homogeneous architecture and hardware, while our network is quite heterogeneous so it make sense for buyers and sellers to set their own prices to factor in the many variables.

1) You are not storing whole files but rather encrypted shards of files. We have another methodologies, to prevent against this. If you are really paranoid about it then you can be selective on what chunks you choose to host, but you won't make much. 2) Bandwidth is rewarded as well. Those with high bandwidth low storage would tend toward CDN applications. Those with high storage low bandwidth would tend toward data backup applications.