Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This change only edits the project's automated continuous-integration (CI) configuration file. It turns on all optional cryptographic modules by default in CI and adds test runs that disable each module one at a time. There is no change to…
No source-code changesNo build-system logic changesCI-only workflow refactor
This commit is a code cleanup (refactor) that splits one internal public-key parsing helper into three clearly named versions. It does not change what keys the public API accepts or rejects, and it adds more tests. There is no security vul…
Refactor only: no change to accepted public-key formats or validation rulesPublic API behavior preserved: 33-byte compressed and 65-byte uncompressed/hybrid still acceptedInternal fixed-size callers now use size-specific parser, reducing risk of accidental hybrid acceptance in future code
This commit only adds new test code to check that a specific Schnorr signing function behaves in a constant-time manner under Valgrind. It does not change any production cryptographic code, so it cannot introduce or fix a security vulnerab…
Only test file src/ctime_tests.c changedNo production cryptographic code modifiedAdds constant-time (CHECKMEM/Valgrind) coverage for schnorrsig_sign_custom
This commit is a code-quality and defensive-programming change. It restructures internal elliptic-curve helper functions so that runtime consistency checks (VERIFY macros) wrap the real implementation and cannot be skipped by an early 'ret…
Defensive restructuring of assertion wrappersAdds missing VERIFY post-conditions on group element outputsNo functional cryptographic change
This commit only adds new test code to check that a specific function behaves correctly when given a buffer of exactly the right size. It does not change any production code, fix a bug, or introduce a vulnerability. It is a routine improve…
This commit only adds a new test case. It checks that a DER signature can be written into a buffer that is exactly the right size, and that writing into a buffer one byte too small fails correctly. There is no change to the actual library …
This commit only adds new test cases to the libsecp256k1 test suite. It does not change any production cryptographic code. The new tests check that the DER signature parser correctly handles an unusual but valid length-encoding format (the…
Adds test coverage for DER long-form length encoding acceptance and rejectionTargets secp256k1_der_read_len boundary conditionsNo changes to src/ecdsa_impl.h or any production parsing logic
This commit only adds new test cases to the project's test suite. It does not change any production parsing code. The tests verify that the existing DER signature parser correctly accepts valid long-form length encodings and rejects invali…
This commit is a straightforward code cleanup: it removes a small internal helper function named secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no securit…
This is a routine internal code cleanup: it moves helper functions that convert between group elements and byte strings from one internal file to another, and renames a couple of private-key tweak helpers from 'privkey' to 'seckey'. The pu…
This commit is a simple renaming of internal function names from 'privkey' to 'seckey' to match current project terminology. No behavior of the code changes, and there is no security fix or vulnerability introduced.
This is a small internal cleanup in Bitcoin Core's secp256k1 cryptography library. It replaces a manual secret-key validity check (overflow plus zero) with an existing helper function that does the same thing. The behavior is intended to b…
No security-relevant behavioral change is described or evidentRefactoring only: equivalent overflow-and-zero check via existing helperReturn value logic preserved with added parentheses for warning avoidance
This is a pure code cleanup change: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several internal files and moves the asterisk in pointer declarations for style consistency. No behavior, logic, or security properties o…
This commit fixes an integer overflow bug in the library's internal scratch-space memory allocator. If a caller requested a scratch space with a size near the maximum possible value, adding the allocator's own bookkeeping header could wrap…
This commit is a pure code cleanup: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several related files and moves the asterisk in pointer declarations from the left side to the right side (e.g., 'type* arg' to 'type *ar…
This commit fixes a low-level arithmetic overflow check in a special internal memory-pool helper called 'scratch space'. Because the scratch API is no longer exposed to users, the bug cannot be triggered by normal callers today. The change…
Integer overflow in size calculationPotential heap buffer under-allocationDefensive hardening of internal allocator helper
This commit fixes test-suite bugs, not the cryptographic library itself. Several test cases were using outputs from functions without first checking whether those functions succeeded. In rare cases a failed setup step could leave a value t…
Test-only hardeningMissing return-value checks in test codePotential false-positive test passes on setup failure
This commit is a straightforward code cleanup: it removes a tiny internal helper function called secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no securit…
This commit is a routine post-release bookkeeping change. It bumps the project's version number from 0.8.0 to 0.8.1, marks the current code as an unreleased development snapshot, and updates the changelog accordingly. There are no code, cr…
This commit is a routine post-release bookkeeping change. It bumps the project's version number from 0.8.0 to 0.8.1, marks the current code as an unreleased development snapshot, and updates the changelog accordingly. There are no code, cr…
Merge bitcoin-core/secp256k1#1934: Clear secret-dependent variables in `_ecmult_const_xonly`
9e65f6ac9b714b85bf03338ffb900a6aeebed800 Clear secret-dependent variables in `_ecmult_const_xonly` (Sebastian Falbesoner)
Pull request description:
While working on the refactoring PR #1933, I noticed that there is no `_gej` clearing of the point multiplication result in `_ecmult_const_xonly` (apparently this was missed back then when looking for instances in https://github.com/bitcoin-core/secp256k1/pull/1579#issuecomment-2405693607, likely because in this case there is no `_ge_set_gej` call involved).
Note that for `_ecmult_const` itself there is already a separate PR: https://github.com/bitcoin-core/secp256k1/pull/1885
ACKs for top commit: real-or-random: utACK 9e65f6ac9b714b85bf03338ffb900a6aeebed800
Enables all modules by default, and tests the disabling of each module separately (respecting the dependency chain). This simplifies the configuration of modules in CI and extends the test coverage.
The extended coverage is proven by exposing pre-existing issues fixed in #1837 and #1839.
ACKs for top commit: hebasto: re-ACK 63f7e222c9d78550f70365f2ac57d24158ad3447. theStack: Concept and code-review ACK 63f7e222c9d78550f70365f2ac57d24158ad3447
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
This change only edits the project's automated continuous-integration (CI) configuration file. It turns on all optional cryptographic modules by default in CI and adds test runs that disable each module one at a time. There is no change to the actual library source code, build scripts, or released binaries, so it cannot directly introduce a runtime security vulnerability or fix one in shipped code. It is a testing-infrastructure cleanup that also increases coverage of build configurations.
de02108c51ca052245c7ba154b02a890e6815fdb tests: cover compressed pubkey parsing/serialization in `_ec_pubkey_parse` test (Sebastian Falbesoner) 31b1b300e812038e5b52f534370f7bd0cae01a79 refactor: split `ge_parse` helper into explicit variants (Sebastian Falbesoner)
Pull request description:
This PR is a follow-up to #1915, see the suggestion https://github.com/bitcoin-core/secp256k1/pull/1915#pullrequestreview-4962713401.
Splits the `ge_parse` function into three explicit variants for parsing from: - compressed public keys (33-bytes, prefixes 0x02 or 0x03) - uncompressed public keys (65-bytes, prefix 0x04) - uncompressed and hybrid public keys (65-bytes, prefixes 0x04, 0x06 or 0x07)
The first two are the counter-parts for the existing serialization functions `ge_serialize{33,65}`. The latter one is only needed for legacy reasons and likely not needed in the future. Having it named explicitly helps to avoid accepting hybrid pubkeys unintentionally. `ge_parse65` is currently unused outside of tests, but one potential use-case would be the serialization of the prevouts_summary in the silentpayments light-client API PR #1912 (see commit https://github.com/bitcoin-core/secp256k1/pull/1912/changes/82b95fde6fe2c75ec940ade339013939b8ecc5ea), unless we want to define a custom serialization there (where we e.g. remove the constant prefix byte).
ACKs for top commit: fjahr: Code review ACK de02108c51ca052245c7ba154b02a890e6815fdb real-or-random: utACK de02108c51ca052245c7ba154b02a890e6815fdb
This commit is a code cleanup (refactor) that splits one internal public-key parsing helper into three clearly named versions. It does not change what keys the public API accepts or rejects, and it adds more tests. There is no security vulnerability being fixed here.
Merge bitcoin-core/secp256k1#1935: tests: generate scalars_near_split_bounds instead of hardcoding
014825f0a30f3968efe51bf782ac2d4662841a41 tests: generate scalars_near_split_bounds instead of hardcoding (anshikakalpana)
Pull request description:
tests: generate scalars_near_split_bounds instead of hardcoding
The hardcoded scalars_near_split_bounds array didn't match its documented formula (a*LAMBDA + (ORDER+b)/2) % ORDER. All 20 entries were off in the same 32-bit window, likely a transcription error. As a result the vectors only reached ~126-bit outputs through secp256k1_scalar_split_lambda instead of the intended ~127-128-bit boundary, so the case they exist to test was never exercised.
Generate the values at runtime from the formula via fill_scalars_near_split_bounds(), which writes into a caller-provided array rather than a file-scope static. It is called at each of the three sites that use the array, so the values can no longer drift from their formula.
Verified the generated values reach within 1-2 units of the true k1_bound/k2_bound from the split_lambda_verify proof, confirming theexisting a/b ranges are sufficient.
Fixes #1920.
ACKs for top commit: real-or-random: utACK 014825f0a30f3968efe51bf782ac2d4662841a41
tests: generate scalars_near_split_bounds instead of hardcoding
The hardcoded scalars_near_split_bounds array didn't match its documented formula (a*LAMBDA + (ORDER+b)/2) % ORDER. All 20 entries were off in the same 32-bit window, likely a transcription error. As a result the vectors only reached ~126-bit outputs through secp256k1_scalar_split_lambda instead of the intended ~127-128-bit boundary, so the case they exist to test was never exercised.
Generate the values at runtime from the formula via fill_scalars_near_split_bounds(), which writes into a caller-provided array rather than a file-scope static. It is called at each of the three sites that use the array, so the values can no longer drift from their formula.
Verified the generated values reach within 1-2 units of the true k1_bound/k2_bound from the split_lambda_verify proof, confirming the existing a/b ranges are sufficient.
Fixes #1920.
91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
`src/ctime_tests.c` covers `secp256k1_schnorrsig_sign32` and `secp256k1_schnorrsig_sign_custom` entry points under Valgrind/CHECKMEM.
`secp256k1_schnorrsig_sign_custom` accepts optional `extraparams`, including a custom nonce function, before calling the shared internal signer. Functional tests cover this API, but previously it was not exercised under the constant-time CHECKMEM harness.
This PR adds coverage for:
- `secp256k1_schnorrsig_sign_custom(..., NULL)` using the default nonce path with NULL extraparams. - The default BIP340 nonce function with non-NULL `extraparams.ndata`. - The custom nonce callback dispatch path via a distinct `nonce_function_custom` callback that delegates to `secp256k1_nonce_function_bip340`. - Secret key material and keypair state under CHECKMEM for these signing paths.
Message and auxiliary data are not treated as secret inputs in these tests.
### Coverage gap
The existing constant-time test suite exercised `secp256k1_schnorrsig_sign32`, but did not exercise the public `secp256k1_schnorrsig_sign_custom` entry point and its custom nonce callback dispatch path under CHECKMEM.
Local synthetic mutations were used during development to verify that the added coverage reaches these paths. These mutations are not included in this branch.
This is a test-coverage improvement. No production cryptographic code is modified, and this PR does not claim a production vulnerability in unmodified libsecp256k1.
### Change
- `src/ctime_tests.c` only - No production code changes - No new dependencies
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
explicit security languagesecret or key materialsigning boundaryconstant-time or timing behaviormerge-commit duplicate discount
AI analysis · Informational 15/100
This commit only adds new test code to check that a specific Schnorr signing function behaves in a constant-time manner under Valgrind. It does not change any production cryptographic code, so it cannot introduce or fix a security vulnerability in the library itself. It is a test-coverage improvement.
c36269ef95da99498b3b62736f09dc42ffe5d094 group/refactor: Use constant expression for readability (Tim Ruffing) 031dbae6591664cf321bd9b09dd12535a5087533 group: Export secp256k1_ge_set_ge(j)_zinv properly in group.h (Tim Ruffing) 4f3bd158d5edd69cc66f39f20c42c72c776fa2d4 group: Cover all input/output ge/gej/fe with VERIFY calls (Tim Ruffing) 0711443e6da39cc98660fbeef3f989935443caa6 group: Add missing FE_VERIFY checks on rzr outputs (Tim Ruffing) 1bd7492181aca5967bbc690a4b81560101b1408b group: Remove redundant SECP256K1_GEJ_VERIFY (Tim Ruffing) cddd125f72f6156b360edb760d4ae089c3ae7a0f group: Split functions into pre/post VERIFY and _impl (Tim Ruffing)
Pull request description:
This PR splits the functions in group_impl.h in a wrapper that only performs VERIFY and an `_impl` function that has the actual code. This ensures that the post VERIFY calls are not skipped in case of early returns.
Also, this PR adds VERIFY calls wherever they were missing (inside group_impl.h)
The new structure is similar to field_impl.h but a bit simpler because we don't need to deal with two different implementations. A real difference is that, in non-VERIFY mode, field_impl.h delegates via #defines (ensure there's no overhead due to a function call) and here I decided to delegate via function calls. It keeps the code a bit simpler to read (and maybe also simpler to parser for tools such as language servers). The _impl functions all have SECP256K1_INLINE. I think every sane compiler will inline the function calls in non-VERIFY mode (even without SECP256K1_INLINE) because the body of the wrapper is really just a single function call then with the same signature.
Follow-up PR can cover modifications of ges and fes outside the group and field modules, e.g., ecmult modifies ges/gejs directly. Maybe it will be good that it does this only through group functions but we'll need to see; in C++ this module could legitimately be considered a "friend" of group.
ACKs for top commit: theStack: ACK c36269ef95da99498b3b62736f09dc42ffe5d094
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarymerge-commit duplicate discount
AI analysis · Informational 14/100
This commit is a code-quality and defensive-programming change. It restructures internal elliptic-curve helper functions so that runtime consistency checks (VERIFY macros) wrap the real implementation and cannot be skipped by an early 'return' statement. It also adds a few missing checks. These VERIFY macros are debug/test-only assertions; they are disabled in production builds, so the change does not alter normal behavior and is not a security fix for a live vulnerability.
Merge bitcoin-core/secp256k1#1931: tests: cover rejection of invalid plain seckey alongside a valid one
05f92899846f098623b3f2d392b58b887699b4b8 tests: silentpayments: cover rejection of invalid plain seckey alongside a valid one (Bruno Garcia)
Pull request description:
The existing silentpayment sender tests only pass a single invalid plain seckey, which parses to a zero scalar and is therefore also rejected by the later zero-sum check. Add a test with a valid key followed by an invalid one so that the early return in the seckey loop itself is exercised.
It kills the following mutant, the only one remaining within 229 ones :) - https://secp256k1.space/src/modules/silentpayments/main_impl.h
```diff diff --git a/src/modules/silentpayments/main_impl.h b/src/modules/silentpayments/main_impl.h index 415f2d2..489ec91 100644 --- a/src/modules/silentpayments/main_impl.h +++ b/src/modules/silentpayments/main_impl.h @@ -237,7 +237,7 @@ int secp256k1_silentpayments_sender_create_outputs( for (i = 0; i < n_seckeys; i++) { ret = secp256k1_scalar_set_b32_seckey(&addend, seckeys[i]); secp256k1_declassify(ctx, &ret, sizeof(ret)); - if (!ret) { + if (1==0) { secp256k1_scalar_clear(&addend); secp256k1_scalar_clear(&seckey_sum_scalar); return 0; ```
ACKs for top commit: real-or-random: utACK 05f92899846f098623b3f2d392b58b887699b4b8
changelog: mention dropped NULL requirement for silentpayments key arrays
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-prioritytests: silentpayments: cover rejection of invalid plain seckey alongside a valid oneby Bruno Garcia · 05f92899 · Sep 7, 2026 · 1 fileMessage 95 · StrongTriage 0Details
Commit message · Bruno Garcia
tests: silentpayments: cover rejection of invalid plain seckey alongside a valid one
The existing sender tests only pass a single invalid plain seckey, which parses to a zero scalar and is therefore also rejected by the later zero-sum check. Add tests with a valid key and an invalid one so that the early return in the seckey loop itself is exercised. The invalid key is placed at both the first and the last index, so that skipping the check for either position would be caught.
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Merge bitcoin-core/secp256k1#1928: tests: add coverage for exact-size DER signature serialization
500ccb60f70550332adf6b6f894ce84659cd6831 tests: add coverage for exact-size DER signature serialization (Bruno Garcia)
Pull request description:
The existing tests only serialize into oversized buffers or one that is far too small, so the boundary case where the output buffer is exactly the required size was untested. Check that this succeeds with identical output, and that one byte less fails while reporting the required size.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarymerge-commit duplicate discount
AI analysis · Informational 15/100
This commit only adds new test code to check that a specific function behaves correctly when given a buffer of exactly the right size. It does not change any production code, fix a bug, or introduce a vulnerability. It is a routine improvement to the test suite.
Lower-prioritysilentpayments: drop "empty key arrays must be NULL" requirementby Sebastian Falbesoner · 89e3a706 · Sep 7, 2026 · 2 filesMessage 73 · AdequateTriage 0Details
Commit message · Sebastian Falbesoner
silentpayments: drop "empty key arrays must be NULL" requirement
Enforcing this doesn't have much value and is in the end just making things slightly more inconvenient for the API user, forcing them to use conditional constructs like `keys_size == 0 ? NULL : keys_ptrs` for the call-sites, so removing it seems reasonable.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Security candidatetests: add coverage for exact-size DER signature serializationby Bruno Garcia · 500ccb60 · Sep 3, 2026 · 1 fileMessage 88 · StrongInformational 13Details
Commit message · Bruno Garcia
tests: add coverage for exact-size DER signature serialization
The existing tests only serialize into oversized buffers or one that is far too small, so the boundary case where the output buffer is exactly the required size was untested. Check that this succeeds with identical output, and that one byte less fails while reporting the required size.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 13/100
This commit only adds a new test case. It checks that a DER signature can be written into a buffer that is exactly the right size, and that writing into a buffer one byte too small fails correctly. There is no change to the actual library code that handles signatures, so this does not fix or introduce a security issue by itself.
Security candidateMerge bitcoin-core/secp256k1#1924: tests: add coverage for the DER long form length encodingby merge-script · a9a61831 · Aug 30, 2026 · 1 fileMessage 96 · StrongInformational 19Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1924: tests: add coverage for the DER long form length encoding
ddb1dfa77038442dff86ba90e6d0a30adfddef17 tests: add coverage for the DER long form length encoding (Bruno Garcia)
Pull request description:
random_ber_signature only emits long form lengths in signatures it marks as certainly_not_der, so run_ecdsa_der_parse asserts that such inputs are rejected but never that a well-formed long form length is accepted. As a result, inverting any of the four conditions in secp256k1_der_read_len that govern the long form goes unnoticed by the test suite.
Add the accepting cases, together with the two rejecting ones that share their boundaries: a length below 128, which must use the short form, and length octets with a leading zero. Since DER permits the long form only for lengths of at least 128, which a signature with two in-range scalars never reaches, the R integers in the accepting cases necessarily overflow to zero; the test checks the parsed values so this stays pinned down.
I noticed this lack in the tests while working on mutation testing for the ecdsa impl. So these tests kill the following mutants: https://secp256k1.space/src/ecdsa_impl.h#863, https://secp256k1.space/src/ecdsa_impl.h#878 and https://secp256k1.space/src/ecdsa_impl.h#896
ACKs for top commit: real-or-random: utACK ddb1dfa77038442dff86ba90e6d0a30adfddef17 theStack: ACK ddb1dfa77038442dff86ba90e6d0a30adfddef17
This commit only adds new test cases to the libsecp256k1 test suite. It does not change any production cryptographic code. The new tests check that the DER signature parser correctly handles an unusual but valid length-encoding format (the 'long form'), and that it rejects certain invalid variants. It is a hardening of test coverage, not a fix for a known bug or vulnerability.
Security candidatetests: add coverage for the DER long form length encodingby Bruno Garcia · ddb1dfa7 · Aug 26, 2026 · 1 fileMessage 88 · StrongInformational 15Details
Commit message · Bruno Garcia
tests: add coverage for the DER long form length encoding
random_ber_signature only emits long form lengths in signatures it marks as certainly_not_der, so run_ecdsa_der_parse asserts that such inputs are rejected but never that a well-formed long form length is accepted. As a result, inverting any of the four conditions in secp256k1_der_read_len that govern the long form goes unnoticed by the test suite.
Add the accepting cases, together with the two rejecting ones that share their boundaries: a length below 128, which must use the short form, and length octets with a leading zero. Since DER permits the long form only for lengths of at least 128, which a signature with two in-range scalars never reaches, the R integers in the accepting cases are longer than 32 bytes and are therefore parsed as zero; the test checks the parsed values so this stays pinned down.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100
This commit only adds new test cases to the project's test suite. It does not change any production parsing code. The tests verify that the existing DER signature parser correctly accepts valid long-form length encodings and rejects invalid ones. There is no security vulnerability being fixed here.
Lower-priorityMerge bitcoin-core/secp256k1#1922: field: Check that argument of _fe_set_int() is a constantby merge-script · 1c8babcd · Aug 25, 2026 · 5 filesMessage 81 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1922: field: Check that argument of _fe_set_int() is a constant
f6d821db032d494daf3bcfe56c0b3e711c06973f field: Fix typo in comment (Tim Ruffing) 1ce0066e6035df1e590178b21e38107115d5f971 field: Check that argument of _fe_set_int() is a constant (Tim Ruffing)
Pull request description:
Solves part of https://github.com/bitcoin-core/secp256k1/issues/1001. Overlooked in https://github.com/bitcoin-core/secp256k1/pull/1345.
ACKs for top commit: theStack: ACK f6d821db032d494daf3bcfe56c0b3e711c06973f
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Security candidateMerge bitcoin-core/secp256k1#1908: refactor: replace `_get_hash_context` with direct `->hash_ctx` accessby merge-script · bae6b89a · Aug 24, 2026 · 16 filesMessage 96 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1908: refactor: replace `_get_hash_context` with direct `->hash_ctx` access
c8745f6b3ad88a8e2b0ee2953ed3cc099dc9e15c refactor: replace `_get_hash_context` with direct `->hash_ctx` access (Sebastian Falbesoner)
Pull request description:
See issue #1835: https://github.com/bitcoin-core/secp256k1/issues/1835#issue-4046371933.
ACKs for top commit: apoelstra: ACK c8745f6b3ad88a8e2b0ee2953ed3cc099dc9e15c; successfully ran local tests real-or-random: utACK c8745f6b3ad88a8e2b0ee2953ed3cc099dc9e15c
This commit is a straightforward code cleanup: it removes a small internal helper function named secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no security bug is fixed or introduced.
Lower-priorityMerge bitcoin-core/secp256k1#1878: field: correct `_fe_half` docs (output is not normalized, input requires magnitude <= 31)by merge-script · 3397f3cb · Aug 21, 2026 · 1 fileMessage 86 · StrongTriage 0Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1878: field: correct `_fe_half` docs (output is not normalized, input requires magnitude <= 31)
56e031a14828a3b0e9a0b3d3626ca48e76716d98 field: correct `_fe_half` docs (output is not normalized, input requires magnitude <= 31) (Sebastian Falbesoner)
Pull request description:
After reviewing #1877, I took a look at the other field module function docs w.r.t. their normalized/magnitude promises and found this mismatch: the `secp256k1_fe_half` docs state the output is normalized, but the impl sets r->normalized = 0 (it only halves the limbs, without a reduction):
This is a minimum-diff fix to match the implementation, with a similar "On output" structure as used for `_fe_add`: https://github.com/bitcoin-core/secp256k1/blob/bd0287d650c24dc41e0362675a9f6a49ee952def/src/field.h#L246
ACKs for top commit: real-or-random: ACK 56e031a14828a3b0e9a0b3d3626ca48e76716d98
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
merge-commit duplicate discount
Security candidateMerge bitcoin-core/secp256k1#1915: refactor: Move (de)ser helpers from musig and eckey to groupby merge-script · 86c7cbaf · Aug 19, 2026 · 10 filesMessage 98 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1915: refactor: Move (de)ser helpers from musig and eckey to group
bfd40bd0ce0e7cac4f6bb395ccfe90eaf625feb1 refactor: Rename privkey to seckey in eckey helpers (Fabian Jahr) d8ee6e6cf6706c00562a584715cb2b8c41df7cb2 refactor: Move parsing helpers from musig to group (Fabian Jahr) 2577fb1888c021752dc6edbfa6df3216daa9ccb1 refactor: Move pubkey parsing and serialization from eckey to group (Fabian Jahr)
Pull request description:
These two helpers, `secp256k1_musig_ge_serialize_ext` and `secp256k1_musig_ge_parse_ext`, aren't really musig-specific. They (de)serialize a group element that can also be the point at infinity. This moves them to `eckey` as `secp256k1_eckey_serialize_ext` and `secp256k1_eckey_parse_ext`. They can't move further down to group.h because they depend on other `eckey` functions internally. There should be no functional change here.
I stumbled upon this while working on #1754 where I would want to reuse these helpers in that module, so it is split out of that. But the change seems to make sense on its own as well, so I wouldn't consider this prep work alone.
ACKs for top commit: theStack: ACK bfd40bd0ce0e7cac4f6bb395ccfe90eaf625feb1 real-or-random: utACK bfd40bd0ce0e7cac4f6bb395ccfe90eaf625feb1
This is a routine internal code cleanup: it moves helper functions that convert between group elements and byte strings from one internal file to another, and renames a couple of private-key tweak helpers from 'privkey' to 'seckey'. The public behavior of the library is unchanged, and the commit message explicitly states there should be no functional change.
Security candidaterefactor: Rename privkey to seckey in eckey helpersby Fabian Jahr · bfd40bd0 · Aug 17, 2026 · 3 filesMessage 62 · AdequateInformational 15Details
Commit message · Fabian Jahr
refactor: Rename privkey to seckey in eckey helpers
62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit is a simple renaming of internal function names from 'privkey' to 'seckey' to match current project terminology. No behavior of the code changes, and there is no security fix or vulnerability introduced.
Merge bitcoin-core/secp256k1#1916: ecdh/ellswift: simplify seckey loading with `_scalar_set_b32_seckey`
c00dc8181054fb31a0149ce03ef8413300a3a8bf ecdh/ellswift: simplify seckey loading with `_scalar_set_b32_seckey` (Sebastian Falbesoner)
Pull request description:
Instead of checking for overflow and zero manually, use the existing `_scalar_set_b32_seckey` helper which does both and returns zero if either of these two conditions apply. This can be seen as a very late follow-up to PR #701, commit 3fec9826086aa45ebbac1ff6fc3bb7b25ca78b1d, where the helper has been introduced and applied to the functions `_ecdsa_sign`, `_pubkey_create` and `_seckey_verify`. The variable name `is_sec_valid` has been chosen as it is currently also used in [`secp256k1_ecdsa_sign_inner`](https://github.com/bitcoin-core/secp256k1/blob/439278a649d3099d62dde966a76dc04aaca7ccb3/src/secp256k1.c#L555).
Note that introducing parantheses around `!!ret` was necessary to avoid warnings in the following form: ``` /home/thestack/secp256k1_master/src/modules/ecdh/main_impl.h: In function ‘secp256k1_ecdh’: /home/thestack/secp256k1_master/src/modules/ecdh/main_impl.h:74:12: warning: suggest parentheses around operand of ‘!’ or change ‘&’ to ‘&&’ or ‘ !’ to ‘~’ [-Wparentheses] 74 | return !!ret & is_sec_valid; | ^~~~~ ```
ACKs for top commit: real-or-random: utACK c00dc8181054fb31a0149ce03ef8413300a3a8bf
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safetymerge-commit duplicate discount
AI analysis · Informational 18/100
This is a small internal cleanup in Bitcoin Core's secp256k1 cryptography library. It replaces a manual secret-key validity check (overflow plus zero) with an existing helper function that does the same thing. The behavior is intended to be identical; no security vulnerability is described or visible in the code change.
Security candidateMerge bitcoin-core/secp256k1#1911: refactor: rename `ctx` param to `ecmult_gen_ctx` where applicableby merge-script · 3d69f4ce · Aug 17, 2026 · 4 filesMessage 86 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1911: refactor: rename `ctx` param to `ecmult_gen_ctx` where applicable
81a5a7567d10b358e6e41ef6085adf2ab2abc879 refactor: rename `ctx` param to `ecmult_gen_ctx` where applicable (Sebastian Falbesoner)
Pull request description:
To be more consistent and avoid confusion with regular `secp256k1_context` instances, rename the `ctx` parameter to `ecmult_gen_ctx` in all functions that take `secp256k1_ecmult_gen_context` pointers (see discussion https://github.com/bitcoin-core/secp256k1/issues/1835#issuecomment-4057203336 ff.).
While at it, move the * in pointer declarations of the touched functions to the right side for consistency across the code base, see PR #1252.
ACKs for top commit: real-or-random: utACK 81a5a7567d10b358e6e41ef6085adf2ab2abc879
This is a pure code cleanup change: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several internal files and moves the asterisk in pointer declarations for style consistency. No behavior, logic, or security properties of the code are changed.
Lower-priorityrefactor: Move parsing helpers from musig to groupby Fabian Jahr · d8ee6e6c · Aug 16, 2026 · 3 filesMessage 77 · AdequateTriage 0Details
Commit message · Fabian Jahr
refactor: Move parsing helpers from musig to group
Also rename them to secp256k1_ge_serialize_ext33 and secp256k1_ge_parse_ext33 to make the 33-byte format explicit.
77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
