7040a2024795a7e3758c7ab604ab440652c9772f doc: fix sage code for deriving alternative generator H (Sebastian Falbesoner)
Pull request description:
The line calculating H (in particular, the expression `G.decode('hex')`) fails with the following error message on Sage 9.5:
```
AttributeError: 'str' object has no attribute 'decode'
```
Fix that by converting the hex-string to bytes using `bytes.fromhex`.
(Noticed while reviewing https://github.com/bitcoin/bitcoin/pull/30048 which picks this code snippet comment up.)
ACKs for top commit:
josibake:
ACK 7040a20247
real-or-random:
utACK 7040a2024795a7e3758c7ab604ab440652c9772f
Tree-SHA512: 0a44f399b103c2f5840056d163c1483a1d4f032bc0f8d3822507ac6da9d567f46e36caa79c7f5016aebcc8827b79e9aec7ebdb4f21c3c0242dc6875be140f289
The expression `G.decode('hex')` fails with the following error message
on Sage 9.5:
AttributeError: 'str' object has no attribute 'decode'
Fix that by converting the hex-string to bytes using `bytes.fromhex`.
3a9b1d46a31e8ca93a94752e08b514c06ebc2c0c New Experimental Module: Incremental Half-Aggregation for Schnorr Signatures (Benedikt)
Pull request description:
Revisited PR #130 by jonasnick.
I am happy to hear your thoughts.
**Summary of changes compared to #130:**
- Address comments from rustyrussell
- Use tagged hash
- Compute hashes with common prefix by copying midstate
- Allow Incremental Aggregation and make code consistent with the [draft spec](https://github.com/BlockstreamResearch/cross-input-aggregation/blob/master/half-aggregation.mediawiki)
ACKs for top commit:
real-or-random:
ACK 3a9b1d46a31e8ca93a94752e08b514c06ebc2c0c
Tree-SHA512: 27239033f8b28ecf87ea310b3dd5a19dbbe6fd07495db71ef7017f8f444ec25a12897087d1bea0a2e9c3df77d7f17c38b183d7fe768858da2180f26624add4aa
The previous implementation returns an off-curve point for the input t=0.
This rewrite addresses that issue by implicity returning the on-curve point
(d, sqrt(1 + b)), which is the point that the paper Indifferentiable Hashing
to Barreto–Naehrig Curves suggests returning in this case.
Note: At the moment it is cryptographically impossible for the input t to be 0.
42f8c5140227dbdd8ae7eaaecd914e705e1b12d0 cmake: Add `SECP256K1_LATE_CFLAGS` configure option (Hennadii Stepanov)
Pull request description:
This PR enables users to override compiler flags that have been set by the CMake-based build system, such as warning flags.
The Autotools-based build system has the same feature out-of-the-box.
See more details [here](https://github.com/bitcoin-core/secp256k1/issues/1235#issuecomment-1465330925).
Here are some examples of the new option usage:
```
cmake -S . -B build -DSECP256K1_LATE_CFLAGS="-Wno-extra -Wlong-long"
```
```
cmake -S . -B build -DSECP256K1_BUILD_EXAMPLES=ON -DSECP256K1_LATE_CFLAGS=-O1
cmake --build build
...
In function ‘secp256k1_ecmult_strauss_wnaf’,
inlined from ‘secp256k1_ecmult’ at /home/hebasto/git/secp256k1/src/ecmult_impl.h:353:5:
/home/hebasto/git/secp256k1/src/ecmult_impl.h:291:5: warning: ‘aux’ may be used uninitialized [-Wmaybe-uninitialized]
291 | secp256k1_ge_table_set_globalz(ECMULT_TABLE_SIZE(WINDOW_A) * no, state->pre_a, state->aux);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/hebasto/git/secp256k1/src/secp256k1.c:29:
/home/hebasto/git/secp256k1/src/ecmult_impl.h: In function ‘secp256k1_ecmult’:
/home/hebasto/git/secp256k1/src/group_impl.h:174:13: note: by argument 3 of type ‘const secp256k1_fe *’ to ‘secp256k1_ge_table_set_globalz’ declared here
174 | static void secp256k1_ge_table_set_globalz(size_t len, secp256k1_ge *a, const secp256k1_fe *zr) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/hebasto/git/secp256k1/src/secp256k1.c:30:
/home/hebasto/git/secp256k1/src/ecmult_impl.h:345:18: note: ‘aux’ declared here
345 | secp256k1_fe aux[ECMULT_TABLE_SIZE(WINDOW_A)];
| ^~~
...
```
Please note that in the last case providing `env CFLAGS=-O1` or `-DCMAKE_C_FLAGS=-O1` won't work.
ACKs for top commit:
real-or-random:
ACK 42f8c5140227dbdd8ae7eaaecd914e705e1b12d0
Tree-SHA512: 2b152e420a4a8ffd5f67857de03ae5ba9f2223e535ac01a867c1025e0619180d8255fdd1e5fb8279b290f0a1c96bcc874043ef968fcd99b1ff4e13041a91b1e1
e6822678ea05c431b4f43be9dfbde54e0f7f645b build: Error if required module explicitly off (Tim Ruffing)
89ec583ccf01d9201fdab6a6c1682e6c27224b16 build: Clean up handling of module dependencies (Tim Ruffing)
Pull request description:
This is a cleanup which makes it easier to add further modules with dependencies, e.g., in #1452. The diff looks larger than it is because I also reordered the modules and made the order consistent between CMake and autotools.
(We noticed that the current logic could be improved in https://github.com/BlockstreamResearch/secp256k1-zkp/pull/275.)
ACKs for top commit:
jonasnick:
ACK e6822678ea05c431b4f43be9dfbde54e0f7f645b
hebasto:
ACK e6822678ea05c431b4f43be9dfbde54e0f7f645b.
Tree-SHA512: 040e791e5b5b9b8845a39632633a45ca759391455910bdefba2b7b77c6340e65df6eda18199ae2ad65c30ee2fc6630471437aec143c26fe09ae4c11409a37622
This also makes the order in which module options are processed
consistent between CMake and autotools (the reverse order of the listing
printed to stdout).
ba5d72d62659f9305d2be30b2ac89ce9480a0e78 assumptions: Use new STATIC_ASSERT macro (Tim Ruffing)
e53c2d9ffc0b0096881e30e388c3fb040f35e05d Require that sizeof(secp256k1_ge_storage) == 64 (Tim Ruffing)
d0ba2abbff2dcd4ca355f648d61fc6520f929949 util: Add STATIC_ASSERT macro (Tim Ruffing)
Pull request description:
This gets rid of an untested code path. Resolves https://github.com/bitcoin-core/secp256k1/issues/1352.
This is a bit opinionated in the sense that it adds a static assertion where it's needed in `secp256k1_pubkey_save` and `secp256k1_pubkey_load`. I think this is justified in this case. It helps the reviewer verify that these functions are correct.
See individual commit messages.
ACKs for top commit:
sipa:
utACK ba5d72d62659f9305d2be30b2ac89ce9480a0e78
jonasnick:
ACK ba5d72d62659f9305d2be30b2ac89ce9480a0e78
Tree-SHA512: 2553c0610b62bcda6d4ef26eb26b5b2e07acf723bcd299691a2d02da57af22b8763f63c2d4adb17d30de8825b6157be6e4f0398147854fbabdf8b865fb0b5c88
da7bc1b803b14274bc1687514e5da6a3e1cd9765 include: in doc, remove article in front of "pointer" (Jonas Nick)
aa3dd5280b4a046c03bd344bfd7f1499199a1f3c include: make doc about ctx more consistent (Jonas Nick)
e3f690015a21d6404cdec30666f721001b493172 include: remove obvious "cannot be NULL" doc (Jonas Nick)
Pull request description:
ACKs for top commit:
sipa:
ACK da7bc1b803b14274bc1687514e5da6a3e1cd9765
real-or-random:
ACK da7bc1b803b14274bc1687514e5da6a3e1cd9765
Tree-SHA512: 809f312fa0cd1e9502ac79b8a1c502b87e6dfc2db8ad6bbd96d7ddbdaadad0c3b6110fa704b770c353cd34d5bf5547541cbb5f2779425d7419b584e721c854c2
This also splits the big "&&" expression into separate expressions. If
we ever see an assertion fail, the error message will tell it precisely
which one failed.
This gets rid of an untested code path. Resolves#1352.
secp256k1_ge_storage is a struct with two secp256k1_fe_storage fields.
The C standard allows the compiler to add padding between the fields and
at the end of the struct, but no sane compiler in the end would do this:
The only reason to add padding is to ensure alignment, but such padding
is never necessary between two fields of the same type.
Similarly, secp256k1_fe_storage is a struct with a single array of
uintXX_t. No padding is allowed between array elements. Again, C allows
the compiler to insert padding at the end of the struct, but there's no
absolute reason to do so in this case.
For the uintXX_t itself, this guaranteed to have no padding bits, i.e.,
it's guaranteed to have exactly XX bits.
So I claim that for any existing compiler in the real world,
sizeof(secp256k1_ge_storage) == 64.
e2eb3fae407f0a081a19baeb2ea22eb965fa9674 Make *key_cache const in musig_pubkey_get (Sanket Kanjalkar)
Pull request description:
ACKs for top commit:
jonasnick:
ACK e2eb3fae407f0a081a19baeb2ea22eb965fa9674
Tree-SHA512: 24d1375bd48440e805e82d8a7d371eebfa98f7ef2c7a60d86c720e8512b5fa5bb70499ea821f9cef81c73145a3569c243fa0ecb1c29d7c31c4515dafeba80e23
3dbfb48946b9d2a98acef23674617510cf1b3386 tests: restore scalar_mul test (Jonas Nick)
Pull request description:
Without this commit, the res[i][1] test vectors are unused. They were introduced to test the correctness of scalar_sqr(x) and scalar_mul(x, x). These tests were deleted as part of removing scalar_sqr in commit
[5437e7bdfbffddf69fdf7b4af7e997c78f5dafbf](5437e7bdfb (diff-c2d5f1f7616875ab71cd41b053cfb428696988ff89642b931a0963d50f34f7e8L2195)).
Discovered in https://github.com/bitcoin-core/secp256k1/discussions/1463 by Coding-Enthusiast (thanks!).
ACKs for top commit:
real-or-random:
utACK 3dbfb48946b9d2a98acef23674617510cf1b3386
Tree-SHA512: 914e08db3efaa1cef546a9730096e740478c422d41fedb2b71ec3a7ea962f81740a05dc7e7c1fb191088f6d38b5690479c7d0864ca8abf2b2e9c4334f03ca605
