db8750de46 sync-upstream: improve help text (Jonas Nick)
Pull request description:
ACKs for top commit:
real-or-random:
utACK db8750de46
Tree-SHA512: 06f28c5ebd74437c3c2ef5ae460bec66ff9f15c4bae3b76c74b1323e2ef24d8ec456b72d58df9d68a3d41fcd44d6dfbefe8115900ccb10b8f028a7b0952b6df1
Switch msg initialization from a string literal to a brace-enclosed
array to avoid -Wunterminated-string-initialization. Upstream removed
the trailing '!' from the message; this change retains it.
The previous code is correct and harmless to initialize an array with a
non-terminated character sequence using a string literal.
However, it requires exactly specifying the array size, which can be
cumbersome.
Also, GCC-15 may issue the -Wunterminated-string-initialization warning.
[1]
Fix both issues by using array initialization. This refactoring commit
does not change behavior.
[1] Example warning:
src/modules/schnorrsig/main_impl.h:48:46: error: initializer-string for array of 'unsigned char' is too long [-Werror=unterminated-string-initialization]
48 | static const unsigned char bip340_algo[13] = "BIP0340/nonce";
| ^~~~~~~~~~~~~~~
(cherry picked from commit fa67b6752d)
Conflicts:
src/testrand_impl.h (kept local name `secp256k1_testrand_seed`)
3a1c39625e rangeproof: add unit test for malleating single-value proofs (Andrew Poelstra)
Pull request description:
I was a bit confused reading `secp256k1_rangeproof_getheader_impl` because in the case of single-value proofs (`has_nz_range == 0`) some bits of the header are unconstrained. At first I thought this was a malleability vector. And I think I've had this same confusion in the past.
But in fact it is not a malleability vector because the whole header gets hashed into the proof.
Add a unit test to confirm this to reduce future confusion.
ACKs for top commit:
real-or-random:
utACK 3a1c39625e
Tree-SHA512: 9670cd04fcc0bb322d89c2c86ef863e13c29e4477dc6fecdda16b9a745e42a84f237a7ec387b3291f334e2a5c5806a8cc7cc00e40246ad5b36366be841195b4b
I was a bit confused reading `secp256k1_rangeproof_getheader_impl`
because in the case of single-value proofs (`has_nz_range == 0`) some
bits of the header are unconstrained. At first I thought this was a
malleability vector. And I think I've had this same confusion in the
past.
But in fact it is not a malleability vector because the whole header
gets hashed into the proof.
Add a unit test to confirm this to reduce future confusion.
Similar to speeding up serialization; in our parsing logic we did a
bunch of expensive stuff then expensively inverted it. Drop everything
except the essential checks and then memcpy.
`secp256k1_pedersen_commit_serialize` would call `_load` (which does a
sqrt to fully decompress the key, then a conditional negation based on
the flag), then check the Jacobian symbol of the resulting y-coordinate,
then re-serialize based on this.
Instead, don't do any of this stuff. Copy the flag directly out of the
internal representation and copy the x-coordinate directly out of the
internal representation.
Checked that none of the other _serialize methods in the modules do
this.
Fixes#293
7040a20247 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 7040a20247
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`.
f7f0184ba1 msan: notate more variable assignments from assembly code (Cory Fields)
a61339149f change inconsistent array param to pointer (Cory Fields)
Pull request description:
This was missed in 31ba404944 because older versions of clang did not complain about it. But clang-17, at least, does.
The array-as-a-param makes this annoying because `sizeof(l)` is not helpful. I'd be happy to change the size calculation if there are any better suggestions or strong preferences.
ACKs for top commit:
sipa:
utACK f7f0184ba1
real-or-random:
ACK f7f0184ba1 tests work fine with clang 17 and `./configure CFLAGS="-fsanitize=memory -fsanitize-memory-track-origins=2 -fno-omit-frame-pointer -g -O1 -fno-optimize-sibling-calls" CC=clang`
Tree-SHA512: 8ab22209ef322a10f500b123c82ae5e7141ae1da0e7a890cbf90bd7d2eb11f397db4ccfe15a1666f2f49228585cccbf5bec741effebd1e2c6012cb7ea1689675
a5e8ab2484 ci: Add sanitizer env variables to debug output (Tim Ruffing)
84a93de4d2 ci: Add workaround for ASLR bug in sanitizers (Tim Ruffing)
Pull request description:
Fixes#1506.
This also adds the sanitizer env variables to our debug output as suggested in the same issue.
ACKs for top commit:
sipa:
utACK a5e8ab2484
jonasnick:
ACK a5e8ab2484
Tree-SHA512: 5162d14eeec01e088c600ed77e21c5ffd4dec23327b7e81b5ecac59b7c535cac97cd7b7b744c767766036dfc6d9152a9933eb326cf4065d56c46e2ee858da662
3a9b1d46a3 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 3a9b1d46a3
Tree-SHA512: 27239033f8b28ecf87ea310b3dd5a19dbbe6fd07495db71ef7017f8f444ec25a12897087d1bea0a2e9c3df77d7f17c38b183d7fe768858da2180f26624add4aa
"... neither can be equal to b." could suggest that the values are not
allowed to be identical, but what is meant here is that the mentioned
inputs shouldn't point to the same object.
Currently the `run_sqr` test doesn't do anything with the
result of the `fe_sqr` call. Improve that by checking that
the equation `(x+y)*(x-y) = x^2 - y^2` holds for some random
values y, as suggested in issue #1471 by real-or-random.
The existing loop for generating the x values is kept as-is.
31ba404944 msan: notate variable assignments from assembly code (Cory Fields)
e7ea32e30a msan: Add SECP256K1_CHECKMEM_MSAN_DEFINE which applies to memory sanitizer and not valgrind (Cory Fields)
Pull request description:
msan isn't smart enough to see that these are set without some help.
This was pointed out here: https://github.com/bitcoin-core/secp256k1/pull/1169#issuecomment-1370003449
With this commit, msan output is clean even with x86 asm turned on.
ACKs for top commit:
real-or-random:
utACK 31ba404944
hebasto:
re-ACK 31ba404944.
Tree-SHA512: c9c51fe542247e1e0a93f6d0063d119cf777ca8c1b7e9c8e45e168a2020dc503872eb2a78004725de81267a3ce78c923be1f8546fb92a3e95fc7ef034e5ba932
`check_fe_equal` is a wrapper around `secp256k1_fe_equal` that takes
care of normalization. Since it doesn't check anything itself, the
CHECK macro is needed at the call-sites to actually ensure equality.
