CommitWatch RSS
BC
← All projectsBitcoin Core

libsecp256k1

High-assurance secp256k1 elliptic-curve library used throughout the Bitcoin ecosystem.

BitcoinCryptographic librariesNormal
Source repository ↗
Repository coverage

176 commits in the local evidence base

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.

48security candidates5second-pass queue30AI analyses
50commits · 30 days
69commits · 60 days
94commits · 180 days
176commits · 365 days
Backfill bands
Aug 5 → Feb 682 seen1 candidatesComplete
Feb 6 → Jun 625 seen2 candidatesComplete
Jun 6 → Jul 619 seen1 candidatesComplete
Jul 6 → Aug 548 seen1 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

67/100 average clarity
39Strong · 80–100
76Adequate · 60–79
58Thin · 40–59
3Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Sebastian Falbesoner391512065
Hennadii Stepanov4562064
Tim Ruffing2262055
furszy1342087
josibake944066
Lőrinc1333077
kevkevinpal620064
John Moffett421069
copilot-swe-agent[bot]322074
Jonas Nick710053
merge-script210091
gzJx0DuTRHytnHe7P5RmMbPf3wKy2BztweVGXTf211078
Analysis record

Published AI watches

Last scanned 22 minutes ago

Low 26 AI analysisMessage 83 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

sha256: cross-check caller supplied compression function

This commit strengthens the library's startup self-test for SHA-256 compression functions that users can plug in. It adds a more thorough 'smoke test' that compares the user-supplied function against the built-in one across many message le…

Defensive self-test hardening for pluggable cryptographic primitiveExpanded test coverage for multi-block, unaligned-input, and non-IV state casesStartup-time detection of faulty SHA-256 compression functions
c84ea465by furszy+154−14 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 58 · Thin
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

header: Add note on SHA256 override and aux functions

This commit only adds a documentation note to a public header file. It explains that certain auxiliary functions, when called directly by user code, will not use a user-installed SHA256 override callback because they do not receive a libra…

4147f8bdby Tim Ruffing+9−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 50 · Thin
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

ecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passed

This small change makes Bitcoin's cryptographic library treat two built-in functions (the default ECDSA nonce generator and the default ECDH hash function) as 'default' choices even when a caller explicitly passes them. The practical effec…

Behavioral alignment of default function pointers with context-aware hash implementationPotential misuse path where explicit default function pointer bypassed context hash functionNo explicit security claim, CVE, or vulnerability description in commit or references
ed091bc4by Tim Ruffing+2−22 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 71 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

Remove deprecated `secp256k1_context_no_precomp` pointer

This commit removes an old, renamed pointer called secp256k1_context_no_precomp from the secp256k1 cryptographic library. It had been marked as deprecated for over three years and was only an alias for the newer secp256k1_context_static. T…

Removal of a deprecated public API symbolNo change to cryptographic logic, memory handling, or context semanticsPotential downstream build breakage for consumers still using the deprecated alias
bf435856by Sebastian Falbesoner+1−84 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 71 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

Remove deprecated `secp256k1_schnorrsig_sign` alias

This commit removes an old, renamed function called secp256k1_schnorrsig_sign from the libsecp256k1 cryptographic library. It had been marked as deprecated for over three years and was simply an alias pointing to the newer secp256k1_schnor…

No security-relevant code change: only a deprecated alias and its test are removedNo memory safety, cryptographic, or input validation changesNo bug fix, vulnerability patch, or incident disclosure present in commit or references
e14756bdby Sebastian Falbesoner+4−194 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 78 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

recovery: check exhaustive API results

This commit tightens a test suite for the secp256k1 cryptographic library. It adds checks to ensure that recoverable signing and signature conversion succeed before using their outputs. It does not change the library's actual signing or ve…

defensive test-hardening onlyno change to cryptographic implementationno change to signature parsing, verification, or recovery logic
1d3f72d3by Lőrinc+3−31 file
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 83 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

ellswift: check test operation results

This commit fixes test code for the EllSwift module so that it actually checks whether encoding, decoding, and public-key loading operations succeed before using their outputs. Previously the tests silently ignored failure return values, w…

