<p dir="ltr">This reminds me, I've joined this list to ask a question / make a suggestion and never got to it.</p>
<p dir="ltr">It's very easy for to generate, for large data file a list of challenges to prove knowledge of the file. For instance the hash of the file after encryption with a given key indicates knowledge of the for content. If a user retains a long precomputed list of challenge-response pairs (which uses only a tiny amount of storage), it can periodically check that a storage service indeed hosts the data, at a trivial bandwidth cost. The CPU cost for the host can be alleviated too, by considering a small, random subset of the data for each challenge.</p>

<p dir="ltr">In an pseudonymous hosting market for long term storage, it would be a simple way to keep participants honest.</p>
<p dir="ltr">Is there anything of the sort planned or available in Tahoe? </p>
<div class="gmail_quote">On Nov 7, 2013 11:39 AM, "Andrew Miller" <<a href="mailto:amiller@cs.ucf.edu">amiller@cs.ucf.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here's a possible Tesla Coils and Corpses discussion I'd like to have<br>
sometime a few weeks from now maybe:<br>
   SNARKs (Succinct Non-interactive Arguments of Knowledge) are a<br>
recent hot topic in modern cryptography. A generic SNARK scheme lets<br>
you can take an arbitrary computation (e.g., the routine that checks a<br>
signature and a merkle tree branch) and compile it to a *constant<br>
size* compressed representation, called the verification key. An<br>
untrusted server can execute the computation on behalf of the client,<br>
and produce a *constant size* proof that it was carried out correctly.<br>
<br>
  These techniques are currently considered "nearly practical", in the<br>
sense that there are some proof-of-concept implementations out there<br>
(that compile C code), they're undergoing very active optimization<br>
work, but they have pretty poor constant-factors and absolute<br>
performance.<br>
<br>
   Here are the top three projects:<br>
   - Pinocchio <a href="https://research.microsoft.com/en-us/projects/verifcomp/" target="_blank">https://research.microsoft.com/en-us/projects/verifcomp/</a><br>
(half open sourced)<br>
   - TinyRAM <a href="http://www.scipr-lab.org/tinyram" target="_blank">http://www.scipr-lab.org/tinyram</a> (currently vaporware)<br>
   - Pantry <a href="https://github.com/srinathtv/pantry/" target="_blank">https://github.com/srinathtv/pantry/</a> (fully open sourced)<br>
<br>
  These have potential applications to TahoeLAFS. You could<br>
potentially perform a check/repair, or issue updates to an MDMF file,<br>
without having to actually transfer or compute over an entire merkle<br>
tree branch.<br>
<br>
   So the discussion topic would be an overview of how these work, the<br>
available implementations, and feasibility estimates for possible<br>
Tahoe applications.<br>
<br>
<br>
<br>
(also, this topic is interesting to me also because I am planning to<br>
extend my authenticated-data-structure programming language to include<br>
SNARKs.)<br>
<br>
--<br>
Andrew Miller<br>
_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</blockquote></div>