17fa21733aae97bf671fede3ce528c7a3b2f5f14 ct: Be cautious and use volatile trick in more "conditional" paths (Tim Ruffing)
5fb336f9ce7d287015ada5d1d6be35d63469c9a4 ct: Use volatile trick in scalar_cond_negate (Tim Ruffing)
Pull request description:
ACKs for top commit:
sipa:
ACK 17fa21733aae97bf671fede3ce528c7a3b2f5f14
jonasnick:
ACK 17fa21733aae97bf671fede3ce528c7a3b2f5f14
Tree-SHA512: 4a0fbee7b1cce4f4647bff697c0e645d93aa8fb49777feef5eb1e1eadce2116bafdcc6175c066ee4fe4bf1340047311e2d7d2c48bb288867a837ecd6c8687121
712e7f8722eba5dec2bc6b37d75aadeb6f6e633b 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 712e7f8722eba5dec2bc6b37d75aadeb6f6e633b
real-or-random:
utACK 712e7f8722eba5dec2bc6b37d75aadeb6f6e633b
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).
97c63b90390b0b11a5d3530b03855ec9cc0de343 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 97c63b90390b0b11a5d3530b03855ec9cc0de343 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 97c63b90390b0b11a5d3530b03855ec9cc0de343
Tree-SHA512: 9598c133c6f4e488c74512089dabe0508529f20ca782be1c8fbeae9d7f132da9d570a061053acd3d245a9a187abf1f2581207441ce6aac8d0f8972cf357a349f
Infinity isn't currently needed here, but correctly handling it is a
little more safe against future changes.
Update docs for it to make it clear that it is not constant time in A
(the input point). It never was constant time in Q (and would be a little
complicated to make constant time in A).
If it was later made constant time in A, infinity support would be easy
to preserve, e.g. by running it on a dummy value and cmoving infinity into
the output.
bef448f9af248dba016883401de07b431f3e686e cmake: Fix library ABI versioning (Hennadii Stepanov)
Pull request description:
This change emulates Libtool to make sure Libtool and CMake agree on the ABI version.
To test, one needs to simulate a release with backward-compatible API changes, which means the following changes in `configure.ac` and `CMakeLists.txt`:
- incrementing of `*_LIB_VERSION_CURRENT`
- setting `*_LIB_VERSION_REVISION` to zero
- incrementing of `*_LIB_VERSION_AGE`
ACKs for top commit:
real-or-random:
ACK bef448f9af248dba016883401de07b431f3e686e diff looks good and I tested on Linux
Tree-SHA512: f7551fc7377ea50c8bc32d14108a034a1f91ebbb63d5fec562e5cc28416637834b9a4dcba3692df1780adcd1212ad4f238dc0219ab5add68bd88a5a458572ee5
An executable target in the `COMMAND` option will automatically be
replaced by the location of the executable created at build time.
This change fixes tests for Windows binaries using Wine.
71f746c057a66d5ae0dfdb5d439bc49592c0d16e cmake: Include `include` directory for subtree builds (Hennadii Stepanov)
5431b9decdbbdf30c5c5f2aed4b59662f5c681a2 cmake: Make `SECP256K1_INSTALL` default depend on `PROJECT_IS_TOP_LEVEL` (Hennadii Stepanov)
162608cc982538906e775d0c549aff2de5dee413 cmake: Emulate `PROJECT_IS_TOP_LEVEL` for CMake<3.21 (Hennadii Stepanov)
Pull request description:
This PR:
1. Emulates [`PROJECT_IS_TOP_LEVEL`](https://cmake.org/cmake/help/latest/variable/PROJECT_IS_TOP_LEVEL.html) variable for CMake versions where it is not available.
2. Makes the `SECP256K1_INSTALL` option dependent on `PROJECT_IS_TOP_LEVEL` (a [follow up](https://github.com/bitcoin-core/secp256k1/pull/1263#issuecomment-1516564300) of https://github.com/bitcoin-core/secp256k1/pull/1263).
3. Makes integration of this project as a subtree easier. A top project can `#include <secp256k1.h>` with no additional `target_include_directories()` commands. For example, see https://github.com/hebasto/secp256k1-CMake-example/tree/subtree.
ACKs for top commit:
theuni:
utACK 71f746c057a66d5ae0dfdb5d439bc49592c0d16e.
Tree-SHA512: 8ccdbcc94b26f36e772611ebaab0f2846debd6ad20f9e361be31a8d2128a14273acb692b0631026e12cc6cdef6d445dce0fd3beb4f71af47b46dfcf840a18879