Missing return-value checks in cryptographic test codePotential silent test failures in EllSwift encode/decode roundtrip testsPotential silent test failures in public-key load operations
564afb0bby Lőrinc+10−102 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 86 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: API docs and internal comment followups

This commit only updates documentation comments and an example error message in the silent payments module. It does not change any executable code, cryptographic calculations, or security behavior. The changes clarify when the output-creat…

0fa38f3dby Sebastian Falbesoner+24−223 files
No security note in commit
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 73 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

nonce: terminate RFC6979 loop at UINT_MAX

This commit fixes an infinite-loop bug in the RFC6979 nonce generation code used for creating cryptographic signatures. If a caller asked for attempt number UINT_MAX (the maximum value of an unsigned integer), the old loop would generate t…

Infinite loop in cryptographic nonce generation when counter is UINT_MAXLoop index wraparound causing non-terminationRFC6979 nonce function behavior mismatch with public API contract
b1bc6f3eby Lőrinc+2−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 50 · Thin
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: drop "shuffle outputs" recommendation from API docs

This commit only changes documentation comments in a header file. It removes a recommendation that callers shuffle transaction outputs before scanning, and instead clarifies that outputs should be passed in their original transaction order…

cea6d114by Sebastian Falbesoner+2−31 file
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 78 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

tests: add constant time tests

This commit only adds new test code. It extends the project's constant-time test suite to also exercise the silent payments module, ensuring that secret key material is not accidentally leaked through timing side channels during those oper…

Adds constant-time (side-channel) test coverage for the silent payments moduleUses memory-secret marking macros (SECP256K1_CHECKMEM_UNDEFINE/DEFINE) to detect secret-dependent branchesNo functional or cryptographic code changes
936907b0by josibake+78−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 70 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: receiving

This commit adds new code for receiving BIP352 Silent Payments in the libsecp256k1 cryptography library. It introduces functions that let a wallet scan a Bitcoin transaction to find outputs sent to it and compute the secret tweaks needed t…

New feature code, not a security patchExtensive input validation and NULL checks addedSensitive scalars cleared after use (shared_secret, scan_key_scalar, t_k_scalar)
d72a7432by josibake+632−13 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 41 · Thin
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: sending

This commit adds a new feature to the secp256k1 cryptographic library: the sender-side logic for Bitcoin Silent Payments (BIP352). It lets a wallet create special one-time payment addresses for recipients without revealing which recipient …

New feature implementation for BIP352 Silent Payments sender sideExtensive input validation (ARG_CHECK) and test coverage for malformed keys and bad argumentsSensitive intermediate values (shared secrets, scalars) are explicitly cleared
b30ea3ebby josibake+719−14 files
No security note in commit
Open full analysis →Source commit ↗
Low 38 AI analysisMessage 73 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: respect per-group recipients protocol limit (K_max=2323)

This commit fixes the libsecp256k1 Silent Payments implementation so it respects the protocol-defined maximum of 2,323 recipients that share the same scan public key. Previously, the code had a TODO warning about unbounded scanning that co…

Unbounded loop bounded to protocol limit to prevent quadratic scanning costSender-side enforcement prevents creating outputs recipients may not findNew public constant documents protocol limit (BIP-352 K_max=2323)
1c1b2753by Sebastian Falbesoner+85−53 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 68 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: recipient label support

This commit adds new public API functions to the silentpayments module of libsecp256k1 to support recipient-side labels for BIP352 silent payments. It is a feature addition, not a security fix or vulnerability patch. There is no evidence i…

c83b6783by Sebastian Falbesoner+302−13 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 62 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

build: add skeleton for new silentpayments (BIP352) module

This commit is purely a build-system and header-file skeleton for a new Silent Payments (BIP352) module. It adds configuration options, dependency checks, and empty placeholder files, but contains no actual cryptographic code or implementa…

a93e696aby Sebastian Falbesoner+83−08 files
No security note in commit
Open full analysis →Source commit ↗
Informational 16 AI analysisMessage 63 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

include: Remove SECP256K1_GNUC_PREREQ macro

