LDK
← All projectsLightning Dev Kit

rust-lightning

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

BitcoinCryptographic librariesLightning NetworkNormal
Repository coverage

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

252security candidates228second-pass queue1525AI analyses
81commits · 30 days
180commits · 60 days
553commits · 180 days
1254commits · 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
473Strong · 80–100
836Adequate · 60–79
294Thin · 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 Corallo43553371574
Jeffrey Czyz19545182169
Wilmer Paulino15945155169
Leo Nash11613116162
Valentine Wallace14511138169
Vincenzo Palazzo11311183
Joost Jager16224162069
elnosh391333058
auto-pr-bot2478087
shaavan22622069
Carla Kirk-Cohen78366068
Analysis record

Published AI watches

Last scanned 0 minutes ago

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Informational 20 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice' (#4942)

This commit is a simple rename of a public function from `matches_invoice_signing_pubkey` to `key_can_sign_invoice`, plus matching updates to its documentation, callers, tests, and changelog. No behavior changed. It is not a security fix.

a476cf92by Matt Corallo+13−133 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice

This commit is a simple rename of a function and its documentation from matches_invoice_signing_pubkey to key_can_sign_invoice. No logic, behavior, or security properties changed. It is a follow-up code-review naming cleanup.

388187caby Vincenzo Palazzo+13−133 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-prioritySimplify error return patterns in channel.rsby Joost Jager · 51b5ef79 · Jan 8, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Joost Jager

Simplify error return patterns in channel.rs

Extract error message strings into local variables before constructing
ChannelError return tuples, reducing nesting and improving readability.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a pure code cleanup: it extracts long error message strings into local variables before building the same error return values. There is no functional change, no security fix, and no change to what the program does.

AI review queuedRustfmt channel methodsby Joost Jager · 8ae40eed · Jan 8, 2026 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · Joost Jager

Rustfmt channel methods

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations from three methods in the Lightning channel code and lets rustfmt reformat the function signatures, calls, and log statements across multiple lines. No logic, behavior, or security checks were changed.

AI review queuedAdd logger to monitor_updating_pausedby Joost Jager · cafbd568 · Jan 8, 2026 · 2 filesMessage 35 · OpaqueInformational 14Details
Commit message · Joost Jager

Add logger to monitor_updating_paused

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 14/100

This commit only adds a logging parameter to an internal helper function and its callers. It does not change program logic, state handling, or security behavior. The change is purely for better observability when channel monitor updates are paused.

Lower-prioritySplit `OffersContext::OutboundPayment` into `InRefund`/`InInvReq`by Matt Corallo · 92038188 · Jan 6, 2026 · 4 filesMessage 85 · StrongLow 26Details
Commit message · Matt Corallo

Split `OffersContext::OutboundPayment` into `InRefund`/`InInvReq`

Because they end up both being used to validate a `Bolt12Invoice`,
we ended up with a single `OffersContext` both for inclusion in a
`Refund` and an `InvoiceRequest`. However, this is ambiguous, and
while it doesn't seem like an issue, it also seems like a nice
property to only use a given `OffersContext` in one place.

Further, in the next commit, we use `OffersContext` to figure out
what we're building a blinded path for and changing behavior based
on it, so its nice to be unambiguous.

Thus, we split the single existing context into
`OutboundPaymentInRefund` and `OutboundPaymentInInvReq`.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
defensive validation
AI analysis · Low 26/100

This commit refactors how the Lightning Dev Kit tracks whether a BOLT12 invoice is tied to a Refund versus a regular InvoiceRequest. Previously, one shared context type was used for both, which could lead to ambiguous handling. The change splits that shared context into two distinct variants and adds checks so that Refund-only contexts are only accepted for Refund invoices and InvoiceRequest contexts only for Offer invoices. It is a hardening/correctness change rather than a clear-cut security fix, but it removes ambiguity that could in principle be abused to trick the code into accepting an invoice in the wrong context.

Lower-priorityAdd a pending changelog note for breaking invreq blinded pathsby Matt Corallo · d7b86e58 · Jan 6, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Matt Corallo

Add a pending changelog note for breaking invreq blinded paths

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit only adds a pending changelog note. It documents that outbound payments waiting for a BOLT 12 invoice response will fail to complete after upgrading to version 0.3. There is no code change, no vulnerability, and no security fix in this commit itself.

