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

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

225security candidates209second-pass queue1479AI analyses
64commits · 30 days
198commits · 60 days
656commits · 180 days
1472commits · 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.

69/100 average clarity
359Strong · 80–100
790Adequate · 60–79
288Thin · 40–59
60Opaque · 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 Corallo35847356473
Jeffrey Czyz17741177168
Wilmer Paulino14939149169
Leo Nash11613116162
Valentine Wallace13710135169
Vincenzo Palazzo10210184
Joost Jager16224162069
elnosh301330056
shaavan22622069
Carla Kirk-Cohen78366068
benthecarman18318071
Analysis record

Published AI watches

Last scanned 56 minutes ago

Low 32 AI analysisMessage 91 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Only fetch TXIDs instead of entire block during gossip verification' (#4846)

This commit changes how the Lightning Dev Kit's block-sync module verifies Lightning network gossip announcements. Instead of downloading entire Bitcoin blocks (which can be large), it now downloads only the list of transaction IDs for a b…

API surface change in UtxoSource traitReduced data exposure: no longer fetches full blocks for gossip verificationNew JSON parsing for txid lists and TxOut values
ebe7a447by Matt Corallo+275−1025 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'Allow filtered block rescans at the current tip' (#4847)

This commit changes how the Lightning Dev Kit (LDK) node software handles receiving the same block twice through its filtered-block interface. Previously, calling filtered_block_connected with the current tip again would trigger an asserti…

Assertion relaxation in block connection pathPotential denial-of-service vector removed: previously a malicious or buggy filter provider could crash the node by replaying the current tipNew test coverage for same-block filtered rescan
54ddbd0bby Matt Corallo+177−486 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add test framework coverage of `Listen` block connection replays

This commit only adds a new test mode to the project's internal testing framework. It lets developers simulate a specific way blocks are delivered to the Lightning node (a 'replay' through the Listen interface) so that behavior is covered …

bf6ad23eby Matt Corallo+18−32 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Update functional test block connection to detect block replays

This commit changes only internal test helper code in the Lightning Dev Kit repository. It makes the functional test framework smarter about 'block replays'—situations where the same block is fed to a test node more than once—so the fake b…

No production code modifiedNo cryptographic, consensus, or networking changesCommit message frames change as test-framework correctness, not security
477facb4by Matt Corallo+41−333 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 66 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct HTLC confusion on unrevoked counterparty commitment txs

This patch fixes a bug in the Lightning Dev Kit where the software could confuse HTLCs (payment contracts) on live, unrevoked counterparty commitment transactions with ones from old, revoked transactions. Previously, it relied only on whet…

Incorrect revocation state detection for counterparty commitment transactionsHTLC direction not previously checked when matching against pending HTLCsPromotion of debug assertions to full assertions for HTLC claim path consistency
f06a08a6by Matt Corallo+26−192 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Return `Err`s` instead of panicking on oversized messages

This commit changes how the Lightning networking code handles oversized encrypted messages. Previously, certain conditions would cause the program to crash with a panic. Now the code returns errors instead, which is a defensive improvement…

panic-to-error conversion for oversized message encryption/decryptiondenial-of-service hardening against oversized peer messagesdebug_assert retained to preserve test coverage of invariant violations
08f12bc7by Matt Corallo+68−313 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid panicking when attempting to send an oversized message

This commit fixes a crash bug in the Lightning Dev Kit's peer message handling. Previously, if a message grew too large to be sent over the encrypted peer connection, the code would panic (abruptly terminate the whole program). The patch m…

Replaces a `.expect()` panic path with a fallible `Result` in peer message encryptionAdds graceful peer disconnection when a critical message cannot be sentIncludes a regression test for oversized-message handling
c5fdc3bfby Matt Corallo+148−901 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 74 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid oversized relayed failure messages

This patch fixes a crash bug in the Lightning Dev Kit's handling of HTLC failure messages. A downstream peer could send a maximally-sized failure message without attribution data. When the node added its own attribution data while relaying…

Denial-of-service via remote-triggered panic in message encryptionOversized message exceeding Noise/Lightning wire framing limitMissing length validation before adding attribution data during relay
6b1dfb1aby Matt Corallo+64−191 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 64 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Reject attempts to advance one-hop blinded forward paths

This commit fixes a denial-of-service bug in rust-lightning where a maliciously crafted one-hop blinded reply path could cause the node to panic when it tried to respond. The fix rejects paths with too few hops before advancing them, and a…

Denial-of-service vector via malformed blinded pathPanic in onion construction due to zero-hop pathUntrusted reply path input validation gap
969a40cfby Matt Corallo+49−14 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 72 AI analysisMessage 96 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

lightning-types: replace Zl/Zp separators in `PrintableString`

This commit fixes a log-forgery risk in a Rust Lightning library helper called PrintableString. That helper is meant to make untrusted text safe to print by replacing dangerous characters with a placeholder. It already caught most control …

log injection / log forgery via U+2028/U+2029 line separatorsincomplete input sanitisation in PrintableStringpeer-controlled strings (node alias, BOLT 12 description/issuer/payer_note, peer_msg) as attack surface
75defa9cby Vincenzo Palazzo+63−83 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 69 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Apply the unfunded channel peer limit to all unaccepted channels

This commit fixes a rate-limiting bug in the Lightning Dev Kit (LDK) that let a single peer bypass the cap on how many different peers can have unfunded (not-yet-funded) channels open. Previously, if a peer sent multiple channel requests q…

Denial-of-service resource exhaustion via rapid inbound channel open requestsLogic error in rate-limiting conditionRegression test added for the bypass scenario
56a4ee43by Matt Corallo+87−62 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 88 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Allow filtered block rescans at the current tip

This commit fixes a bug where replaying the current blockchain block through a normal listener callback could crash two core Lightning components (ChannelManager and OutputSweeper) with a panic. The fix recognizes a same-block replay as a …

panic in chain listener callbacksame-block replay/rescan mishandlingassertion failure on valid chain input
686f9860by Elias Rohrer+118−123 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 57 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Avoid panic when reorged claims cannot merge

This commit fixes a crash bug in the Lightning Dev Kit's on-chain transaction handler. During a deep blockchain reorganization, a previously settled HTLC claim could be 'resurrected' at a block height where it could no longer be combined w…

Assertion/panic in reorg handling pathDeep blockchain reorg as trigger conditionHTLC claim resurrection after reorg
f1dc8487by Matt Corallo+219−52 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 45 · Thin
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Update crate repository links to forgejo

This commit simply updates the 'repository' web links in 15 package metadata files from GitHub to a self-hosted Forgejo instance. It does not change any program code, build logic, dependencies, or security behavior. There is no security is…

eb77676dby benthecarman+15−1515 files
No security note in commit
Open full analysis →Source commit ↗
Low 45 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Account for message type prefix len in prevtx length enforcement

This commit fixes a small but real accounting bug in how rust-lightning checks whether a previous transaction (prevtx) attached to a funding input will make the resulting Lightning wire message too large. The code previously compared the m…

Off-by-constant length check in protocol message size enforcementPotential acceptance of a prevtx that produces an oversized Lightning wire messageDenial-of-service / protocol-interop risk from peer message rejection
d29e1415by Wilmer Paulino+21−41 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 54 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Retransmit splice_locked for 0-conf channels missing tx_signatures

This commit fixes a bug in the Lightning Dev Kit where, after a disconnection, a node could fail to retransmit a 'splice_locked' message to a peer that was still waiting for transaction signatures. Without this retransmission, the two peer…

Protocol state desynchronization between channel peers after reconnectionMissing retransmission of splice_locked for 0-conf splice channelsPotential channel unusability or stuck splice negotiation
5434015bby Wilmer Paulino+266−12 files
No security note in commit
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

bolt12: add pay_for_bolt12_invoice for externally-sourced invoices

This commit adds a new API, pay_for_bolt12_invoice, that lets users pay a BOLT 12 invoice even if LDK did not originally request it. It is intended for advanced use cases like multi-sender payments and replaces an older, more restrictive A…

New API removes internal invoice-origin verification, shifting trust boundary to callerDocumentation explicitly warns caller to verify invoice via Bolt12Invoice::verify_using_metadata and to ensure unique payment_id to avoid duplicate paymentsInput validation added for zero amount, overpay, and partial-amount-without-MPP
5b80fe9cby Alkamal01+550−156 files
No security note in commit
Open full analysis →Source commit ↗
Low 26 AI analysisMessage 90 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Include to_self_delay size in DelayedPaymentOutput weight calculation

This commit fixes a small accounting bug in how the Lightning wallet estimates the size (and therefore transaction fee) of a special Bitcoin transaction that sweeps funds back to the user after a channel closes. The old code always assumed…

debug assertion failure possible in development/testing buildstransaction weight/fee estimate overestimation up to 3 WUconstant replaced with per-descriptor length computation
e6652237by Matt Morehouse+97−83 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 65 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Correct docs on `ChannelSigner::get_per_commitment_point`

This commit only updates documentation comments for a Rust function called get_per_commitment_point. It removes an outdated warning that the method was non-asynchronous and that returning an error could cause a crash, and replaces it with …

Documentation-only changeRemoves outdated panic warningAdds retry/unblock guidance for signer errors
5057809bby Matt Corallo+6−31 file
No security note in commit
Open full analysis →Source commit ↗
Informational 16 AI analysisMessage 35 · Opaque
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln/refactor: remove BlindedTrampolineEntrypoint

This commit is a small internal code cleanup in the Lightning Dev Kit's Trampoline routing code. It removes a separate 'BlindedTrampolineEntrypoint' payload variant and folds an optional blinding point into the existing 'Forward' variant. …

Refactor-only change with no added bounds checks or validationNo mention of vulnerability, CVE, security fix, or bug in commit messageTLV field changed from required to optional, but only for a newly unified variant used in internal construction
3e0c2697by Carla Kirk-Cohen+8−263 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.

Lower-priorityStop using RAA-unblocking post event action chan funding outpointsby Matt Corallo · 10df89dd · Aug 6, 2025 · 2 filesMessage 85 · StrongLow 27Details
Commit message · Matt Corallo

Stop using RAA-unblocking post event action chan funding outpoints

Historically we indexed channels by
`(counterparty_node_id, funding outpoint)` in several pipelines,
especially the `ChannelMonitorUpdate` pipeline. This ended up
complexifying quite a few things as we always needed to store the
full `(counterparty_node_id, funding outpoint, channel_id)` tuple
to ensure we can always access a channel no matter its state.

Over time we want to move to only the
`(counterparty_node_id, channel_id)` tuple as *the* channel index,
especially as we move towards V2 channels that have a
globally-unique `channel_id` anyway.

Here we take one small step towards this, avoiding using the
channel funding outpoint in the `EventCompletionAction` pipeline.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Low 27/100

This commit is a code cleanup in the Lightning Dev Kit (LDK). It changes how internal channel tracking identifies channels, moving from using a Bitcoin transaction outpoint (a specific on-chain funding reference) to using a stable channel ID. The commit message frames this as a step toward supporting newer channel types and simplifying the code. There is no direct evidence in the commit or message that this fixes a security vulnerability.

Lower-priorityBroadcast holder commitment for currently confirmed fundingby Wilmer Paulino · 89ce01d3 · Aug 5, 2025 · 2 filesMessage 85 · StrongModerate 63Details
Commit message · Wilmer Paulino

Broadcast holder commitment for currently confirmed funding

A `FundingScope` can only be promoted once a
`ChannelMonitorUpdateStep::RenegotiatedFundingLocked` is applied, or if
the monitor is no longer accepting updates, once the renegotiated
funding transaction is no longer under reorg risk. Because of this, our
current `FundingScope` may not reflect the latest confirmed state in the
chain. Before making a holder commitment broadcast, we must check which
`FundingScope` is currently confirmed to ensure that it can propogate
throughout the network.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Moderate 63/100

This change fixes a bug in how the Lightning node decides which commitment transaction to broadcast when a channel has gone through splicing or dual-funded RBF (i.e., the funding transaction was replaced). Previously, the node might broadcast a holder commitment tied to the wrong, no-longer-confirmed funding transaction, which could fail to claim funds or leave them exposed. The patch makes the monitor track which funding transaction is actually confirmed and uses that funding scope when generating the broadcast and related claims. It also cleans up stale claim requests when the active funding changes due to a reorg or replacement.

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.