This commit removes an unused internal compiler-version-checking helper macro from the public header file. It is a cleanup change with no security implications. The commit message notes it is technically a breaking change for any external …

dba4d937by copilot-swe-agent[bot]+0−91 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 85 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

Use __GNUC__ instead of SECP256K1_GNUC_PREREQ

This commit is a routine cleanup of compiler feature checks in the secp256k1 cryptographic library. It replaces a custom version-check macro with a simpler check for whether the compiler is GCC (or claims to be GCC, like Clang). The change…

09870e9cby copilot-swe-agent[bot]+10−102 files
No security note in commit
Open full analysis →Source commit ↗
Low 36 AI analysisMessage 100 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

refactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)

This is a defensive code cleanup in a Bitcoin cryptography library. It introduces a helper function that wraps a common three-step pattern when multiplying by the generator point, ensuring that temporary sensitive Jacobian coordinate data …

New helper ensures intermediate Jacobian coordinates are always cleared after generator multiplicationCommit message states goal is to prevent accidental gej leaks of secret scalar informationRefactors existing call sites in ECDSA sign, Schnorr sign, pubkey creation, and blinding setup
a3296d5eby Sebastian Falbesoner+14−165 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 55 · Thin
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

doc: correct API docs for ECDSA signing out-params (s/array/signature object/)

This commit only fixes wording in the API documentation comments. It changes the description of a function output parameter from 'pointer to an array' to 'pointer to a signature object' in two header files. No actual code behavior changed,…

40a0d874by Sebastian Falbesoner+2−22 files
No security note in commit
Open full analysis →Source commit ↗
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidateMerge bitcoin-core/secp256k1#1897: tests: check results before using outputsby merge-script · 687155df · Aug 4, 2026 · 8 filesMessage 96 · StrongTriage 0Details
Commit message · merge-script

Merge bitcoin-core/secp256k1#1897: tests: check results before using outputs

a2ad68cd81787ba70b2caff0a57998ae8a5b4834 ec: check pubkey sort test results (Lőrinc)
93280c22917c018f4e99d76e4398e66405c887bd silentpayments: check test serialization (Lőrinc)
b8de1bc30f917c0ab9f05aeaeb494834e81513e2 musig: check infinity test setup (Lőrinc)
0618af81317307466e9968592880a54229885edc extrakeys: check test pubkey loads (Lőrinc)
1d3f72d3fa8e476cdc3344dbb5aebeaf7a6efe89 recovery: check exhaustive API results (Lőrinc)
564afb0b06e6124092fd6fa1239b1b397f742e41 ellswift: check test operation results (Lőrinc)
658c7edc24832592969ccbd1bdbc5c59e1ccc5d5 tests: check exhaustive ecmult success (Lőrinc)

Pull request description:

**Problem:** Several tests inspect outputs from deterministic operations without checking the result.
The later output comparisons usually still exercise behavior, but a failed setup call can leave an output that accidentally satisfies a later assertion.
In `pubnonce_summing_to_inf`, `secp256k1_musig_sum_pubnonces` initializes both sums to infinity before a pubnonce load can fail, so the test could pass without constructing a valid opposing-nonce pair.

**Fix:** Check the result of each deterministic operation before reading its output in the affected exhaustive, EllSwift, recovery, extrakeys, MuSig, silent-payments, and public-key sort tests.
Leave deliberately ignored results alone when the test permits either result or validates a mutated value rather than an auxiliary carry, overflow, or sign flag.

ACKs for top commit:
151henry151:
Tested ACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834
real-or-random:
utACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834
theStack:
ACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834

Tree-SHA512: 9955e9170c53d87cd851351234133660d5d4a26190bd9054b5bef75ed11c785a0168f92ca9ec634d9599da019dad473dc30e4f635eeef699abc39407a5e28c5c

96/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✓ Names security-relevant behavior explicitly
Why it was queued
memory safetydefensive validationmerge-commit duplicate discount
Security candidatesha256: cross-check caller supplied compression functionby furszy · c84ea465 · Aug 3, 2026 · 4 filesMessage 83 · StrongLow 26Details
Commit message · furszy

