Hacker News new | ask | show | jobs
by _prometheus 4351 days ago
the proof-of-retrievability. see http://cseweb.ucsd.edu/~hovav/dist/verstore.pdf
2 comments

I'm at work and don't want to read either of the papers at the moment, but if A asks B to provide proof of having stored some bytes, could B proxy that request to C and replay the reply to A ?
FWIW, thats usually called 'delegation' or 'outsourcing'. Apparently it's intentionally not resistant to this (sounds like a pretty bad idea— IMO, but apparently intentional). See the IRC log I linked above.
As long as a node you control has the data and can retrieve the file, I don't think there's a problem. If you could proxy the "proof of retrieval" than you could surely proxy the retrieval itself. Pooling resources shouldn't break anything.
But you could make it look like several computers have copies of the data when there's really only one copy of the data. You would get credit/coins for multiple copies and reduce the redundancy of the files.
From what I read in the paper, it sounds like you _don't_ get paid for providing the data. You get paid for proving you have it when mining a block. Distributing your storage across multiples nodes would simply make it easier to "mine", but wouldn't get coins passively. That is, if I'm understanding the protocol correctly.
You're right that nodes get paid for proving. Though you do also get paid for providing pieces in Get transactions.

On outsourceability, Filecoin today makes no effort against it. But see Permacoin for a great (and compatible) solution.

I haven't RTFA or any of the papers but couldn't you perhaps add a different nonce to each copy of the file you want stored before encrypting?
FWIW: For the simpler case of two single entities there is a non-probabilistic (whole data needed for proof) proof-of-retrievability concept: https://www.researchgate.net/publication/4326385_Reliable_Ev... Disclaimer: I am one of the authors.