Andrew Miller [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-24 📝 Original message: Even though it seems like ...
📅 Original date posted:2015-11-24
📝 Original message:
Even though it seems like SNARKs aren't strictly necessary for this
application, it's awesome you tried that out!
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.
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.
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.
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!
On Tue, Nov 24, 2015 at 12:45 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On 24 November 2015 1:30:19 pm AEST, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> >Anthony Towns <aj at erisian.com.au> writes:
> >> On Fri, Nov 20, 2015 at 12:05:46PM +1030, Rusty Russell wrote:
> >>> With the segregated witness proposal, introducing new opcodes is
> >easy,
> >>> so maybe someone would find a reason to prefer open-coding it like
> >this?
> >>
> >> I don't follow how segregated witness makes new opcodes any easier?
> >
> >I didn't either, and that's because it's slightly orthogonal.
> >
> >The proposal I heard is that the first byte of SW script is a version
> >byte, and if you don't understand that version, the script succeeds.
>
> 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.
>
> Cheers,
> aj
>
>
> --
> Sent from my phone.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151124/35b6db51/attachment.html>;
📝 Original message:
Even though it seems like SNARKs aren't strictly necessary for this
application, it's awesome you tried that out!
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.
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.
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.
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!
On Tue, Nov 24, 2015 at 12:45 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On 24 November 2015 1:30:19 pm AEST, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> >Anthony Towns <aj at erisian.com.au> writes:
> >> On Fri, Nov 20, 2015 at 12:05:46PM +1030, Rusty Russell wrote:
> >>> With the segregated witness proposal, introducing new opcodes is
> >easy,
> >>> so maybe someone would find a reason to prefer open-coding it like
> >this?
> >>
> >> I don't follow how segregated witness makes new opcodes any easier?
> >
> >I didn't either, and that's because it's slightly orthogonal.
> >
> >The proposal I heard is that the first byte of SW script is a version
> >byte, and if you don't understand that version, the script succeeds.
>
> 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.
>
> Cheers,
> aj
>
>
> --
> Sent from my phone.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151124/35b6db51/attachment.html>;