Jeff Burdges

I've noticed ZCash's refactor aiming for some general `Group` trait, but our `Pixel::SignatureGroup` actually requires both projective and affine forms, and a `batch_normalization` method. It's not a curve however since...

It appears Pixel's versifier optimizations differ significantly from BLS, so maybe this fits less well than I initially thought.

Yes, decompression currently does a full multiplication by the group order. See: https://github.com/filecoin-project/pairing/blob/master/src/bls12_381/ec.rs#L146 and https://github.com/filecoin-project/pairing/blob/master/src/bls12_381/ec.rs#L964 It's slow on G1 and really slow on G2. Assuming your orientation is public keys...

We noticed a nicer trick: Initially set X_0 to be random and compute Z_0 = a X_0 + b X_0 for some random a,b with a+b=s. In signing, set X_{i+1}...

I've implemented this last idea in c8db373c2cb617491a95d27df345c1063c7fbcd8 because it's basically free. I'll leave this open since we might still consider more radical approaches..

Thomas Pornin cautions against viewing key splitting as an alternative to constant-time implementations. We expect librustzcash to eventually become constant-time, so I'm not eger to duplicate their efforts, but maybe...

There are many papers on roughly this topic for RSA, including some theoretical models, since people like the CRT optimization which causes big problems. It's hard to have satisfactory answers...

There is recent work on making the zcash libraries constant time in https://github.com/zkcrypto/bls12_381 so I'm inclined to wait for now. In any case, we're likely stuck with key splitting now...

Very cool! Yes, any multi-frame tx should becomes more user friendly using raptorq, although maybe keep an eye out for regressions at small numbers like two frames or whatever. We...

As an aside, we'll try to make some progress on https://github.com/w3f/schnorrkel/issues/11 soon-ish, which should be interesting for parity signer. Feel free to chat with me about it on Element.