<div dir="ltr"><div><div>Even though it seems like SNARKs aren't strictly necessary for this application, it's awesome you tried that out!<br><br></div>So, there are a couple of things that seem off to me about those performance estimates. I don't know snarklib/snarkfront well so I'm not sure what would cause this.<br>But checking a single snark proof should take around 10 milliseconds rather than 500 milliseconds. And it should only require like a kilobyte of memory to verify, definitely not 150 MB.<br></div><div>Also when you say that the verification/proving key is 100MB, those are two very different keys! The verification key should be extremely small, in the kilobyte range.<br></div><div><br></div>When I have some time (hopefully later this week) I'll try to reproduce this experiment using libsnark and write back in this thread. Some students at UMD also have a tool for composing circuits that is (arguably) more user-friendly and complements libsnark, I'm really hoping they release those open source soon!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 12:45 AM, Anthony Towns <span dir="ltr"><<a href="mailto:aj@erisian.com.au" target="_blank">aj@erisian.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 November 2015 1:30:19 pm AEST, Rusty Russell <<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> wrote:<br>
>Anthony Towns <<a href="mailto:aj@erisian.com.au">aj@erisian.com.au</a>> writes:<br>
>> On Fri, Nov 20, 2015 at 12:05:46PM +1030, Rusty Russell wrote:<br>
>>> With the segregated witness proposal, introducing new opcodes is<br>
>easy,<br>
>>> so maybe someone would find a reason to prefer open-coding it like<br>
>this?<br>
>><br>
>> I don't follow how segregated witness makes new opcodes any easier?<br>
><br>
>I didn't either, and that's because it's slightly orthogonal.<br>
><br>
>The proposal I heard is that the first byte of SW script is a version<br>
>byte, and if you don't understand that version, the script succeeds.<br>
<br>
</span>Ah, I see - it doesn't make OP_CHECK*VERIFY any easier then, but adding ops that actually change the contents of the stack becomes a soft fork instead of a hard fork. Pretty neat. Don't think that's needed here though.<br>
<br>
Cheers,<br>
aj<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Sent from my phone.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</div></div></blockquote></div><br></div>