In the field 5x52 asm for x86_64, stack variables are provided as outputs.
The existing inputs are all forcibly allocated to registers, so cannot
coincide, but mark them as early clobber anyway to make this clearer.
In the existing code, the compiler is allowed to allocate the RSI register
for outputs m0, m1, or m2, which are written to before the input in RSI is
read from. Fix this by marking them as early clobber.
Reported by ehoffman2 in https://github.com/bitcoin-core/secp256k1/issues/766
cd54ac7c1c schnorrsig: Improve docs of schnorrsig_sign_custom (Tim Ruffing)
28687b0312 schnorrsig: Add BIP340 varlen test vectors (Tim Ruffing)
97a98bed1e schnorrsig: Refactor test vector code to allow varlen messages (Tim Ruffing)
Pull request description:
ACKs for top commit:
sipa:
ACK cd54ac7c1c. I didn't verify the included test vectors match the BIP.
jonasnick:
ACK cd54ac7c1c
Tree-SHA512: 268140e239b703aaf79825de2263675a8c31bef999f013ea532b0cd7b80f2d600d78f3872209a93774ba4dbc0a046108e87d151fc4604882c5636876026a0816
17fa21733a ct: Be cautious and use volatile trick in more "conditional" paths (Tim Ruffing)
5fb336f9ce ct: Use volatile trick in scalar_cond_negate (Tim Ruffing)
Pull request description:
ACKs for top commit:
sipa:
ACK 17fa21733a
jonasnick:
ACK 17fa21733a
Tree-SHA512: 4a0fbee7b1cce4f4647bff697c0e645d93aa8fb49777feef5eb1e1eadce2116bafdcc6175c066ee4fe4bf1340047311e2d7d2c48bb288867a837ecd6c8687121
712e7f8722 Remove unused scratch space from API (Jonas Nick)
Pull request description:
Not sure if we want the typedef and `secp256k1_scratch_space_{create,destroy}` but if we don't keep them then this PR will be a rather large diff.
ACKs for top commit:
sipa:
ACK 712e7f8722
real-or-random:
utACK 712e7f8722
Tree-SHA512: b3a8feb0fe4639d5e48b708ccbf355bca5da658a291f63899086d2bbeb6d0ab33e3dcd55d8984ec7fa803f757b7d02e71bcb7e7eeecaab52ffc70ae85dce8c44
- secp256k1_scalar_cadd_bit
- secp256k1_modinvXX_normalize_YY
- secp256k1_modinvXX_divsteps_ZZ
- ECMULT_CONST_TABLE_GET_GE
Even though those code loations are not problematic right now
(with current compilers).
97c63b9039 Avoid normalize conditional on VERIFY (Pieter Wuille)
Pull request description:
In the old code, `secp256k1_gej_rescale` requires a normalized input in VERIFY mode, but not otherwise. Its requirements shouldn't depend on this mode being enabled or not.
ACKs for top commit:
real-or-random:
utACK 97c63b9039 I've also verified that the loop in secp256k1_ecmult_strauss_wnaf holds up the invariant that the magnitude of Z is 1, even with the normalization removed
jonasnick:
ACK 97c63b9039
Tree-SHA512: 9598c133c6f4e488c74512089dabe0508529f20ca782be1c8fbeae9d7f132da9d570a061053acd3d245a9a187abf1f2581207441ce6aac8d0f8972cf357a349f