Lower-priorityAlways pad `BlindedMessagePath` hop data to a consistent lengthby Matt Corallo · c589389f · Jan 6, 2026 · 6 filesMessage 85 · StrongModerate 51Details
Commit message · Matt Corallo

Always pad `BlindedMessagePath` hop data to a consistent length

If we're building a blinded message path with extra dummy hops, we
have to ensure we at least hide the length of the data in pre-final
hops as otherwise the dummy hops are trivially obvious. Here we do
so, taking an extra `bool` parameter to `BlindedMessagePath`
constructors to decide whether to pad every hop to the existing
`MESSAGE_PADDING_ROUND_OFF` or whether to only ensure that each
non-final hop has an identical hop data length.

In cases where the `DefaultMessageRouter` opts to use compact
paths, it now also selects compact padding, whether short channel
IDs are available or not.

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 51/100

This commit fixes a privacy leak in Lightning onion messages. When building a blinded path with fake 'dummy' hops, the program previously did not always hide the size of the data carried at each hop. That made the dummy hops easy to spot, defeating their purpose. The patch adds a new padding mode so that every non-final hop is padded to the same length, keeping dummy hops indistinguishable from real ones. It also lets compact paths use this same minimal padding instead of skipping padding entirely.

Lower-priorityAdd additional documentation on when to use `NodeIdMessageRouter`by Matt Corallo · dc623d3c · Jan 6, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Matt Corallo

Add additional documentation on when to use `NodeIdMessageRouter`

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only adds a three-line documentation comment explaining when developers might want to use a specific message-routing helper. It does not change any code behavior, fix a bug, or alter security logic.

Lower-priorityMake `DefaultMessageRouter` use the context to pad/compact pathsby Matt Corallo · 485ae4e0 · Jan 6, 2026 · 3 filesMessage 93 · StrongLow 35Details
Commit message · Matt Corallo

Make `DefaultMessageRouter` use the context to pad/compact paths

After much discussion in #3246 we mostly decided to allow
downstream developers to override whatever decisions the
`DefaultMessageRouter` makes regarding blinded path selection by
providing easy overrides for the selected `OnionMessageRouter`. We
did not, however, actually select good defaults for
`DefaultMessageRouter`.

Here we add those defaults, taking advantage of the
`MessageContext` we're given to detect why we're building a blinded
path and selecting blinding and compaction parameters based on it.

Specifically, if the blinded path is not being built for an offers
context, we always use a non-compact blinded path and always pad it
to four hops (including the recipient).

However, if the blinded path is being built for an `Offers` context
which implies it might need to fit in a QR code (or, worse, a
payment onion), we reduce our padding and try to build a compact
blinded path if possible.

We retain the `NodeIdMessageRouter` to disable compact blinded path
creation but use the same path-padding heuristic as for
`DefaultMessageRouter`.

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
AI analysis · Low 35/100

This commit changes how Lightning Dev Kit builds private 'blinded paths' used to route messages without revealing the recipient's exact location. It makes the default router choose shorter, more compact paths when the message is part of a BOLT 12 offer that might be encoded in a QR code, and longer, padded paths otherwise. The goal is to balance privacy with fitting data into QR codes and payment onions. The change itself is a privacy-tuning improvement, not a direct security bug fix, though it touches code that affects how easily a recipient can be identified.

Lower-priorityAdd a trivial helper to LSPS5's `WebhookNotification`by Matt Corallo · c06aa96e · Jan 5, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo

Add a trivial helper to LSPS5's `WebhookNotification`

`LSPS5ServiceEvent::SendWebhookNotification`'s docs say to send the
`WebhookNotification` as the HTTP request body "as JSON", which is
great, but it leaves the dev to figure out how to do that. Its nice
to have a helper to do that, which is trivial so we provide it
here.

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

This commit adds a small convenience helper that converts an LSPS5 webhook notification into a JSON string. It is purely a developer-experience improvement and does not change any security behavior.

Lower-priorityRefactor payment_hash to return PaymentHashby psychemist · 9c802c25 · Jan 4, 2026 · 5 filesMessage 78 · AdequateInformational 18Details
Commit message · psychemist

Refactor payment_hash to return PaymentHash

This commit fixes the payment_hash function of Bolt11Invoice to return a
PaymentHash type instead of a sha256 byte stream. Code and test files dependent
on this function have also been modified to adhere to the updated
changes.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 18/100

This is a routine code cleanup that changes how a BOLT 11 invoice exposes its payment hash. Previously the function returned a raw SHA-256 hash object; now it returns a typed PaymentHash wrapper. All callers are updated to use the new type. There is no security bug being fixed here and no behavior change to the Lightning protocol logic.

Lower-priorityMove to awaiting gossip validation in the background processorby Matt Corallo · ad78799b · Dec 31, 2025 · 3 filesMessage 81 · StrongLow 32Details
Commit message · Matt Corallo

Move to awaiting gossip validation in the background processor

`P2PGossipSync` is a rather poor design. It currently basically
requires two circular `Arc` references, leaving `NetworkGraph`s to
leak if LDK is un-loaded:
* `P2PGossipSync` owns/holds a reference to the
`GossipVerifier` and `GossipVerifier` holds an `Arc` to the
`P2PGossipSync` and
* `PeerManager` holds a reference to the `P2PGossipSync` (as the
gossip message handler) which owns/holds a reference to the
`GossipVerifier`, which has a `Deref` (likely an `Arc` in
practice) to the `PeerManager`.

Instead, we should move towards the same design we have elsewhere -
hold a `Notifier` and expose waiting on it to the background
processor then poll for completion from there (in this case, as in
others by checking for completion when handling
`get_and_clear_pending_msg_events` calls).

After the last few commits of setup, here we finally switch to
waking the background processor directly when we detect async
gossip validation completion, allowing us to drop the circular
references in `P2PGossipSync`/`GossipVerifier` entirely.

Fixes #3369

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Low 32/100

This commit refactors how Lightning Dev Kit handles background verification of gossip data (the routing information nodes share). Previously, the gossip verifier, the gossip sync component, and the peer manager held circular references to each other, which could prevent memory from being freed when LDK was unloaded. The change replaces those circular references with a notification mechanism: the background processor now waits directly for a 'validation completed' signal. This is primarily a memory-leak and architectural cleanup, not a direct exploit fix, but it removes a design that could keep resources alive unexpectedly.

Lower-priorityDrop the async-setting of the `P2PGossipSync` `utxo_verifier`by Matt Corallo · 15ddb316 · Dec 31, 2025 · 3 filesMessage 83 · StrongInformational 12Details
Commit message · Matt Corallo

Drop the async-setting of the `P2PGossipSync` `utxo_verifier`

Now that we do not rely on circular references for `P2PGossipSync`
validation, we no longer need the hacky
`P2PGossipSync::add_utxo_lookup` method to add the gossip
validator after building the `P2PGossipSync` first. Thus, we
remove it here, updating some tests that relied on it.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 12/100

This commit is a routine internal cleanup in the Lightning Dev Kit's gossip message handling code. It removes a method that let users set a UTXO (unspent transaction output) lookup provider after the object was created, because the codebase no longer needs that late-setup workaround. The change only affects how the code is structured and how tests are set up; it does not fix a security bug or introduce a known vulnerability.

Lower-priorityPass a new `Notifier` through to `UtxoFuture`sby Matt Corallo · efaadf57 · Dec 31, 2025 · 4 filesMessage 80 · StrongInformational 19Details
Commit message · Matt Corallo

Pass a new `Notifier` through to `UtxoFuture`s

`P2PGossipSync` is a rather poor design. It currently basically
requires two circular `Arc` references, leaving `NetworkGraph`s to
leak if LDK is un-loaded:
* `P2PGossipSync` owns/holds a reference to the
`GossipVerifier` and `GossipVerifier` holds an `Arc` to the
`P2PGossipSync` and
* `PeerManager` holds a reference to the `P2PGossipSync` (as the
gossip message handler) which owns/holds a reference to the
`GossipVerifier`, which has a `Deref` (likely an `Arc` in
practice) to the `PeerManager`.

Instead, we should move towards the same design we have elsewhere -
hold a `Notifier` and expose waiting on it to the background
processor then poll for completion from there (in this case, as in
others by checking for completion when handling
`get_and_clear_pending_msg_events` calls).