sha256: cross-check caller supplied compression function

The existing selftest hashes one 63 byte string against a known digest.
Which catches a compression function that is wrong everywhere, but not
one that is wrong on multi-block calls, unaligned input, or a state
that is not the IV.

This introduces secp256k1_sha256_smoke_test, which hashes messages
of various lengths and starting offsets with both the supplied function
and the built-in one, and fails if the digest differs.

The check runs once during startup, so a faulty compression function
is caught early rather than silently producing incorrect output later.

Measured locally, this takes 1.5ms, which should be negligible for
any application.

See the introduced test for a clear view of the bugs this catches.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive path
AI analysis · Low 26/100

This commit strengthens the library's startup self-test for SHA-256 compression functions that users can plug in. It adds a more thorough 'smoke test' that compares the user-supplied function against the built-in one across many message lengths and memory alignments. The goal is to catch buggy or incompatible custom SHA-256 code early, before it silently produces wrong hashes. It is a defensive hardening change, not a fix for an active security hole.

Security candidaterelease-process: Add signing of tarballby Tim Ruffing · fae22e77 · Jul 31, 2026 · 1 fileMessage 53 · ThinTriage 0Details
Commit message · Tim Ruffing

release-process: Add signing of tarball

Resolves #1175.

53/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
signing boundarydocumentation-only discount
Security candidateheader: Add note on SHA256 override and aux functionsby Tim Ruffing · 4147f8bd · Jul 29, 2026 · 1 fileMessage 58 · ThinInformational 15Details
Commit message · Tim Ruffing

header: Add note on SHA256 override and aux functions

Resolves one item in #1835.

58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit only adds a documentation note to a public header file. It explains that certain auxiliary functions, when called directly by user code, will not use a user-installed SHA256 override callback because they do not receive a library context object. There is no code change, no behavior change, and no security fix.

Security candidateecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passedby Tim Ruffing · ed091bc4 · Jul 29, 2026 · 2 filesMessage 50 · ThinLow 32Details
Commit message · Tim Ruffing

ecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passed

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Low 32/100

This small change makes Bitcoin's cryptographic library treat two built-in functions (the default ECDSA nonce generator and the default ECDH hash function) as 'default' choices even when a caller explicitly passes them. The practical effect is that these built-in functions now receive the library context's hash function, which matters when the library is compiled with a custom hash implementation. Without this fix, a caller passing the same built-in function by name could accidentally bypass the context's hash function and use a different code path. There is no direct evidence in the commit of an exploitable vulnerability; it looks like a consistency/correctness fix.

Security candidateRemove deprecated `secp256k1_context_no_precomp` pointerby Sebastian Falbesoner · bf435856 · Jul 29, 2026 · 4 filesMessage 71 · AdequateInformational 21Details
Commit message · Sebastian Falbesoner

Remove deprecated `secp256k1_context_no_precomp` pointer

