BC
← All projectsBitcoin Core

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 7 minutes ago

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
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
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
Moderate 62 AI analysisMessage 100 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

ellswift: fix overflow flag handling in secp256k1_ellswift_xdh

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 che…

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
Informational 19 AI analysisMessage 100 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

refactor: remove unnecessary `malloc` result casts

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 alt…

97b3c478by Sebastian Falbesoner+17−173 files
No security note in commit
Repository ledger

Explore captured commits

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

Lower-prioritytests: check exhaustive ecmult successby Lőrinc · 658c7edc · Jul 26, 2026 · 1 fileMessage 78 · AdequateTriage 0Details
Commit message · Lőrinc

tests: check exhaustive ecmult success

The exhaustive matrix compared the Jacobian output without requiring `secp256k1_ecmult_multi_var` to succeed.
Require success before consuming the result so a failure cannot satisfy an infinity case accidentally.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Lower-priorityAdd changelog entry for silentpayments moduleby Sebastian Falbesoner · d9ac2ee5 · Jul 23, 2026 · 1 fileMessage 45 · ThinTriage 0Details
Commit message · Sebastian Falbesoner

Add changelog entry for silentpayments module

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
Security candidatesilentpayments: API docs and internal comment followupsby Sebastian Falbesoner · 0fa38f3d · Jul 23, 2026 · 3 filesMessage 86 · StrongTriage 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
Security candidatenonce: terminate RFC6979 loop at UINT_MAXby Lőrinc · b1bc6f3e · Jul 20, 2026 · 1 fileMessage 73 · AdequateTriage 15Details
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
Lower-priorityextrakeys: check invariant that x-only pubkeys have even Yby Sebastian Falbesoner · 89a54b5a · Jul 20, 2026 · 1 fileMessage 50 · ThinTriage 0Details
Commit message · Sebastian Falbesoner

extrakeys: check invariant that x-only pubkeys have even Y

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Security candidatesilentpayments: drop "shuffle outputs" recommendation from API docsby Sebastian Falbesoner · cea6d114 · Jul 20, 2026 · 1 fileMessage 50 · ThinTriage 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
Lower-prioritysilentpayments: flush labels before direct matchby Lőrinc · 1ae90bde · Jul 19, 2026 · 2 filesMessage 78 · AdequateTriage 0Details
Commit message · Lőrinc

silentpayments: flush labels before direct match

A direct x-only match stops scanning before a partial batch of earlier label candidates is checked.
The batch-inversion optimization can therefore return a later unlabeled output and discard label metadata for the earlier output.

Check the pending batch before accepting the direct match.
This restores the scan order from before batching, where the first matching output wins.

The regression puts a labeled `k = 0` output before its unlabeled counterpart and requires scanning to return it with the label.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Lower-prioritysilentpayments: extract label batch checkerby Lőrinc · 84a02fa9 · Jul 19, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · Lőrinc

silentpayments: extract label batch checker

Move the existing label-batch conversion and lookup into a helper.
The helper preserves the lookup order and keeps each scan exit on the same batch path.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritysilentpayments: skip slow benchmarks for low iters count (<= 2)by Sebastian Falbesoner · 4aa16704 · Jul 14, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · Sebastian Falbesoner

silentpayments: skip slow benchmarks for low iters count (<= 2)

The worst-case scanning benchmarks and the common-case scanning
benchmarks with N>10 are relatively slow, leading to signifcantly
long run times of CI jobs. Avoid this by skipping these if the
iters count is <= 2 (CI jobs run with SECP256K1_BENCH_ITERS=2).
This is the same approach used in the ecmult benchmarks (bench_ecmult).

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritydocs: update READMEby josibake · 7e4b313c · Jul 14, 2026 · 1 fileMessage 40 · ThinTriage 0Details
Commit message · josibake

docs: update README

40/100 · ThinMessage clarity
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
documentation-only discount
Security candidatetests: add constant time testsby josibake · 936907b0 · Jul 14, 2026 · 1 fileMessage 78 · AdequateTriage 24Details
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
Lower-priorityci: enable silentpayments moduleby Sebastian Falbesoner · f27a2968 · Jul 14, 2026 · 2 filesMessage 47 · ThinTriage 0Details
Commit message · Sebastian Falbesoner

ci: enable silentpayments module

47/100 · ThinMessage clarity
✓ Descriptive subject✓ Uses a recognizable type or scope! No meaningful explanatory body
Lower-prioritytests: add sha256 tag testby josibake · 4f7a578d · Jul 14, 2026 · 1 fileMessage 70 · AdequateTriage 0Details
Commit message · josibake

tests: add sha256 tag test

Test midstate tags used in silent payments.

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Lower-prioritytests: add BIP-352 test vectorsby josibake · b608a9d9 · Jul 14, 2026 · 6 filesMessage 83 · StrongTriage 5Details
Commit message · josibake

tests: add BIP-352 test vectors

Add the BIP-352 test vectors. The vectors are generated with a Python script
that converts the .json file from the BIP to C code:

$ ./tools/tests_silentpayments_generate.py test_vectors.json > ./src/modules/silentpayments/vectors.h

