CommitWatch RSS
Continuous public-repository analysis

Open source.
Not open secrets.

We watch what security-critical projects change—then translate the code into clear, independent intelligence anyone can understand.

Explore the watch feed ↓See how scoring works →
24Projects watched
17541Commits captured
17134AI analyses
88High-risk findings · 30d
The watch feed

Changes worth understanding

AI analysis is published as generated. Community notes appear after human validation.

17134 analyses
Highest risk·RSS
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 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 ↗
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 60 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: add examples/silentpayments.c

This commit adds a new example file (examples/silentpayments.c) showing how to use the Silent Payments feature in libsecp256k1. It is purely documentation and demonstration code, not a change to the cryptographic library itself. There is n…

f0fdd99dby josibake+481−04 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 68 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: add benchmarks for scanning

This commit only adds performance benchmark tests for the Silent Payments module. It does not change any cryptographic logic, network behavior, or wallet handling. There is no security issue here.

7ae555c5by josibake+268−204 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

silentpayments: optimize scanning by using batch inversion

This commit is a pure performance optimization for the silent payments scanning feature. It replaces many individual expensive math operations (modular inversions) with a batched version, making scanning roughly 2.5 times faster in the wor…

ca0136dcby Sebastian Falbesoner+46−231 file
No security note in commit
Open full analysis →Source commit ↗
High 71 AI analysisMessage 50 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Reject duplicate Orchard and Ironwood action rk values

This update fixes a flaw in how the Keystone hardware wallet checks Zcash private transaction proposals (PCZTs). If the same random verification key ('rk') appeared in two different spending actions—either two Orchard actions or one Orchar…

New validation rejects duplicate Orchard/Ironwood randomized validating keys (rk)Code comment explicitly describes signature replay risk across shielded actionsTests added for duplicate rk within Orchard and across Orchard/Ironwood
5fa1ad23by Adam Tucker+173−04 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Remove unreleased batch changelog entries

This commit only removes two unreleased changelog entries from a markdown file. No source code, firmware logic, or security behavior was changed. It is a documentation cleanup and has no security relevance on its own.

86652d1dby Adam Tucker+0−61 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 64 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Scope Zcash shielded signing to selected account

This commit fixes a bug in the Keystone 3 hardware wallet's Zcash shielded transaction signing. Previously, when a user reviewed and approved a transaction for one account, the device could accidentally authorize a spend from a different a…

Account-scoping enforcement added to shielded spend authorizationPrevents cross-account signing under same seedNew validation in PCZT check path before signing
3d14c7ddby Adam Tucker+166−296 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 46 AI analysisMessage 62 · Adequate
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix(zcash): compact migrations alongside split transactions

This commit changes how the Keystone hardware wallet summarizes Zcash batch transactions that include both ordinary payments and migration (Orchard-to-Ironwood) self-transfers. Previously, if a batch had more than one ordinary transaction …

Behavioral change in transaction review UI that could affect user understanding of batch contentsRemoval of ambiguity guard that previously forced full review for mixed batchesNo explicit security claim or CVE reference in commit or supplied materials
ead96096by Adam Tucker+47−321 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

reduce unnecessary module lint warnings in workflows

This commit only changes two GitHub workflow files to add a Java compiler option that suppresses a specific category of warning messages ('module' lint warnings). It does not modify application code, dependencies, build logic, or anything …

fb10ac3aby Craig Raw+4−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 60 · Adequate
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

add missing key for .module verification issue and remove debug step

This commit fixes a build-time trust issue and cleans up temporary debugging. It adds the missing cryptographic key for the OpenTelemetry library so Gradle can verify its downloaded files, and removes a one-off debug step that was used to …

Dependency verification metadata updated to trust a previously untrusted signing keyBuild pipeline debug instrumentation removed after incident investigationNo application code or cryptographic wallet logic changed
08b36abbby Craig Raw+1−362 files
No security note in commit
Open full analysis →Source commit ↗
01
Why commit watching?

Security should leave a paper trail.

A quiet fix may be responsible caution—or it may leave users unaware that their assets were ever at risk. CommitWatch preserves the evidence, adds context, and tracks whether vendors disclose, acknowledge, and learn.

Why we built this →