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

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 24 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
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 ↗
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 ↗
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
Open full analysis →Source 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
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-prioritySimplify in_flight_monitor_updates from Option<HashMap> to HashMapby Joost Jager · b509c4a9 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Simplify in_flight_monitor_updates from Option<HashMap> to HashMap

Since there is no semantic difference between None and Some(empty map)
for in_flight_monitor_updates, simplify the type to HashMap and use
unwrap_or_default() when reading from TLV fields.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

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

This is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It changes a data field from 'optional map' to just 'map' because an empty map means the same thing as no map. There is no security-relevant behavior change.

Lower-priorityCombine claimable HTLCs with purposes in ChannelManagerDataby Joost Jager · 07bcba97 · Feb 5, 2026 · 1 fileMessage 83 · StrongLow 29Details
Commit message · Joost Jager

Combine claimable HTLCs with purposes in ChannelManagerData

Move the reconstruction of claimable_payments from the main
ChannelManager::read into ChannelManagerData::read. This removes
the separate claimable_htlc_purposes and claimable_htlc_onion_fields
fields from ChannelManagerData, replacing them with the combined
claimable_payments HashMap.

This requires adding a node_signer parameter to ChannelManagerDataReadArgs
to support verification of legacy hop data when reconstructing payment
purposes for very old serialized data (pre-0.0.107).

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
defensive validation
AI analysis · Low 29/100

This commit is a code-cleanup refactor that moves the reconstruction of claimable payment data from one deserialization function to another. It does not change the underlying security logic but reorganizes how legacy payment records are verified when loading old wallet state. There is no direct evidence in the commit that this fixes an active security vulnerability.

Lower-prioritySimplify peer_storage_dir from Option<Vec> to Vec in ChannelManagerDataby Joost Jager · 47901533 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Simplify peer_storage_dir from Option<Vec> to Vec in ChannelManagerData

Since there is no semantic difference between None and Some(empty vec)
for peer_storage_dir, simplify the type to Vec and use unwrap_or_default()
when reading from TLV fields.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

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

This is a small internal code cleanup in the Lightning Dev Kit's Rust implementation. It changes a data structure field from 'optional list' to just 'list', because an empty list and a missing list meant the same thing. There is no security-relevant change here.

Lower-priorityGroup legacy fields in ChannelManagerData to deduplicate commentby Joost Jager · 77be67b0 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Group legacy fields in ChannelManagerData to deduplicate comment

Reorder the struct fields to place all three `_legacy` fields together
at the end, allowing the explanatory comment to appear once instead of
being duplicated three times.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

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 pure code cleanup: it rearranges three struct fields in the Lightning channel manager so that a single comment can explain all of them instead of repeating the same comment three times. No behavior changes, no security fixes, and no bug fixes are present.

Lower-priorityUse consistent unwrap_or_else pattern for optional TLV fieldsby Joost Jager · 4a640d15 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 12Details
Commit message · Joost Jager

Use consistent unwrap_or_else pattern for optional TLV fields

Initialize pending_claiming_payments and monitor_update_blocked_actions_per_peer
with None and resolve with unwrap_or_else, matching the pattern used for other
optional hash map fields like pending_intercepted_htlcs_legacy.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

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

This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It changes how two optional data fields are initialized during deserialization so they follow the same safe pattern already used elsewhere. There is no indication this fixes a security vulnerability or changes observable behavior for users.

Lower-priorityAdd a `custom` TLV read/write variantby Matt Corallo · 05c9a036 · Feb 4, 2026 · 2 filesMessage 68 · AdequateInformational 12Details
Commit message · Matt Corallo

Add a `custom` TLV read/write variant

At various points we've been stuck in our TLV read/write variants
but just want to break out and write some damn code to initialize
a field and some more code to decide what to write for a TLV.

We added the write-side part of this with the `legacy` TLV
read/write variant, but its useful to also be able to specify a
function which is called on the read side.

Here we add a `custom` TLV read/write variant which calls a method
both on read and write to either decide what to write or to map a
read value (if any) to the final field.

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