Co-authored-by: Ron <4712150+macgyver13@users.noreply.github.com>
Co-authored-by: Sebastian Falbesoner <91535+thestack@users.noreply.github.com>
Co-authored-by: Tim Ruffing <1071625+real-or-random@users.noreply.github.com>

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
fuzzing or regression evidence
Security candidatebuild: add skeleton for new silentpayments (BIP352) moduleby Sebastian Falbesoner · a93e696a · Jul 14, 2026 · 8 filesMessage 62 · AdequateTriage 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
Security candidatesilentpayments: receivingby josibake · d72a7432 · Jul 14, 2026 · 3 filesMessage 70 · AdequateTriage 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
Security candidatesilentpayments: recipient label supportby Sebastian Falbesoner · c83b6783 · Jul 14, 2026 · 3 filesMessage 68 · AdequateTriage 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
Security candidatesilentpayments: respect per-group recipients protocol limit (K_max=2323)by Sebastian Falbesoner · 1c1b2753 · Jul 14, 2026 · 3 filesMessage 73 · AdequateTriage 15Details
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
Lower-prioritysilentpayments: optimize scanning by using batch inversionby Sebastian Falbesoner · ca0136dc · Jul 14, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · Sebastian Falbesoner

silentpayments: optimize scanning by using batch inversion

This improves the worst-case scanning scenario performance by ~2.5x
and also helps notably in the common case ("no match") scenario,
especially if the number of outputs is high.

Benchmark results on parent commit (without optimization):

Benchmark , Min(us) , Avg(us) , Max(us)

silentpayments_scan_nomatch_N=2 , 40.1 , 40.1 , 40.2
silentpayments_scan_nomatch_N=5 , 43.7 , 43.8 , 43.8
silentpayments_scan_nomatch_N=10 , 50.1 , 50.1 , 50.1
silentpayments_scan_nomatch_N=100 , 166.0 , 168.0 , 173.0
silentpayments_scan_nomatch_N=1000 , 1363.0 , 1368.0 , 1376.0
silentpayments_scan_nomatch_N=2323 , 3107.0 , 3113.0 , 3122.0
silentpayments_scan_nomatch_N=23250 , 30719.0 , 30764.0 , 30813.0
silentpayments_scan_worstcase_K=10 , 336371.0 , 336429.0 , 336492.0
silentpayments_scan_worstcase_K=100 , 3081573.0 , 3082413.0 , 3082899.0
silentpayments_scan_worstcase_K=1000 , 29909353.0 , 29931334.0 , 29951917.0
silentpayments_scan_worstcase_K=2323 , 67392236.0 , 67410087.0 , 67440159.0

Benchmark results on this commit (with optimization):

Benchmark , Min(us) , Avg(us) , Max(us)

silentpayments_scan_nomatch_N=2 , 39.3 , 39.3 , 39.4
silentpayments_scan_nomatch_N=5 , 40.5 , 40.5 , 40.6
silentpayments_scan_nomatch_N=10 , 43.5 , 43.5 , 43.5
silentpayments_scan_nomatch_N=100 , 90.0 , 92.7 , 100.0
silentpayments_scan_nomatch_N=1000 , 578.0 , 579.0 , 584.0
silentpayments_scan_nomatch_N=2323 , 1296.0 , 1300.0 , 1310.0
silentpayments_scan_nomatch_N=23250 , 12629.0 , 12649.0 , 12664.0
silentpayments_scan_worstcase_K=10 , 137746.0 , 137781.0 , 137813.0
silentpayments_scan_worstcase_K=100 , 1261417.0 , 1261614.0 , 1261774.0
silentpayments_scan_worstcase_K=1000 , 12245097.0 , 12249587.0 , 12258039.0
silentpayments_scan_worstcase_K=2323 , 27591765.0 , 27594324.0 , 27597324.0

(Benchmark machine: arm64 notebook, Snapdragon X Elite X1E-78-100)

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritysilentpayments: add benchmarks for scanningby josibake · 7ae555c5 · Jul 14, 2026 · 4 filesMessage 68 · AdequateTriage 0Details
Commit message · josibake

silentpayments: add benchmarks for scanning

Add a benchmark for a full transaction scan, both for the common
case and worst-case (full-block sized tx) scenarios.
Only benchmarks for scanning are added as this is the most
performance critical portion of the protocol.

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

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
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.

Lower-prioritysilentpayments: add examples/silentpayments.cby josibake · f0fdd99d · Jul 14, 2026 · 4 filesMessage 60 · AdequateTriage 0Details
Commit message · josibake

silentpayments: add examples/silentpayments.c

Demonstrate sending and scanning on full nodes.

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Lower-priorityfield: serialize elements by wordby Lőrinc · e217ead5 · Jul 13, 2026 · 2 filesMessage 78 · AdequateTriage 0Details
Commit message · Lőrinc

field: serialize elements by word

The byte assignments replaced nested nibble loops before the endian write helpers existed.
Pack the 5x52 limbs into four 64-bit words and the 10x26 limbs into eight 32-bit words, then use those helpers.
This matches the scalar serializers and keeps the output unchanged.
Benchmarks indicate no measurable performance regression.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Lower-prioritySECURITY.md: Align the tableby Tim Ruffing · d5c64baf · Jul 9, 2026 · 1 fileMessage 50 · ThinTriage 0Details
Commit message · Tim Ruffing

SECURITY.md: Align the table

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-prioritySECURITY.md: Add theStack's keyby Tim Ruffing · 9bd50f0c · Jul 9, 2026 · 1 fileMessage 50 · ThinTriage 0Details
Commit message · Tim Ruffing

SECURITY.md: Add theStack's key

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
documentation-only discount