Here we take the first step towards this, adding a shared
`Notifier` to `PendingChecks` and piping it through to
`UtxoFuture`s so that they can be simply resolved and wake the
background processor (once it waits on the new `Notifier`).

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 19/100

This commit is a small internal cleanup in the Lightning Dev Kit Rust library. It changes how background tasks are notified when an asynchronous UTXO (unspent transaction output) lookup finishes, so that circular references between gossip-sync objects can eventually be removed. There is no direct security vulnerability being fixed here; it is a design refactor that may help prevent memory leaks in the future.

Lower-priorityPoll for resolved `UtxoFuture`s rather than resolving on the graphby Matt Corallo · 91a16c53 · Dec 31, 2025 · 4 filesMessage 73 · AdequateInformational 24Details
Commit message · Matt Corallo

Poll for resolved `UtxoFuture`s rather than resolving on the graph

`P2PGossipSync` is a rather poor design. It currently basically
requires two circular `Arc` references, leaving `NetworkGraph`s to
leak if LDK is un-loaded:
* `P2PGossipSync` owns/holds a reference to the
`GossipVerifier` and `GossipVerifier` holds an `Arc` to the
`P2PGossipSync` and
* `PeerManager` holds a reference to the `P2PGossipSync` (as the
gossip message handler) which owns/holds a reference to the
`GossipVerifier`, which has a `Deref` (likely an `Arc` in
practice) to the `PeerManager`.

Instead, we should move towards the same design we have elsewhere -
hold a `Notifier` and expose waiting on it to the background
processor then poll for completion from there (in this case, as in
others by checking for completion when handling
`get_and_clear_pending_msg_events` calls).

Here we do the bulk of this work, moving `UtxoFuture` resolution
to a simple function that signals the `Notifier` and stores the
result. We then poll to convert the result into forwarded messages
in `P2PGossipSync::get_and_clear_pending_message_events`. Note that
we still rely on manual wakeups from the gossip validator, but that
will be fixed in the next commit.

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

This commit refactors how Lightning Dev Kit handles asynchronous checks of Bitcoin transaction outputs (UTXOs) used to validate gossip messages about the network graph. Previously, resolving these checks required direct circular references between components, which could cause memory leaks when LDK was unloaded. The new design uses a notification/polling pattern instead, making the code cleaner and avoiding leaked objects. It is a defensive architectural fix rather than a patch for an active exploit.

Lower-prioritySimplify `Sleeper` init in sync `lightning-background-processor`by Matt Corallo · 5ff4051d · Dec 31, 2025 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo

Simplify `Sleeper` init in sync `lightning-background-processor`

Rather than `match`ing on on several optional objects (with another
one to come in a future commit), build an iterator over the futures
using the fact that an `Option` is an iterator.

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

This commit is a straightforward internal code cleanup in the Lightning Dev Kit Rust library. It replaces several hand-written helper functions for waiting on 2, 3, or 4 background tasks with a single helper that accepts any number of tasks using Rust's standard iterator features. There is no indication this fixes a security bug or changes user-facing behavior.

Lower-priorityAutomatically archive resolved `ChannelMonitor`s in the BPby Matt Corallo · ded972b5 · Dec 16, 2025 · 1 fileMessage 81 · StrongLow 36Details
Commit message · Matt Corallo

Automatically archive resolved `ChannelMonitor`s in the BP

When we first added auto-archiving of resolved `ChannelMonitor`s,
we wanted to be somewhat cautious of flipping it on by default as
archiving a `ChannelMonitor` too soon would be a critical bug and,
while we were confident in it, we weren't 100%. Since then its been
used extensively in various LDK deployments, including `ldk-node`.

Given its now seen substantial use, and performs an important
anti-DoS function, here we flip to calling it by default on a new
timer in `lightning-background-processor`.

Fixes #218

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Low 36/100

This change turns on automatic cleanup of old, resolved Lightning channel monitoring data by default in LDK's background processor. Previously this cleanup existed but was not enabled by default because archiving a monitor too early could risk losing funds. After broader real-world use, the developers now enable it automatically on a timer, which helps prevent denial-of-service/resource-exhaustion issues caused by keeping stale monitors around forever. The commit itself is a defensive hardening change, not an active vulnerability fix.

