CommitWatch RSS
LDK
← All projectsLightning Dev Kit

rust-lightning

Composable Rust libraries for building Lightning wallets, nodes, and services.

BitcoinCryptographic librariesLightning NetworkNormal
Source repository ↗
Repository coverage

1672 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.

254security candidates228second-pass queue1527AI analyses
76commits · 30 days
183commits · 60 days
551commits · 180 days
1253commits · 365 days
Backfill bands
Aug 5 → Feb 6819 seen18 candidatesComplete
Feb 6 → Jun 6468 seen16 candidatesComplete
Jun 6 → Jul 6128 seen8 candidatesComplete
Jul 6 → Aug 561 seen3 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.

70/100 average clarity
478Strong · 80–100
837Adequate · 60–79
295Thin · 40–59
62Opaque · 0–39
3security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Elias Rohrer15315153667
Matt Corallo43754372574
Jeffrey Czyz19545182169
Wilmer Paulino15945155169
Leo Nash11613116162
Valentine Wallace14612139169
Vincenzo Palazzo11311183
Joost Jager16224162069
elnosh391333058
auto-pr-bot2578087
shaavan22622069
Carla Kirk-Cohen78366068
Analysis record

Published AI watches

Last scanned 56 minutes ago

Moderate 57 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Don't track refused monitor updates as pending' (#5030)

This patch fixes a bookkeeping bug in rust-lightning's ChainMonitor. When a channel monitor refuses an update (for example, because the channel is already force-closing), the code used to still record that update as 'pending completion.' B…

State inconsistency: pending monitor updates tracked for updates that will never completePotential denial of service / channel freeze: stale pending entry could block completion actionsLightning-specific risk: delayed or blocked PaymentClaimed event could affect fund recovery timing
47850384by Matt Corallo+44−132 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 55 AI analysisMessage 76 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Persistent `MonitorEvent`s' (#4491)

This commit makes on-chain 'MonitorEvent' notifications durable and replay-safe. Previously, if a node crashed after a ChannelMonitor persisted a block update but before the ChannelManager processed the resulting event, the event could be …

Durability/atomicity fix for async persistence: prevents lost MonitorEvents across crashesNew ack-based event lifecycle with random event IDsArchival gating on unacknowledged events to avoid losing preimage/timeout information
9a324e72by wpaulino+467−45912 files
No security note in commit
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Fix payment attribution edge cases and simplify claiming' (#5021)

This commit refactors how LDK nodes claim incoming Lightning payments. It replaces a separate 'claim with known custom TLVs' method with an options struct passed to the normal claim call, and fixes two edge cases in payment attribution dat…

API change: claim_funds now takes ClaimFundsOptions, consolidating TLV-known behavior into one pathFailure-packet length bound added to prevent oversized onion error messagesIncoming failure packet truncated at 32 KiB before processing
ee7c61c2by Matt Corallo+256−17322 files
No security note in commit
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'release utxos from failed splices' (#4973)

This change fixes a wallet bookkeeping problem in rust-lightning's built-in coin-selection wrappers. Previously, when a splice attempt failed or coin selection errored after picking UTXOs, those UTXOs stayed marked as 'reserved' in memory …

Resource exhaustion / denial-of-service via permanent in-memory UTXO reservationIncorrect state tracking in coin-selection wrapperNew API method required for correct lifecycle management (release_utxos)
7220a6fdby jkczyz+295−383 files
No security note in commit
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Restore `Wallet` UTXO locks when coin selection fails afterwards

This commit fixes a bug in the wallet's coin-selection code. When the wallet picked UTXOs to spend, it locked them immediately so they couldn't be reused. But if a later step—fetching the change address or the previous transaction—failed, …

Resource lock leak on error pathUTXO lock state inconsistency between selection and confirmationDenial-of-service/funds-unavailability risk from persistent UTXO locks
81afd9caby elnosh+146−331 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 66 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Don't track refused monitor updates as pending

This patch fixes a bookkeeping bug in rust-lightning's ChainMonitor. When a monitor update is rejected (for example, because the channel funding has already been spent), the code may persist the entire monitor instead of the individual upd…

State inconsistency: rejected monitor update tracked as pending-persist despite never being persisted individuallyDenial-of-service-like effect: completion actions blocked until restartForce-close risk: stalled forwarding channel can lead to HTLC timeout and force close
ada0cb7aby Valentine Wallace+44−132 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'tx-sync: Parallelize esplora status queries' (#4913)

This commit rewrites how a Lightning wallet talks to Esplora block-explorer servers so that many status checks happen in parallel instead of one at a time. It is a performance/refactoring change. There is no direct evidence in the commit t…

Concurrency/timing change in transaction confirmation logicNew inconsistency check preserved when a previously-confirmed tx is reported unconfirmedAdded defensive error path for missing pre-fetched block status
c303f515by Matt Corallo+140−371 file
No security note in commit
Open full analysis →Source commit ↗
Low 30 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Skip Electrum creator transaction downloads' (#4992)

This change stops the Electrum-based transaction sync client from downloading the very transaction that created an output it is watching. Previously, the client could request that transaction from Electrum, even though a transaction can ne…

Avoids unnecessary Electrum transaction.get requests for watched outputsReduces information disclosure to Electrum server about watched outpointsAdds regression test verifying request suppression
c36e50cbby Matt Corallo+142−02 files
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Use preferred sPK of watched txn in electrum, not rand ones' (#4867)

This change improves how the Lightning Dev Kit's Electrum and Esplora transaction-sync clients track watched Bitcoin transactions. Previously, the code ignored the script pubkey (the 'address' associated with a transaction) supplied when r…

Previously ignored `script_pubkey` argument in `register_tx` for transaction watchersElectrum script-history queries previously used an arbitrary transaction output, which could be OP_RETURN and therefore unindexed by some Electrum serversNew logic prefers caller-supplied script pubkey and falls back to non-OP_RETURN outputs
bfe5ca89by tnull+52−243 files
No security note in commit
Open full analysis →Source commit ↗
Low 33 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Serialize transient Event variants; move persist decision into ChannelManager' (#4791)

This commit changes how LDK stores pending event notifications. It adds serialization support for several event types that previously were not fully saved to disk, and introduces a helper method so the code can decide which events are wort…

Data-loss prevention: previously non-round-trippable event variants are now fully serialized, avoiding accidental event loss when users serialize Event queues themselvesState-consistency hardening: ChannelManager now explicitly skips events that describe non-surviving restart state, preventing replay of stale eventsDefensive assertion: debug builds assert that every persisted event round-trips to Some(event), catching serialization mismatches
a0d4632eby Matt Corallo+694−818 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Document that funding signing events can go stale' (#4960)

This commit only adds documentation comments to two source files. It explains that certain funding-signing events can become stale if the underlying negotiation fails, and that callers may see specific harmless errors as a result. No code …

26eecf2dby Matt Corallo+15−02 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 58 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add `Wallet::release_utxos` to free UTXOs from abandoned transactions

This commit fixes a design flaw in LDK's built-in wallet helper where coins selected for a splice-in (or other unclaimed funding) were permanently reserved in memory if the transaction was abandoned. Over repeated failed splices, all spend…

Denial-of-service via UTXO exhaustion from repeated failed splice negotiationsRisk of inability to broadcast fee-bumping/claim transactions due to lack of available UTXOsNew API surface (release_utxos) introduced to mitigate resource leak
52ab13fdby elnosh+148−43 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 100 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Drop the honggfuzz version pin from the CI fuzz job

This commit removes a fixed-version pin for the honggfuzz fuzzing tool in a continuous-integration script. The project now uses the current release of honggfuzz instead of an older pinned version. There is no change to the actual Lightning…

4a1635efby auto-pr-bot+1−51 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 86 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Run the CI fuzz job on the stable toolchain

This commit changes the Rust toolchain used in the continuous integration (CI) fuzzing job from a fixed older version (1.75) to the latest stable release. It is purely a build/test infrastructure change to fix a dependency compatibility is…

21c4ed2bby auto-pr-bot+3−32 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 91 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Expose the dummy-hop tail constructor publicly

This commit makes a previously internal helper function public so that outside developers can build dummy-hop tails for blinded payment paths without recreating the logic themselves. It is an API usability change, not a fix for a known sec…

No security-relevant behavior change in the diffAPI visibility broadened from crate-public to publicCLTV expiry overflow check already present and unchanged
c5443353by auto-pr-bot+14−71 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 54 AI analysisMessage 100 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fail commitment sig verification without counterparty params

This change adds a safety check in a Bitcoin Lightning Network library (LDK). Previously, if the software tried to verify a peer's commitment signature before it had learned the peer's channel parameters, it could crash with a panic. Now i…

Defensive check added on peer-driven code path to prevent panicMissing counterparty_parameters could previously cause panic during commitment transaction constructionChannel closure returned instead of panic
de7ecc2fby auto-pr-bot+24−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 100 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Clarify the commitment validation failure message

This commit only changes the wording of an error message sent to peers when a commitment transaction fails validation. It replaces the vague phrase 'Failed to validate our commitment' with the clearer 'Received commitment failed validation…

3284a006by auto-pr-bot+11−114 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 61 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Move holder commit sig checks to `InMemorySigner`' (#4885)

This commit moves the checks that validate a counterparty's signatures on the holder's commitment and HTLC transactions out of the general channel code and into the signer module (InMemorySigner). Previously, these signature checks were do…

Moved signature validation from channel state machine into signer moduleAdded new tests that corrupt signatures and verify rejectionChanged error message from 'Invalid commitment tx signature from peer' / 'Invalid funding_created signature from peer' to 'Failed to validate our commitment'
83f5ba55by Matt Corallo+626−31024 files
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 86 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Drop stale splice signature on disconnect' (#4954)

This change fixes a Lightning channel splicing bug: when two peers temporarily disconnect during a splice, any half-finished signature the other side already sent is now discarded. Before the fix, that stale signature could be reused after…

State-invalidation bug in multi-step protocol (splice negotiation)Stale cryptographic signature not cleared on disconnectPotential reuse of old commitment state after reconnect
c9a77251by Matt Corallo+22−12 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 58 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Drop stale splice signature on disconnect

This fix prevents a Lightning channel from being accidentally force-closed. During a splice (a way to resize a payment channel), one side's initial signature could be kept in memory after the peers disconnected. If the peers later reconnec…

State inconsistency: in-memory buffered message not cleared on disconnectDuplicate message processing after reconnectionForce-close consequence for active Lightning channel
71405b4bby Wilmer Paulino+22−12 files
Vendor flagged security relevance
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.

Lower-priorityDetect channel alternative funding transaction confirmationby Wilmer Paulino · ad99d9a9 · Aug 5, 2025 · 1 fileMessage 73 · AdequateModerate 51Details
Commit message · Wilmer Paulino

Detect channel alternative funding transaction confirmation

Whether it's a splice, or a dual-funded RBF, we need to know which
funding transaction out of all of the negotiated ones is currently
confirmed in case we need to broadcast the holder commitment.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Moderate 51/100

This commit adds tracking in the Lightning node's channel monitor so that when a renegotiated funding transaction (from a channel splice or a dual-funded RBF) gets confirmed on-chain, the node knows which funding transaction is the real one. Without this, the node might broadcast the wrong commitment transaction during a force-close, potentially losing funds or getting into an inconsistent state. It is a defensive correctness fix, not an obvious remote exploit.

Lower-priorityDetect and fail-back monitor-blocked un-forwarded HTLCs at closeby Matt Corallo · 7c394804 · Aug 5, 2025 · 2 filesMessage 73 · AdequateModerate 66Details
Commit message · Matt Corallo

Detect and fail-back monitor-blocked un-forwarded HTLCs at close

If we have pending HTLCs which we intended to forward, but which
were waiting on a `ChannelMonitorUpdate` to be forwarded when we
closed, they will neither be in the `ChannelMonitor` nor in the
`Channel` in a state which indicates they need to be failed (i.e.
in the holding cell). As a result, we previously did not fail such
HTLCs back immediately. Note that we cannot rely on the catch-all
fail-back-before-channel-closure logic either as it is done by the
`ChannelMonitor` that is unaware of these HTLCs.

Here we fix this by detecting the specific case - HTLCs which are
in `LocalSent` (i.e. the counterparty has not provided an RAA yet)
and we have a blocked `ChannelMonitorUpdate` containing a remote
commitment transaction update (which will always contain the HTLC).

In such a case, we can be confident the counterparty does not have
a commitment transaction containing the HTLC, and can fail it back
immediately.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Moderate 66/100

This commit fixes a bug in the Lightning Dev Kit where certain pending forwarded payments could get stuck and not be returned to the sender if a channel closed at exactly the wrong moment. Normally, stuck payments are automatically failed back, but a specific edge case involving a delayed channel-monitor update caused the software to lose track of them. The fix detects these stranded payments during channel closure and immediately fails them back so funds are not left in limbo.