This context pointer has been deprecated since the rename to `_context_static`
more than three and a half years ago (see PR #1126, commit 53796d2b24e813750feae73e85c0a6eee40dc391),
for the first official release 0.2.0. Removing it should be fine by now.

71/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 21/100

This commit removes an old, renamed pointer called secp256k1_context_no_precomp from the secp256k1 cryptographic library. It had been marked as deprecated for over three years and was only an alias for the newer secp256k1_context_static. The change is a routine API cleanup, not a security fix, but any external code still using the old name will fail to compile or link after updating.

Security candidateRemove deprecated `secp256k1_schnorrsig_sign` aliasby Sebastian Falbesoner · e14756bd · Jul 28, 2026 · 4 filesMessage 71 · AdequateInformational 19Details
Commit message · Sebastian Falbesoner

Remove deprecated `secp256k1_schnorrsig_sign` alias

This function has been deprecated since the rename to `_schnorrsig_sign32`
more than three and a half years ago (see PR #1089, commit 99e6568fc6),
before the first official release 0.2.0. Removing it should be fine by now.

71/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 19/100

This commit removes an old, renamed function called secp256k1_schnorrsig_sign from the libsecp256k1 cryptographic library. It had been marked as deprecated for over three years and was simply an alias pointing to the newer secp256k1_schnorrsig_sign32. Any software still using the old name will fail to compile or link after this change, but the actual signing behavior is unchanged. There is no security vulnerability introduced by this cleanup.

Security candidaterecovery: check exhaustive API resultsby Lőrinc · 1d3f72d3 · Jul 26, 2026 · 1 fileMessage 78 · AdequateInformational 17Details
Commit message · Lőrinc

recovery: check exhaustive API results

The exhaustive recovery tests decoded and verified signatures without requiring recoverable signing or conversion to succeed.
Check those documented success results before consuming the outputs, matching the ordinary exhaustive signing test.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Informational 17/100

This commit tightens a test suite for the secp256k1 cryptographic library. It adds checks to ensure that recoverable signing and signature conversion succeed before using their outputs. It does not change the library's actual signing or verification code, so it does not fix a live security bug in production software. It is a defensive improvement to testing.

Security candidateellswift: check test operation resultsby Lőrinc · 564afb0b · Jul 26, 2026 · 2 filesMessage 83 · StrongInformational 17Details
Commit message · Lőrinc

ellswift: check test operation results

The EllSwift tests inspected outputs without requiring encoding, decoding, or public-key loading to succeed.
They also discarded the field parser result despite relying on its no-overflow precondition.
Check each deterministic success result before inspecting its output.

83/100 · StrongMessage clarity
✓ 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
memory safety
AI analysis · Informational 17/100

This commit fixes test code for the EllSwift module so that it actually checks whether encoding, decoding, and public-key loading operations succeed before using their outputs. Previously the tests silently ignored failure return values, which could hide bugs during testing but does not change the production library behavior or introduce a direct vulnerability in running software.

Security candidatesilentpayments: API docs and internal comment followupsby Sebastian Falbesoner · 0fa38f3d · Jul 23, 2026 · 3 filesMessage 86 · StrongInformational 15Details
Commit message · Sebastian Falbesoner

silentpayments: API docs and internal comment followups

Addresses follow-up comments and Claude nits from #1765, see
- https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3629070333
- https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3628888249
- https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3629066762
- https://github.com/bitcoin-core/secp256k1/pull/1765#pullrequestreview-4754517850

Note that the "hash output is not a valid scalar" error mentioning in
the API docs for sending is dropped intentionally to reflect the
scanning API docs, where we don't mention this negligible case either.

Co-authored-by: Tim Ruffing <me@real-or-random.org>

86/100 · StrongMessage clarity
✓ 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
cryptography-sensitive path
AI analysis · Informational 15/100

This commit only updates documentation comments and an example error message in the silent payments module. It does not change any executable code, cryptographic calculations, or security behavior. The changes clarify when the output-creation function can fail and add internal explanatory notes for future maintainers.

Security candidatenonce: terminate RFC6979 loop at UINT_MAXby Lőrinc · b1bc6f3e · Jul 20, 2026 · 1 fileMessage 73 · AdequateLow 37Details
Commit message · Lőrinc

nonce: terminate RFC6979 loop at UINT_MAX

The public nonce callback accepts `UINT_MAX`, but `nonce_function_rfc6979_impl` never returns for that attempt.
Its `i <= counter` loop wraps after the final candidate and starts again.

Generate the candidate before checking whether it is the requested attempt.
This preserves the result for every `unsigned int` attempt, including `UINT_MAX`, and exits before the index can wrap.

Co-authored-by: Tim Ruffing <me@real-or-random.org>

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
cryptography-sensitive path
AI analysis · Low 37/100

This commit fixes an infinite-loop bug in the RFC6979 nonce generation code used for creating cryptographic signatures. If a caller asked for attempt number UINT_MAX (the maximum value of an unsigned integer), the old loop would generate that nonce but then keep going forever because the loop counter would wrap around to zero and never exceed the target. The fix generates the nonce first, then checks whether the requested attempt has been reached and exits. This is a reliability/correctness bug in a critical cryptographic path, though it requires a caller to deliberately request UINT_MAX to trigger.

Security candidatesilentpayments: drop "shuffle outputs" recommendation from API docsby Sebastian Falbesoner · cea6d114 · Jul 20, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Sebastian Falbesoner

silentpayments: drop "shuffle outputs" recommendation from API docs

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit only changes documentation comments in a header file. It removes a recommendation that callers shuffle transaction outputs before scanning, and instead clarifies that outputs should be passed in their original transaction order. There is no code change, no security fix, and no vulnerability being addressed.

Security candidatetests: add constant time testsby josibake · 936907b0 · Jul 14, 2026 · 1 fileMessage 78 · AdequateInformational 12Details
Commit message · josibake

tests: add constant time tests

Co-authored-by: Jonas Nick <2582071+jonasnick@users.noreply.github.com>
Co-authored-by: Sebastian Falbesoner <91535+thestack@users.noreply.github.com>

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
constant-time or timing behavior
AI analysis · Informational 12/100

This commit only adds new test code. It extends the project's constant-time test suite to also exercise the silent payments module, ensuring that secret key material is not accidentally leaked through timing side channels during those operations. There is no change to the actual cryptographic library code that users rely on.

Security candidatesilentpayments: respect per-group recipients protocol limit (K_max=2323)by Sebastian Falbesoner · 1c1b2753 · Jul 14, 2026 · 3 filesMessage 73 · AdequateLow 38Details
Commit message · Sebastian Falbesoner

silentpayments: respect per-group recipients protocol limit (K_max=2323)

This affects both the sending and scanning API functions:
* Sending fails if any group is exceeding the limit.
* Scanning doesn't look beyond the limit.

Also add a recommendation to the API docs to shuffle the
`tx_outputs` input array, which improves the worst-case by ~2x.

Co-authored-by: nymius <155548262+nymius@users.noreply.github.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
AI analysis · Low 38/100

This commit fixes the libsecp256k1 Silent Payments implementation so it respects the protocol-defined maximum of 2,323 recipients that share the same scan public key. Previously, the code had a TODO warning about unbounded scanning that could lead to quadratic runtime and possible missed outputs. Now, sending fails if any group exceeds the limit, and scanning stops at the limit. It also documents a recommendation to shuffle transaction outputs to improve worst-case performance.

Security candidatesilentpayments: receivingby josibake · d72a7432 · Jul 14, 2026 · 3 filesMessage 70 · AdequateInformational 15Details
Commit message · josibake

silentpayments: receiving

Add routine for scanning a transaction and returning the necessary
spending data for any found outputs. This function works with labels via
a lookup callback and requires access to the transaction outputs.
Requiring access to the transaction outputs is not suitable for light
clients, but light client support is enabled in a future release.

Add an opaque data type for passing around the prevout public key sum
and the input hash tweak (input_hash). This data is passed to the scanner
before the ECDH step as two separate elements so that the scanner can
multiply the scan_key * input_hash before doing ECDH.

Finally, add test coverage for the receiving API.

Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification! Too few words to establish purpose
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit adds new code for receiving BIP352 Silent Payments in the libsecp256k1 cryptography library. It introduces functions that let a wallet scan a Bitcoin transaction to find outputs sent to it and compute the secret tweaks needed to spend them later. The change is a feature addition with extensive tests; nothing in the commit message or diff indicates a security bug fix or vulnerability.

Security candidatesilentpayments: sendingby josibake · b30ea3eb · Jul 14, 2026 · 4 filesMessage 41 · ThinInformational 15Details
Commit message · josibake

silentpayments: sending

Add a routine for the entire sending flow which takes a set of private keys,
the smallest outpoint, and list of recipients and returns a list of
x-only public keys by performing the following steps:

1. Sum up the private keys
2. Calculate the input_hash
3. For each recipient group:
3a. Calculate a shared secret
3b. Create the requested number of outputs

This function assumes a single sender context in that it requires the
sender to have access to all of the private keys. In the future, this
API may be expanded to allow for a multiple senders or for a single
sender who does not have access to all private keys at any given time,
but for now these modes are considered out of scope / unsafe.

Internal to the library, add:

1. A function for creating shared secrets (i.e., a*B or b*A)
2. A function for generating the "SharedSecret" tagged hash
3. A function for creating a single output public key

Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>

41/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context! Too few words to establish purpose
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Informational 15/100

This commit adds a new feature to the secp256k1 cryptographic library: the sender-side logic for Bitcoin Silent Payments (BIP352). It lets a wallet create special one-time payment addresses for recipients without revealing which recipient is being paid on the blockchain. The change is a normal, well-documented feature addition with no indication of a security bug or vulnerability fix.

Security candidatebuild: add skeleton for new silentpayments (BIP352) moduleby Sebastian Falbesoner · a93e696a · Jul 14, 2026 · 8 filesMessage 62 · AdequateInformational 15Details
Commit message · Sebastian Falbesoner

build: add skeleton for new silentpayments (BIP352) module

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 purely a build-system and header-file skeleton for a new Silent Payments (BIP352) module. It adds configuration options, dependency checks, and empty placeholder files, but contains no actual cryptographic code or implementation. There is nothing here that could introduce a security vulnerability.

Security candidatesilentpayments: recipient label supportby Sebastian Falbesoner · c83b6783 · Jul 14, 2026 · 3 filesMessage 68 · AdequateInformational 15Details
Commit message · Sebastian Falbesoner

silentpayments: recipient label support

Add function for creating a label tweak. This requires a tagged hash
function for labels. This function is used by the receiver for creating
labels to be used for a) creating labeled addresses and b) to populate
a labels cache when scanning.