This commit adds a new 'custom' variant to LDK's TLV (Type-Length-Value) serialization macros. It is a developer-facing feature that lets programmers supply custom read and write functions when serializing/deserializing data structures. The change is purely additive and does not by itself fix a bug or introduce a vulnerability; it is infrastructure for future message formats.

Security candidateUse SignedAmount::unsigned_abs to avoid overflowby Jeffrey Czyz · 2d948fdd · Feb 4, 2026 · 1 fileMessage 85 · StrongLow 34Details
Commit message · Jeffrey Czyz

Use SignedAmount::unsigned_abs to avoid overflow

In debug mode, using SignedAmount::abs can lead to an integer overflow
when used with SignedAmount::MIN. Use SignedAmount::unsigned_abs to
avoid this.

85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 34/100

This commit fixes a potential integer overflow bug in the Lightning Dev Kit's channel splicing code. The bug occurs when converting a negative Bitcoin amount to its absolute value in debug builds, which could crash the program. The fix uses a safer method that cannot overflow. The practical security impact is limited because the overflow only happens in debug mode and the affected values are normally constrained by protocol rules.

Lower-priorityCheck semver of all workspace crates rather than an explicit listby Matt Corallo · a123cfa0 · Feb 3, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Matt Corallo

Check semver of all workspace crates rather than an explicit list

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 updates an automated GitHub workflow that checks whether code changes break promised version compatibility. It replaces a manually maintained list of checks with a single tool command that scans all crates in the project. There is no change to the actual Lightning library code, user-facing behavior, or network security.

AI review queuedCorrect crate version numbers that have broken semverby Matt Corallo · 784b85c1 · Feb 3, 2026 · 10 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo

Correct crate version numbers that have broken semver

The semver CI check is great but only checks the immediate crate in
question. It doesn't catch that many of our crates depend on
`lightning` and thus have actually broken semver as the types they
use have changed to `lightning` 0.3.

Here we hump the version of crates that have actually changed
semver since 0.2.

In addition to those that depend on `lightning`,
`lightning-invoice`'s API has changed (but was not being checked by
the semver CI task).

Finally, `lightning-macros` was updated to 0.2.1, so the version is
changed to 0.2.2.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only changes version numbers in package configuration files (Cargo.toml). It bumps crate versions from 0.2.x to 0.3.x to keep them aligned with semantic versioning rules after the underlying `lightning` crate changed its public types. There is no code change, no bug fix, and no security patch.

Security candidateFix 0.2 CHANGELOG to note that offers will break on downgradeby Matt Corallo · e245c0aa · Feb 3, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · Matt Corallo

Fix 0.2 CHANGELOG to note that offers will break on downgrade

It turns out we also switched the key we use to authenticate offers
*created* in the 0.2 upgrade and as a result downgrading to 0.2
will break any offers created on 0.2. This wasn't intentional but
it doesn't really seem worth fixing at this point, so just document
it.

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

This commit is a documentation-only update to the 0.2 release CHANGELOG. It adds a note warning users that if they upgrade to LDK 0.2, create BOLT 12 offers, and then downgrade to an older LDK version, those offers will not be accepted. This is a compatibility/operational issue, not a security vulnerability, and no code behavior is changed.

Security candidateAdd AChainMonitor trait and use it in background processorby Joost Jager · 4800a473 · Feb 3, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Add AChainMonitor trait and use it in background processor

Add a new `AChainMonitor` trait following the same pattern as
`AChannelManager`. This trait provides associated types for all
generic parameters of `ChainMonitor` and a `get_cm()` method to
access the underlying `ChainMonitor`.

Update the background processor to use `AChainMonitor` trait bounds
instead of spelling out the full `ChainMonitor` generic parameters.
This simplifies the function signatures by removing 5-6 explicit
generic parameters (CF, T, F, P, ES) per function.

This is preparation for adding a flush method to the AChainMonitor
trait.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

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

This commit is a pure internal refactoring in the Lightning Dev Kit Rust library. It introduces a new helper trait called AChainMonitor that wraps the existing ChainMonitor type, and updates background-processor functions to use that trait instead of listing many generic type parameters directly. There is no change to user-visible behavior, no bug fix, and no security-sensitive logic change.

AI review queuedAdd Utxo::new_v1_p2trby Willem Van Lint · 1f6095b5 · Feb 2, 2026 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · Willem Van Lint

Add Utxo::new_v1_p2tr

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: opaque commit messagesecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit adds a new helper function to create a UTXO descriptor for modern Taproot (P2TR) single-key spending. It is purely additive API surface with no changes to existing behavior, no bug fixes, and no security-sensitive logic beyond correctly estimating transaction weight for fee calculations.

Lower-priorityUse `--quiet` not `--verbose` on `cargo` calls in `ci-tests.sh`by Matt Corallo · d2eeb0a9 · Feb 2, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Matt Corallo

Use `--quiet` not `--verbose` on `cargo` calls in `ci-tests.sh`

I'm pretty confident I've never needed the full command strings
printed by the `--verbose` argument to `cargo` in `ci-tests.sh` and
it makes the output nontrivially larger. Further, I'm not sure
there's really much reason at all to output which thing is built
built - we only care about failures, thus we switch to `--quiet`.

This should make CI output comparatively easy to parse as scrolling
up to see which command failed requires a lot less scrolling.

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

This commit only changes CI test scripts to use cargo's --quiet flag instead of --verbose. It reduces log output size and makes CI logs easier to read. There is no change to application code, no security fix, and no vulnerability introduced.

AI review queuedDrop unused importsby Elias Rohrer · 0715f4aa · Feb 2, 2026 · 2 filesMessage 28 · OpaqueInformational 15Details
Commit message · Elias Rohrer

Drop unused imports

Co-Authored-By: HAL 9000

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 simply removes two unused import statements from Rust source files. It does not change any program logic, data handling, or security behavior. There is no security relevance.

Security candidateAdd test coverage for `TransactionType::Splice`by Elias Rohrer · 32a801ef · Feb 2, 2026 · 8 filesMessage 78 · AdequateInformational 15Details
Commit message · Elias Rohrer

Add test coverage for `TransactionType::Splice`

Add parallel `txn_types` vector to `TestBroadcaster` to track
`TransactionType` alongside broadcast transactions. Existing
`txn_broadcast()` API remains unchanged for backward compatibility.
New `txn_broadcast_with_types()` API allows tests to verify transaction
types.

Also add a `clear()` helper method and update test files to use it
instead of directly manipulating `txn_broadcasted`, ensuring the two
vectors stay in sync.

Update splice tests to use the new API and verify that splice
transactions are broadcast with the correct `TransactionType`.

Co-Authored-By: HAL 9000
Signed-off-by: Elias Rohrer <dev@tnull.de>

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
boot or update path
AI analysis · Informational 15/100

This commit only adds and improves test code. It gives the project's test mock broadcaster the ability to remember what 'type' each broadcast transaction was (for example, a splice transaction), and updates tests to check that splice transactions are labeled correctly. There is no change to production code that handles real money or network messages, so it does not introduce or fix a security vulnerability on its own.

AI review queuedRefactor `BroadcasterInterface` to include `TransactionType`by Elias Rohrer · 988f1b14 · Feb 2, 2026 · 11 filesMessage 73 · AdequateInformational 21Details
Commit message · Elias Rohrer

Refactor `BroadcasterInterface` to include `TransactionType`

Add a `TransactionType` enum to provide context about the type of
transaction being broadcast. This information can be useful for
logging, filtering, or prioritization purposes.

The `TransactionType` variants are:
- `Funding`: A funding transaction establishing a new channel
- `CooperativeClose`: A cooperative close transaction
- `UnilateralClose`: A force-close transaction
- `AnchorBump`: An anchor transaction for CPFP fee-bumping
- `Claim`: A transaction claiming outputs from commitment tx
- `Sweep`: A transaction sweeping spendable outputs to wallet

Co-Authored-By: HAL 9000
Signed-off-by: Elias Rohrer <dev@tnull.de>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 21/100

