From socrates1024 at gmail.com Tue Nov 24 13:31:37 2015 From: socrates1024 at gmail.com (Andrew Miller) Date: Tue, 24 Nov 2015 08:31:37 -0500 Subject: [Lightning-dev] Better privacy with SNARKs In-Reply-To: <9123B138-FC5E-489D-8159-3945176B84CE@erisian.com.au> References: <20151120074415.GA24674@navy> <87y4dojcqc.fsf@rustcorp.com.au> <9123B138-FC5E-489D-8159-3945176B84CE@erisian.com.au> Message-ID: 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 wrote: > On 24 November 2015 1:30:19 pm AEST, Rusty Russell > wrote: > >Anthony Towns 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: