Jack Grigg

Also, looking at the code, we _already_ use `dbl-2009-l` for Pallas and Vesta doubling (and `dbl-2007-bl` for the general doubling code for the Iso points).

Reminded myself how https://eprint.iacr.org/2015/1060 works, and it uses homogeneous coordinates; we currently use Jacobian coordinates because of the tie-in with hash-to-curve. So I think using these addition formulas (which would...

Something I want to consider for this is how easy each of the approaches makes implementing "backends": specialisations for different targets for improved performance (e.g. AVX2).

`bls12_381` has an alloc-free hash-to-curve implementation (https://github.com/zkcrypto/bls12_381/tree/main/src/hash_to_curve). That one has been tracking the RFC draft, whereas the one in this repository is intentionally point-in-time (as we need consensus compatibility with...

I want to take the first commit from this branch but not (yet) the second. I don't really want to maintain a second macro-based field implementation (the other being the...

I've opened #49 for discussing code de-duplication approaches. In the meantime, I will open another PR with the first commit from this branch, so we can get it reviewed.

Per https://github.com/zcash/pasta_curves/pull/50#issuecomment-1276980492, the manual bitshift-based doubling does not appear to be more efficient than the `self.add(self)` doubling.

It's also worth noting that in NU5 we're adding the ability to authenticate CompactBlock data, and this new field won't be included in that. An adversary can't provide an invalid...

#367 had test vectors that include txids; these passed because the test conditional was backwards, and checking that the derived txid _didn't_ match the test vector. https://github.com/zcash/lightwalletd/blob/ab4c0fef70dcb195f131d3d794e0c9cec2972dba/parser/transaction_test.go#L88-L90

Reopening because this shouldn't have been closed by #393 (which only partially fixed the problem, the internal code still derives the wrong txid and needs fixing).