Add function for creating a labeled spend pubkey. This involves taking
a label tweak, turning it into a public key and adding it to the spend
public key. This function is used by the receiver to create a labeled
silent payment address.

Add tests for the label API.

Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit adds new public API functions to the silentpayments module of libsecp256k1 to support recipient-side labels for BIP352 silent payments. It is a feature addition, not a security fix or vulnerability patch. There is no evidence in the commit or supplied references of any security defect, exploit, or incident.

Security candidateUse __GNUC__ instead of SECP256K1_GNUC_PREREQby copilot-swe-agent[bot] · 09870e9c · Jun 17, 2026 · 2 filesMessage 85 · StrongInformational 15Details
Commit message · copilot-swe-agent[bot]

Use __GNUC__ instead of SECP256K1_GNUC_PREREQ

Replace all SECP256K1_GNUC_PREREQ version checks with plain
defined(__GNUC__) checks, since the macro was only used for ancient GCC
versions that are no longer worth supporting individually. Moreover, the
macro was misleading because Clang claims to be GCC 4.2 by default.

All GCC versions that we reasonably support have the features previously
gated behind these checks (__inline__, __builtin_expect, __restrict__,
__warn_unused_result__, __nonnull__, and the __builtin_ctz* family).

Co-authored-by: Tim Ruffing <me@real-or-random.org>