This commit is a straightforward API refactor: it adds a TransactionType label (Funding, Close, Claim, Sweep, etc.) to every place in the Lightning Dev Kit that broadcasts a Bitcoin transaction. The actual transactions being broadcast do not change; only the metadata passed alongside them changes. There is no security vulnerability being fixed or introduced here.

Lower-priorityinvoice: Use PaymentHash in raw invoice typesby Jon · d652d86a · Feb 2, 2026 · 9 filesMessage 45 · ThinInformational 20Details
Commit message · Jon

invoice: Use PaymentHash in raw invoice types

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

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's invoice handling. It replaces the use of a generic SHA-256 hash type with a dedicated PaymentHash type when representing payment hashes inside BOLT11 invoices. There is no indication this fixes a security vulnerability; it is a type-safety and consistency refactor that touches many test files and a few production call sites.

Security candidateExport `outbound_payments` directly rather than via re-exportsby Matt Corallo · 0bc5c954 · Feb 2, 2026 · 28 filesMessage 85 · StrongInformational 19Details
Commit message · Matt Corallo

Export `outbound_payments` directly rather than via re-exports

Every time we use re-exports to hide a module in the public API we
end up accidentally breaking the public API due to accidental
seals. We did this yet again in
e9c6bbccc3ccd4cb121a092229f50e29b3345552 where we moved to using a
`CustomTlvs` field in the public API for `RecipientOnionFields` but
forgot to re-export it, making it impossible to use downstream.

Instead, here, we just actually export `outbound_payments`.

Compilation fixes by Claude.

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
signing or wallet pathboot or update path
AI analysis · Informational 19/100

This commit is a straightforward code cleanup in a Rust Lightning library. It stops hiding an internal module behind re-exports and exposes it directly in the public API. The change fixes an earlier accidental break in the public API where a type (CustomTlvs) was used in a public struct but not re-exported, making it hard for downstream developers to use. There is no runtime security issue, no bug fix in payment logic, and no exploit.

AI review queuedResolve optional hash map TLV fields during ChannelManagerData deserializationby Joost Jager · 9a05daf3 · Feb 2, 2026 · 1 fileMessage 73 · AdequateInformational 24Details
Commit message · Joost Jager

Resolve optional hash map TLV fields during ChannelManagerData deserialization

Move the unwrap_or_else(new_hash_map) resolution for pending_intercepted_htlcs
and decode_update_add_htlcs from stage 2 (from_channel_manager_data) to stage 1
(ChannelManagerData::read). This changes the struct fields from Option<HashMap>
to HashMap, making it explicit that these are always present after deserialization.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 24/100

This commit is a small internal cleanup in the Lightning Dev Kit's channel manager. It moves the handling of two optional hash-map fields from a later processing stage into the deserialization stage, so the fields are always plain hash maps after loading. The change makes the code's invariants clearer and removes a potential source of inconsistency, but it does not appear to fix an active security bug on its own.

AI review queuedResolve legacy TLV fields during ChannelManagerData deserializationby Joost Jager · d2c55dd2 · Feb 2, 2026 · 1 fileMessage 73 · AdequateLow 28Details
Commit message · Joost Jager

Resolve legacy TLV fields during ChannelManagerData deserialization

Move the resolution of legacy/compatibility TLV fields from
from_channel_manager_data (stage 2) into ChannelManagerData::read
(stage 1). This keeps ChannelManagerData minimal by consolidating
mutually exclusive fields into their final form during deserialization:

- pending_outbound_payments: Merge TLV 3, TLV 1 (no_retry), and
non-TLV compat fields into a single HashMap
- in_flight_monitor_updates: Convert legacy TLV 10 (keyed by OutPoint)
to TLV 17 format (keyed by ChannelId)
- pending_events: Apply events_override (TLV 8) if present

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Low 28/100

This commit is an internal code cleanup in the Lightning Dev Kit's channel manager. It moves the handling of old data formats (legacy TLV fields) from a later initialization stage into the deserialization stage, so the data structure is normalized earlier. There is no direct evidence this fixes an active security vulnerability; it appears to be a maintainability and correctness refactor to prevent inconsistencies when loading older persisted data.

AI review queuedExtract second stage of ChannelManager::read into from_channel_manager_databy Joost Jager · f08f4b4f · Feb 2, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Joost Jager

Extract second stage of ChannelManager::read into from_channel_manager_data

Move the validation and reconstruction logic (stage 2) from the
ReadableArgs::read implementation into a new pub(super) constructor
`from_channel_manager_data`. This separates the pure deserialization
from the complex reconstruction logic, making the code more modular
and easier to test.

The read function now:
1. Deserializes into ChannelManagerData (stage 1)
2. Calls from_channel_manager_data for validation/reconstruction (stage 2)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100

This commit is a pure code refactoring: it moves an existing block of logic from one place inside a function into a newly created helper function, without changing what the logic actually does. There is no security-relevant behavior change visible in the diff.

Lower-prioritySimplify legacy TLV resolution in ChannelManagerData::readby Joost Jager · 397cc1dc · Feb 2, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager

Simplify legacy TLV resolution in ChannelManagerData::read

The previous commit intentionally kept the code as close to a move as
possible to ease review. This follow-up applies idiomatic simplifications:

- Use unwrap_or for events_override resolution
- Use unwrap_or_else with iterator chains for pending_outbound_payments
- Use match with into_iter().collect() for in_flight_monitor_updates

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

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 follow-up cleanup that rewrites three sections of deserialization logic in rust-lightning's ChannelManager to use more idiomatic Rust iterator methods. It does not change the underlying behavior, data formats, or security checks; it only makes the code shorter and easier to read.

AI review queuedSplit ChannelManager::read into two stagesby Joost Jager · 3deecd4a · Feb 2, 2026 · 1 fileMessage 68 · AdequateInformational 12Details
Commit message · Joost Jager

Split ChannelManager::read into two stages

Introduce ChannelManagerData<SP> as an intermediate DTO that holds all
deserialized data from a ChannelManager before validation. This splits
the read implementation into:

1. Stage 1: Pure deserialization into ChannelManagerData
2. Stage 2: Validation and reconstruction using the DTO

The existing validation and reconstruction logic remains unchanged;
only the deserialization portion was extracted into the DTO's
ReadableArgs implementation.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 12/100

This commit is a pure internal code reorganization. It splits the loading of a Lightning node's ChannelManager into two steps: first reading raw data into a temporary data holder, then validating and building the actual ChannelManager. No security behavior appears to change; it is a refactoring to make the code easier to maintain and test.

AI review queuedUnwrap TLV fields with initialized defaults in ChannelManagerDataby Joost Jager · fe6fd648 · Feb 2, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · Joost Jager

Unwrap TLV fields with initialized defaults in ChannelManagerData

For TLV fields that are initialized with Some(...) before reading and
thus always have a value after deserialization, remove the Option
wrapper from ChannelManagerData and unwrap when constructing it.

This applies to pending_claiming_payments and
monitor_update_blocked_actions_per_peer.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 18/100

This is a small internal cleanup in the Lightning Dev Kit's Rust code. It removes unnecessary 'Option' wrappers from two data fields that are always set during deserialization, replacing later `.unwrap()` calls with direct use. The change does not introduce a new security vulnerability; it is a refactoring that makes the code clearer and slightly reduces panic risk by moving the unwrapping to a point where the value is guaranteed to exist.

Lower-priorityRemove spurious universality comment on `KVStore`by Matt Corallo · 16a69168 · Jan 31, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Matt Corallo

Remove spurious universality comment on `KVStore`

There would be nothing wrong with passing a different `KVStore` to
`OutputSweeper` from `MonitorUpdatingPersister` (though I'm not
really sure why someone would), and in fact I'm not aware of any
cases where passing a different `KVStore` to different structs
would be problematic. Thus, the sentence in docs is simply removed.

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

This commit only removes a misleading documentation comment. It does not change any code behavior, fix a bug, or address a security issue. The previous comment incorrectly warned that using different data stores for different parts of the lightning node could be unsafe; the commit author clarifies that this is not actually a problem.