Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm surprised the whitepaper didn't cite PermaCoin [1], which addresses the same problem with proofs-of-retrievability and uses the BitCoin blockchain for storage. Would the authors like to comment on how their work differs?

[1] http://cs.umd.edu/~amiller/permacoin.pdf



We designed Permacoin with the goal of being rigorously secure. Our design addressed a bunch of problems that aren't (yet) addressed by filecoin.

- Erasure coding (over the whole dataset) guarantees that you can't just drop some of the filed and make them unrecoverable.

- Preprocessing the entire dataset to be full entropy guarantees that it isn't cheaper to store one portion of the dataset than another (for example a segment with just all zeroes).

- Outsource resistance: it would be a shame if someone just runs a cloud service to store the file, which would be more efficient than using local hard drives. Arguably this is already happening with Bitcoin cloud mining. Permacoin and the follow up work on nonoutsourceable puzzles address this.

Without these features, the concern is that selfish miners might find ways to earn more filecoins without actually providing the useful service. Incentives are correctly aligned only when there's no way to game or cheat the system.

Filecoin provides a richer interface (get and put for individual files) than Permacoin (which only guarantees recovery of the whole dataset at once). We would have supported this interface if we could figure out how to, while maintaining the same standard security properties! This is difficult (but hopefully possible) future work.

On the other hand:

- Maybe it will be a long time before practical ways to game filecoin catch on.

- if filecoin builds a community that values altruistic participation like Tor (and even Bitcoin to some degree) it will be useful anyway

- it could be possible to improve filecoin with features from Permacoin

- there's a lot to learn from the actual launch of a system like this with real users


Hey, yeah. I found out about permacoin (which is great!) after designing this construction. Turns out that permacoin and filecoin are really compatible, and complementary. amiller and I will be talking about it in the near future. (btw, permacoin's non-outsourceability is a great contribution! it should also be added to regular bitcoin)

And, to answer your question, I didn't cite permacoin here because I would have to address a whole range of things like how they overlap/differ/which one is good for what parts. Perhaps I should've, but I think it's best left to a future paper (hinted at in the discussion). Stay tuned! :)


I hope you can take more hints from permacoin. There is an important economical point in permacoin's whitepaper:

"The expected reward per unit of work is approximately constant, even for very small investments of computational effort. This prevents large participants from monopolizing the system and driving out ordinary participants."

Maybe I don't have a deep understanding how filecoin works, but as far as I know if you don't have the storage capacity which can even reach the current difficulty then you have an expected reward of 0. Maybe it's a non-issue and the difficulty will never reach let's say 10MB, but if it reaches 1TB then it will be really hard to hop in the mining business.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: