libsecp256k1

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

BitcoinCryptographic librariesNormal

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 queue5AI 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 Falbesoner39153065

Hennadii Stepanov4560064

Tim Ruffing2260055

furszy1340087

josibake941066

Lőrinc1330077

kevkevinpal620064

John Moffett420069

copilot-swe-agent[bot]320074

Jonas Nick710053

merge-script210091

gzJx0DuTRHytnHe7P5RmMbPf3wKy2BztweVGXTf211078

Analysis record

Published AI watches

Last scanned 6 minutes ago

Informational 15 AI analysisMessage 41 · Thin

3 weeks, 1 day ago

BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: sending

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 36 AI analysisMessage 100 · Strong

1 month, 4 weeks ago

BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

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

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

3 months, 1 week ago

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 ↗

Moderate 62 AI analysisMessage 100 · Strong

5 months, 2 weeks ago

BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

ellswift: fix overflow flag handling in secp256k1_ellswift_xdh

Cryptographic secret-key validation bypassSilent modular reduction instead of rejection for out-of-range secretsInconsistency with documented/referenced ECDH overflow handling

307b49f1by gzJx0DuTRHytnHe7P5RmMbPf3wKy2BztweVGXTf+1−11 file

Vendor flagged security relevance

Open full analysis →Source commit ↗

Informational 19 AI analysisMessage 100 · Strong

6 months ago

BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

refactor: remove unnecessary `malloc` result casts

97b3c478by Sebastian Falbesoner+17−173 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 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 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

Security candidateellswift: fix overflow flag handling in secp256k1_ellswift_xdhby gzJx0DuTRHytnHe7P5RmMbPf3wKy2BztweVGXTf · 307b49f1 · Feb 16, 2026 · 1 fileMessage 100 · StrongModerate 62Details

Commit message · gzJx0DuTRHytnHe7P5RmMbPf3wKy2BztweVGXTf

ellswift: fix overflow flag handling in secp256k1_ellswift_xdh

The secp256k1_ellswift_xdh function uses overflow = secp256k1_scalar_is_zero(&s) which overwrites the overflow flag from the preceding secp256k1_scalar_set_b32 call. This means secret keys >= the curve order are silently accepted (reduced mod n) instead of being rejected.

The fix changes = to |=, matching the correct pattern already used in secp256k1_ecdh (main_impl.h, line 51).

The ECDH module's test suite explicitly tests overflow rejection (passes secp256k1_group_order_bytes as a key and checks the function returns 0). The ellswift test suite has no corresponding test, which is why this went undetected.

100/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✓ Names security-relevant behavior explicitly

Why it was queued

secret or key materialmemory safety

AI analysis · Moderate 62/100

This commit fixes a bug in the ElligatorSwift-based ECDH key exchange function. The function was supposed to reject secret keys that are invalid (zero or greater than or equal to the curve order), but due to a one-character bug it only checked for zero keys and silently accepted too-large keys by reducing them modulo the curve order. The fix makes it reject both invalid cases, matching the behavior of the regular ECDH function. There is no evidence this was exploited or that it caused real-world harm, but it is a genuine cryptographic correctness issue.

Security candidaterefactor: remove unnecessary `malloc` result castsby Sebastian Falbesoner · 97b3c478 · Feb 2, 2026 · 3 filesMessage 100 · StrongInformational 19Details

Commit message · Sebastian Falbesoner

refactor: remove unnecessary `malloc` result casts

It seems that there is no good reason to do this and it's even
considered bad practice, see e.g. https://stackoverflow.com/a/605858

This commit touches mostly test code, the only two functions used
in production are `secp256k1_context_{create,clone}`.

Instances were found manually via `$ git grep "malloc("`

100/100 · StrongMessage clarity

✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference

Why it was queued

memory safetycryptography-sensitive path

AI analysis · Informational 19/100

This commit is a straightforward code cleanup: it removes unnecessary type casts in front of memory allocation calls like malloc. In modern C, casting the result of malloc is not needed and is generally discouraged. The change does not alter program behavior, fix a bug, or address a security issue. It touches mostly test and benchmark code, with only two small changes in production functions that create or clone a cryptographic context.