This is about the point where my math and libsnark knowledge runs out :)

My usecase is specifically cryptocurrency related, so I'm mostly interested
in curves that are used by cryptocurrency signature algorithms. E.g.
secp256k1 (Bitcoin and its kids), ed25519 (Sia, Stellar, and a few others).
Jubjub is definitely on the list once sapling is closer to deployment.
After a bit of consideration, ed25519 would probably be the most
interesting at first.

On Wed, Jan 3, 2018 at 2:33 PM Sean Bowe <s...@z.cash> wrote:

> I believe those gadgets are specifically for curves where the scalar
> field is the base field of the curve you're working with, so they
> probably wouldn't be that useful for arbitrary fields. Most of the
> complexity here is the bignum arithmetic inside the circuit, though.
>
> > Is there any more clever way to do this than just providing splitting
> into bits to implement modular arithmetic in a different field?
>
> Not that I know of. I explored the feasibility of this kind of stuff
> in the past and concluded each point addition would be around the cost
> of a SHA256 invocation. You can minimize the number of additions using
> window tables. The best approach seemed to be giant window tables
> queried with merkle tree lookups using something like MiMC. The
> additions are most efficient when working with affine formulas
> (inversions can be witnessed as efficiently as multiplications). You
> may be able to get this down to 2^20 constraints for ~256-bit scalars,
> which might be around 10-20 second proving time.
>
> Sean
>
> On Wed, Jan 3, 2018 at 1:36 PM, Andrew Miller <soc1...@illinois.edu>
> wrote:
> > Suppose one did want to build a secp256k1 gadget. I notice that libsnark
> > already provides a general gadget for  weierstrass form elliptic curves,
> > parameterized by a field. So all we'd have to do is define the secp256k1
> > operations in the alt_bn128 or in bls12 fields. Is there any more clever
> way
> > to do this than just providing splitting into bits to implement modular
> > arithmetic in a different field?
> >
> > On Jan 3, 2018 2:11 PM, "Sean Bowe" <s...@z.cash> wrote:
> >>
> >> If any curve is acceptable, I would encourage Jubjub, which we'll be
> >> using for the next version of Zcash. In which case you will be able to
> >> leverage our Sapling crypto code once it is more mature over the next
> >> month or so. https://github.com/zcash-hackworks/sapling-crypto
> >>
> >> Sean
> >>
> >> On Wed, Jan 3, 2018 at 1:02 PM, James Prestwich via zapps-wg
> >> <zapps...@lists.z.cash.foundation> wrote:
> >> > I'd prefer sha256 or bitcoin-style hash160. I'm interested in a few
> >> > different curves, including secp256k1. Eventually for EdDSA keys as
> >> > well. Is
> >> > there a list of supported curve operations?
> >> >
> >> > On Wed, Jan 3, 2018 at 12:57 PM Andrew Miller <soc1...@illinois.edu>
> >> > wrote:
> >> >>
> >> >> Thank you so much for expressing your question in Camenisch-Stadler
> >> >> notation! That makes it very clear what you're going for.
> >> >>
> >> >> What hash function H do you have in mind, would SHA2 work? Also what
> >> >> group
> >> >> G do you have in mind, secp256k1?
> >> >>
> >> >> If so, I do not know of any existing implementation of secp256k1
> >> >> operations specifically in libsnark, so that would presumably be the
> >> >> biggest
> >> >> challenge.
> >> >>
> >> >>
> >> >> On Jan 3, 2018 1:47 PM, "James Prestwich via zapps-wg"
> >> >> <zapps...@lists.z.cash.foundation> wrote:
> >> >>
> >> >> I'd like to participate in the setup ceremony.
> >> >>
> >> >> I also have an app I'd like to build using a zk-proof of knowledge of
> >> >> an
> >> >> ECC private key. {(a) : A = a * G, B = H(a)}. Can anyone point me to
> >> >> good
> >> >> resources on getting started?
> >> >>
> >> >>
> >> >
>

Reply via email to