Pieter Wuille

@real-or-random Woah! No, that's news to me. Just skimmed the paper, and it seems it is using homogeneous coordinates, not Jacobian ones? That may require rewriting all of the group...

@peterdettman I'm sure I've had discussions about this, but I can't find it on the issue tracker. Yes, I think using the endomorphism may give another trade-off dimension to ecmult_gen....

https://github.com/sipa/secp256k1/commits/202112_combine_ecmult_gen (=master + #1058 + #1056 + #1033 + #1028 + incomplete addition formula): 12.3 us per schnorrsig (master is 17.9 us).

I just copied our vartime code, without the var parts. It's easy to plug in something else for testing.

Questions like that may become more complicated with #967 too (as it introduces a new field approach with very different add/mul/normalize tradeoffs, and an independent magnitude-like dimension).

> Can someone with access please kick travis to clear the spurious failure? Done.

It seems s390x doesn't really work; I think we need to disable it again unfortunately. See #794.

utACK 6e712dcdc71f08672d8f243174051a000c85268f Seems s390x is green again; let's hope it stays that way.

As it seems this should be adding a strict invariant that ge/gej objects always have sane coordinates, I added checks for that in VERIFY mode: https://github.com/sipa/secp256k1/commits/202009_pr791. There was one place...

Fixed. The ```c++ r[i].infinity = a[i].infinity; ``` line above can be removed now.