85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100

This commit is a routine cleanup of compiler feature checks in the secp256k1 cryptographic library. It replaces a custom version-check macro with a simpler check for whether the compiler is GCC (or claims to be GCC, like Clang). The change does not fix a security bug and does not introduce a clear vulnerability; it removes support for very old GCC versions that are no longer targeted.

Security candidateinclude: Remove SECP256K1_GNUC_PREREQ macroby copilot-swe-agent[bot] · dba4d937 · Jun 17, 2026 · 1 fileMessage 63 · AdequateInformational 16Details
Commit message · copilot-swe-agent[bot]

include: Remove SECP256K1_GNUC_PREREQ macro

The macro is no longer used anywhere in the codebase. This is
technically a breaking change, but it's not expected any user code
actually uses this macro.

Co-authored-by: Tim Ruffing <me@real-or-random.org>

63/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
cryptography-sensitive path
AI analysis · Informational 16/100

This commit removes an unused internal compiler-version-checking helper macro from the public header file. It is a cleanup change with no security implications. The commit message notes it is technically a breaking change for any external code that might have relied on this macro, but the authors do not expect such usage.

Security candidaterefactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)by Sebastian Falbesoner · a3296d5e · Jun 7, 2026 · 5 filesMessage 100 · StrongLow 36Details
Commit message · Sebastian Falbesoner