Lower-priorityUse more specific locked_handle_unfunded_close when possibleby Joost Jager · 42a993d5 · Dec 15, 2025 · 1 fileMessage 50 · ThinInformational 19Details
Commit message · Joost Jager

Use more specific locked_handle_unfunded_close when possible

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 19/100

This commit is a small internal cleanup in the Lightning Dev Kit's channel manager. It replaces calls to a more general force-close helper with a more specific helper meant for channels that have not yet been funded. The change removes duplicated parameters and makes the code clearer, but there is no direct evidence in the commit or supplied references that it fixes an active security vulnerability or changes externally observable behavior.

Lower-priorityRename convert_err methodsby Joost Jager · 275b0062 · Dec 15, 2025 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Joost Jager

Rename convert_err methods

Make the names more descriptive and link shared documentation.

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
AI analysis · Informational 15/100

This commit only renames several internal helper methods in the Lightning channel manager to make their purpose clearer (for example, 'convert_channel_err' becomes 'locked_handle_force_close'). No behavior changes, security fixes, or bug fixes are present in the diff.

AI review queuedInline format argsby Joost Jager · e50280cb · Dec 15, 2025 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · Joost Jager

Inline format args

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit is a minor code cleanup that changes how two error messages are formatted in Rust. It uses a newer, more concise syntax for embedding variables inside strings. There is no functional change and no security relevance.

Lower-priorityLDK Node Integration CI: Also patch LDK dependencies if `git`by Elias Rohrer · c7d1ba70 · Dec 12, 2025 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Elias Rohrer

LDK Node Integration CI: Also patch LDK dependencies if `git`

By now, we switched our LDK Node `main` to a specific commit on LDK's
`main`. Since we don't have the `crates.io` dependencies in the
`Cargo.toml`, the patch command won't actually do anything but silently
fail, i.e., *not* check the PR changes against the LDK Node main branch.

Here we fix this by also patching the git repository path.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This is a routine fix to an internal GitHub Actions CI workflow. The change ensures that when testing pull requests against the LDK Node project, the local copy of rust-lightning is patched in correctly even when LDK Node depends on it via a Git URL rather than crates.io. It has no effect on shipped code or user-facing security.

Lower-priorityGroup channel closure methods togetherby Joost Jager · 7fb84e66 · Dec 12, 2025 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Joost Jager

Group channel closure methods together

This commit is a pure move.

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit simply moves a group of channel-closing helper methods to a different location within the same file. No code behavior was changed, so it has no security impact on its own.

Lower-priorityConvert send_channel_ready macro to methodby elnosh · 3247fad6 · Dec 11, 2025 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · elnosh

Convert send_channel_ready macro to method

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit is a simple code cleanup: it turns an internal macro (a reusable code snippet) into a regular Rust method. The actual behavior of the program does not change. There is no security fix or vulnerability here.

Lower-priorityAllow clippy's new assertions-on-constants lintby Matt Corallo · 6ff720b9 · Dec 11, 2025 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Matt Corallo

Allow clippy's new assertions-on-constants lint

This is really dumb, `assert!(cfg!(fuzzing))` is a perfectly
reasonable thing to write!

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100

This commit only adds one line to a shell script used in continuous integration. It tells the Clippy code-analysis tool to ignore a newly introduced lint about assertions on constant values. The change does not modify any actual Rust source code, runtime behavior, or security-sensitive logic.

AI review queuedRustfmt touched methodsby Joost Jager · d436cbf5 · Dec 11, 2025 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · Joost Jager

Rustfmt touched methods

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit is purely a code-formatting cleanup. It uses rustfmt to rewrap long function signatures, break up long macro invocations, and adjust indentation in a single Rust source file. No logic, behavior, or security properties of the code were changed.

Lower-priorityRemove rustfmt::skip from touched methodsby Joost Jager · 7fe270b0 · Dec 11, 2025 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Joost Jager

Remove rustfmt::skip from touched methods

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit simply removes formatting-suppression annotations from several Rust methods. It does not change any executable code, logic, or security behavior. It is a code-style cleanup with no security relevance.