
<div dir="ltr"><div>If I'm reading this right, if someone is trying to crack the system, it might allow you to quickly discard a lot of the malicious data and reduce the impact on performance and the cracker learns nothing about the system in the process--something they really need with bitcoin / altcoin. When you exchange hashes, a third party could in theory use that information to learn about the system, I think mainly hashes would benefit crackers with large amounts of resources at their disposal, so I'd say it really depends on the use case (who would want your data?) and the design goals of the system.</div>

<div><br></div><div><a href="http://stackoverflow.com/questions/6776050/how-long-to-brute-force-a-salted-sha-512-hash-salt-provided">http://stackoverflow.com/questions/6776050/how-long-to-brute-force-a-salted-sha-512-hash-salt-provided</a><br>

</div><div><br></div><div>"Zero-knowledge proofs introduced by Goldwasser, Micali and Racko [GMR89] are interactive</div><div>protocols that enable a prover to convince a verier about the truth of a statement without</div>

<div>leaking any information but the fact that the statement is true. Blum, Feldman and Micali</div><div>[BFM88] followed up by introducing non-interactive zero-knowledge (NIZK) proofs where the</div><div>prover outputs just one message called a proof, which convinces the verier of the truth of the</div>

<div>statement. The central properties of zero-knowledge proofs and non-interactive zero-knowledge</div><div>proofs are completeness, soundness and zero-knowledge."</div><div><br></div><div><div>"Completeness: If the statement is true, the prover should be able to convince the verier.</div>

<div>Soundness: A malicious prover should not be able to convince the verier if the statement is</div><div>false.</div><div>Zero-knowledge: A malicious verier learns nothing except that the statement is true"</div>

</div><div><br></div><div><a href="http://www0.cs.ucl.ac.uk/staff/J.Groth/PCPNIZK.pdf">http://www0.cs.ucl.ac.uk/staff/J.Groth/PCPNIZK.pdf</a><br></div><div><br></div><div>"Non-interactive zero-knowledge proofs are a variant of zero-knowledge proofs in which no interaction is necessary between prover and verifier. Blum, Feldman, and Micali [1] showed that a common reference string shared between the prover and the verifier is enough to achieve computational zero-knowledge without requiring interaction."</div>

<div><br></div><div><a href="http://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof">http://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof</a><br></div><div><br></div><div>A more simplified explanation and example:</div>

<div><br></div><div><a href="http://www.cse.scu.edu/~tschwarz/coen350/zkp.html">http://www.cse.scu.edu/~tschwarz/coen350/zkp.html</a><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 3:11 PM, Natanael <span dir="ltr"><<a href="mailto:natanael.l@gmail.com" target="_blank">natanael.l@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Resending since it bounced the last time. </p>

<p dir="ltr">> SCIPR is another one. <a href="http://www.scipr-lab.org/" target="_blank">http://www.scipr-lab.org/</a><br>

><br>

> If it became efficient it could be useful for mining in a Bitcoin fork (commonly called altcoins). Don't know what kind of computations you'd actually would want it to do, though. Most meaningful computations could easily be deprecated by better algorithms, forcing you to switch algorithms often. You also have the problem of achieving consensus for what to compute.<br>


><br>

> What exactly would it be used for in Tahoe-LAFS?<br>

><br>

> - Sent from my phone<br>

><br>

> Den 7 nov 2013 18:54 skrev "Steve Weis" <<a href="mailto:steveweis@gmail.com" target="_blank">steveweis@gmail.com</a>>:<br>

>><br>

>> Hi Andrew. You may be interested in contacting an early-phase startup called Tegos:<br>

>> <a href="http://www.tegostech.com/" target="_blank">http://www.tegostech.com/</a><br>

>><br>

>> They're in stealth mode and haven't posted any info online, but they are legitimate and relevant to this work.<br>

>><br>

>> On Thu, Nov 7, 2013 at 8:39 AM, Andrew Miller <<a href="mailto:amiller@cs.ucf.edu" target="_blank">amiller@cs.ucf.edu</a>> wrote:<br>

>>><br>

>>> 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>

>><br>

>> _______________________________________________<br>

>> cryptography mailing list<br>

>> <a href="mailto:cryptography@randombit.net" target="_blank">cryptography@randombit.net</a><br>

>> <a href="http://lists.randombit.net/mailman/listinfo/cryptography" target="_blank">http://lists.randombit.net/mailman/listinfo/cryptography</a><br>

>><br>

</p>

<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>

<br></blockquote></div><br></div>