refactor: introduce `_ecmult_gen_ge` helper (preventing accidental gej leaks)

Scalar multiplication with the generator point frequently involves a
conversion to affine coordinates and clearing out the temporary Jacobian
group element object after to avoid leaking secret key material, i.e.
executing the following three steps:
- secp256k1_ecmult_gen(ctx, &rj, ...)
- secp256k1_ge_set_gej(&r, &rj)
- secp256k1_gej_clear(&rj)

This commit introduces a corresponding helper to deduplicate code
and mitigate the risk that last step is forgotten (which can easily
happen and is not detected by tests).

The idea came up during a conversation with furszy, see
https://github.com/bitcoin-core/secp256k1/pull/1765#issuecomment-4482838033

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
secret or key materialcryptography-sensitive path
AI analysis · Low 36/100

This is a defensive code cleanup in a Bitcoin cryptography library. It introduces a helper function that wraps a common three-step pattern when multiplying by the generator point, ensuring that temporary sensitive Jacobian coordinate data is always wiped from memory. The change reduces the chance that a future developer forgets to clear that temporary data, which could theoretically leak tiny fragments of secret key information through memory side channels. It does not fix a known active bug or reported vulnerability.

Security candidatedoc: correct API docs for ECDSA signing out-params (s/array/signature object/)by Sebastian Falbesoner · 40a0d874 · Apr 29, 2026 · 2 filesMessage 55 · ThinInformational 15Details
Commit message · Sebastian Falbesoner

doc: correct API docs for ECDSA signing out-params (s/array/signature object/)

55/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 15/100

This commit only fixes wording in the API documentation comments. It changes the description of a function output parameter from 'pointer to an array' to 'pointer to a signature object' in two header files. No actual code behavior changed, so there is no security impact.

Security candidatemusig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`by Sebastian Falbesoner · 8479eafa · Apr 28, 2026 · 1 fileMessage 73 · AdequateLow 34Details
Commit message · Sebastian Falbesoner

musig: always clear out secret key in `secp256k1_musig_nonce_gen_counter`

Even though `secp256k1_musig_nonce_gen_internal` can currently only fail
if the API is misused (invalid `keypair` or `keyagg_cache` parameters),
clear out the buffer holding secret key data as well in this case to
follow best practices.

The issue was found and reported by l0rinc using GPT 5.5 (Thanks!).

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key material
AI analysis · Low 34/100

This is a small defensive cleanup in Bitcoin Core's libsecp256k1 MuSig code. The function that generates a cryptographic nonce could, in rare error cases, leave a temporary copy of the user's secret key in memory instead of wiping it. The patch makes sure the secret key buffer is always cleared, even when the internal function fails. The actual failure path can only be reached if the API is misused (bad keypair or cache), so this is best-practice hardening rather than an active exploit.

Security candidateecdsa: VERIFY_CHECK result of _fe_set_b32_limitby Tim Ruffing · 43fca0ff · Mar 23, 2026 · 1 fileMessage 68 · AdequateTriage 15Details
Commit message · Tim Ruffing

ecdsa: VERIFY_CHECK result of _fe_set_b32_limit

This also avoids a spurious "-Wmaybe-uninitialized" warning emitted by
gcc 16 (snapshot) when compiling with -DDETERMINISTIC.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive path
Security candidateAdd API to override SHA256 compression at runtimeby furszy · 0753f8b9 · Mar 3, 2026 · 11 filesMessage 80 · StrongTriage 15Details
Commit message · furszy

Add API to override SHA256 compression at runtime

This introduces `secp256k1_context_set_sha256_compression()`,
which allows users to provide their own SHA256 block-compression
function at runtime.

This is useful in setups where the fastest implementation can only
be determined dynamically based on the available CPU features, and
rebuilding the library is not possible.

The callback is installed on the `secp256k1_context` and is then used
by all operations that compute SHA256 hashes. As part of the setup,
the library performs sanity checks to ensure that the supplied
function is equivalent to the default transform.

Passing NULL to the callback setter restores the built-in
implementation.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
cryptography-sensitive path