LDK
← All projectsLightning Dev Kit

rust-lightning

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

BitcoinCryptographic librariesLightning NetworkNormal
Repository coverage

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

249security candidates223second-pass queue1517AI analyses
88commits · 30 days
195commits · 60 days
565commits · 180 days
1307commits · 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
470Strong · 80–100
830Adequate · 60–79
293Thin · 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 Corallo43452370574
Jeffrey Czyz19545182169
Wilmer Paulino15945155169
Leo Nash11613116162
Valentine Wallace14010135169
Vincenzo Palazzo11311183
Joost Jager16224162069
elnosh371331057
auto-pr-bot2478087
shaavan22622069
Carla Kirk-Cohen78366068
Analysis record

Published AI watches

Last scanned 41 minutes ago

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

Merge PR 'offers: add Offer::permits_invoice_signed_by' (#4884)

This commit adds a new public helper method, Offer::matches_invoice_signed_by (later renamed matches_invoice_signing_pubkey), that lets callers check whether an invoice signing key belongs to the recipient named by a BOLT 12 offer. It also…

Refactors existing BOLT 12 invoice-signing-pubkey validation into a reusable helperAdds public API to bind an invoice signing key to an offer recipientAdds unit tests for issuer-id vs. path-last-hop matching behavior
016af8f9by Matt Corallo+81−135 files
No security note in commit
Low 29 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Support retired TLV fields in object-constructing macros

This commit is a feature enhancement for LDK's internal serialization macros. It allows developers to mark old protocol fields as 'retired' (reserved but no longer used) in more places, so those type numbers cannot be accidentally reused. …

TLV type-number reservation mechanism extended to more macro-generated code pathsPrevents accidental reuse of retired protocol field type numbersAvoids UnknownRequiredFeature decode failures for obsolete even-type fields
6d7c2bdaby Jeffrey Czyz+120−222 files
No security note in commit
Informational 17 AI analysisMessage 91 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Replace splice failure wire tests with a 0.2 downgrade test

This commit is a test-only cleanup in the Lightning Dev Kit (LDK) Rust codebase. It removes low-level byte-level tests for splice failure events and replaces them with a single cross-version test that actually loads a 0.2 node with seriali…

Cross-version serialization compatibility test addedRemoval of byte-level tests that could not detect real 0.2 mismatchesNo production code changes
80f2b44fby auto-pr-bot+95−2663 files
No security note in commit
Low 28 AI analysisMessage 98 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Document duplicate HTLC handling on revoked commitments

This commit only adds a code comment explaining an existing quirk: if a revoked old channel transaction contains two identical-looking payment forwards and the other side claims both, the software may only claim one upstream while letting …

Behavioral quirk in revoked-commitment HTLC resolution documentedDuplicate (payment_hash, amount) HTLCs can map to the same upstream sourcePotential missed upstream preimage claim on second identical HTLC
c5bd8b11by auto-pr-bot+19−01 file
Vendor flagged security relevance
Moderate 60 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Abort active splice RBF when prior candidate confirms

This commit fixes a state-handling bug in Lightning Dev Kit's splicing feature. When a user tries to speed up or replace a pending splice (an 'RBF' attempt) and the older splice transaction unexpectedly gets confirmed on-chain, the softwar…

State-conflict handling between confirmed splice candidate and active RBF negotiationStructured abort propagation through chain-event pathConditional abort based on holder signature progress to avoid unsafe cancellation
7587d2cdby Wilmer Paulino+623−424 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.

Security candidateFix missing user_channel_id in PaymentForwardedby Valentine Wallace · 0d6dcc91 · Feb 12, 2026 · 2 filesMessage 68 · AdequateLow 34Details
Commit message · Valentine Wallace

Fix missing user_channel_id in PaymentForwarded

Previously, if a forwarding node reloaded mid-HTLC-forward with a preimage in
the outbound edge monitor and the outbound edge channel still open, and
subsequently reclaimed the inbound HTLC backwards, the PaymentForwarded event
would be missing the next_user_channel_id field.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
boot or update path
AI analysis · Low 34/100

This commit fixes a bug where a forwarding Lightning node, after restarting mid-payment, could emit a 'PaymentForwarded' event that was missing the identifier (next_user_channel_id) of the next channel the payment went through. The fix ensures the identifier is correctly looked up from the still-open channel state during startup. It is a data-correctness bug, not a direct loss-of-funds vulnerability, but it could break downstream accounting or automation that relies on this field.

Security candidateRustfmt ChannelManager::internal_tx_signaturesby Wilmer Paulino · 146f29a9 · Feb 12, 2026 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Wilmer Paulino

Rustfmt ChannelManager::internal_tx_signatures

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit is purely a code-formatting cleanup. It removes a manual 'do not format' marker from one function and lets the Rustfmt tool reformat the code. No logic, behavior, or security properties of the software were changed.

Security candidateAccept blinded paths built by a phantom node participantby Matt Corallo · c10a0af6 · Feb 11, 2026 · 8 filesMessage 85 · StrongLow 37Details
Commit message · Matt Corallo

Accept blinded paths built by a phantom node participant

In the next commit we'll add support for building a BOLT 12 offer
which can be paid to any one of a number of participant nodes. Here
we add support for validating blinded paths as coming from one of
the participating nodes by deriving a new key as a part of the
`ExpandedKey`.

We keep this separate from the existing `ReceiveAuthKey` which is
node-specific to ensure that we only allow this key to be used for
blinded payment paths and contexts in `invoice_request` messages.
This ensures that normal onion messages are still tied to specific
nodes.

Note that we will not yet use the blinded payment path phantom
support which requires additional future work. However, allowing
them to be authenticated in a phantom configuration should allow
for compatibility across versions once the building logic lands.

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
cryptography-sensitive path
AI analysis · Low 37/100

This commit prepares the Lightning Dev Kit (LDK) to support a new 'phantom node' feature for BOLT 12 offers. It changes how encrypted control data in blinded payment paths and onion messages is authenticated: instead of checking one extra node-specific key, it now checks two keys (the existing node-specific key and a new shared phantom-node key). The commit itself does not enable the actual phantom-node building logic yet, but it adds the cryptographic plumbing so that future versions can authenticate blinded paths from any participant in a phantom-node setup while still keeping normal onion messages tied to a specific node.

Security candidateAdd an `ExpandedKey` key for phantom blinded path authenticationby Matt Corallo · 14a47405 · Feb 11, 2026 · 2 filesMessage 78 · AdequateInformational 19Details
Commit message · Matt Corallo

Add an `ExpandedKey` key for phantom blinded path authentication

In the coming commits we'll add support for building a blinded path
which can be received to any one of several nodes in a "phantom"
configuration (terminology we retain from BOLT 11 though there are
no longer any phantom nodes in the paths).

Here we adda new key in `ExpandedKey` which we can use to
authenticate blinded paths as coming from a phantom node
participant.

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
access controlcryptography-sensitive path
AI analysis · Informational 19/100

This commit adds a seventh cryptographic key to an existing key-expansion routine. The new key is intended for a future feature where multiple nodes can share a 'phantom' blinded payment path. The change itself only extends the HKDF output and stores the extra key; it does not introduce a vulnerability or fix one.

Security candidateTrivial: use full path in test macrosby Valentine Wallace · eb31aeb1 · Feb 10, 2026 · 1 fileMessage 70 · AdequateInformational 15Details
Commit message · Valentine Wallace

Trivial: use full path in test macros

Useful when using these macros in lightning-tests/upgrade_downgrade_tests

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
update trust
AI analysis · Informational 15/100

This is a minor code cleanup change inside test helper macros. It replaces short internal names like `_reload_node` with fully qualified paths such as `$crate::ln::functional_test_utils::_reload_node`. This only affects how test macros resolve symbols when reused in other test crates; it does not change runtime behavior, user-facing APIs, or any security-sensitive logic.

Security candidateAdd a read closure to the `legacy` TLV variantby Jeffrey Czyz · e71ad81a · Feb 7, 2026 · 5 filesMessage 73 · AdequateInformational 18Details
Commit message · Jeffrey Czyz

Add a read closure to the `legacy` TLV variant

Update the `legacy` TLV read/write variant signature from
`(legacy, $fieldty, $write)` to `(legacy, $fieldty, $read, $write)`,
adding a read closure parameter matching the `custom` variant's
signature.

The read closure is applied in `_check_missing_tlv!` after all TLV
fields are read but before `static_value` fields consume legacy
values. This preserves backwards compatibility with `static_value` and
`default_value` expressions that reference legacy field variables as
`Option<$fieldty>` during TLV reading.

The read closure signature differs from `custom`:
`FnOnce(Option<&$fieldty>) -> Result<(), DecodeError>`. All existing
usage sites return `Ok(())` as their read closure (no-op).

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

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 18/100

This commit is a small, internal refactoring of a Rust serialization macro used in the Lightning Dev Kit. It adds an optional read-time callback to the 'legacy' type-length-value (TLV) field variant so future code can validate or reject decoded legacy values. All existing usage sites pass a no-op callback that always succeeds, so the change does not alter current behavior. It is a defensive/extensibility improvement, not a fix for an active security bug.

Security candidateFix thread starvation in test_single_channel_multiple_mppby Jeffrey Czyz · 1829dc9f · Feb 6, 2026 · 1 fileMessage 83 · StrongInformational 16Details
Commit message · Jeffrey Czyz

Fix thread starvation in test_single_channel_multiple_mpp

The busy-wait loop polling for PaymentClaimed events had no yield,
causing it to continuously acquire ChannelManager locks via
get_and_clear_pending_events(). This could starve the claim_funds
thread of lock access, preventing it from ever queuing the event.
Add a yield_now() call matching the pattern used by the other two
spin loops in this test.

Co-Authored-By: Claude Opus 4.6 <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
boot or update path
AI analysis · Informational 16/100

This is a fix inside a single test function. The test had a tight loop that repeatedly checked for events without ever pausing, which could monopolize a lock and prevent another thread in the same test from making progress. The change adds a brief yield so the other thread can run. It only affects test code, not production code, and has no security impact on real users.

Security candidateAdd `counterparty_node_id` to `TrackedSpendableOutput`by Elias Rohrer · da9ddd2f · Feb 6, 2026 · 2 filesMessage 63 · AdequateInformational 18Details
Commit message · Elias Rohrer

Add `counterparty_node_id` to `TrackedSpendableOutput`

This adds an optional `counterparty_node_id` field to
`TrackedSpendableOutput` and updates the `track_spendable_outputs`
method signatures on both `OutputSweeper` and `OutputSweeperSync` to
accept this new parameter.

The field uses TLV type 3 (odd) for backwards compatibility. When
reading outputs tracked with LDK 0.2 and prior, this field will be
`None`.

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

63/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Informational 18/100

This commit is a routine API and data-model enhancement. It adds an optional 'counterparty_node_id' field to the internal record that tracks spendable Lightning outputs, and threads that value through the sweeper methods. The field is optional and backward-compatible, so older stored records still load. There is no indication this fixes a security bug or introduces a vulnerability.

Security candidateMake get_latest_mon_update_id a helper on TestChainMonitorby Wilmer Paulino · 60b5d66e · Feb 6, 2026 · 2 filesMessage 50 · ThinInformational 15Details
Commit message · Wilmer Paulino

Make get_latest_mon_update_id a helper on TestChainMonitor

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

This commit is a simple code cleanup in the project's test utilities. It moves a small helper function that reads the latest monitor update ID from one test file into a shared test helper struct, so other tests can call it more cleanly. There is no change to production code, no security fix, and no behavior change.

Security candidateRename test default channel configby elnosh · 306eea72 · Feb 5, 2026 · 18 filesMessage 78 · AdequateInformational 15Details
Commit message · elnosh

Rename test default channel config

Now that anchor channels are the default,
rename `test_default_anchors_channel_config` to
`test_default_channel_config` and the
previous default to legacy.

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 is a pure test-code refactoring. It renames the default test channel configuration because anchor channels became the production default, and updates many tests to explicitly use a new 'legacy' configuration where they previously relied on the old default. There is no change to production code, no bug fix, and no security-relevant behavior change.

Security candidateRemove automatic channel acceptanceby elnosh · cad035db · Feb 5, 2026 · 26 filesMessage 58 · ThinLow 36Details
Commit message · elnosh

Remove automatic channel acceptance

Removes the `manually_accept_inbound_channels` config
option. In upcoming commit we will default to anchor
channels which requires users checking if they have
enough onchain funds to cover fees in case of a force
close. Hence, we move to always require users to
manually accept inbound channels.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathboot or update path
AI analysis · Low 36/100

This commit removes the automatic acceptance of incoming Lightning channels in the LDK library. Previously, users could set a flag to automatically accept inbound channel requests. Now, every inbound channel request must be explicitly approved by the user through an OpenChannelRequest event. This is a deliberate design change to ensure users verify they have enough on-chain funds to cover fees, especially with upcoming anchor channel defaults. It is not a fix for an active vulnerability, but it prevents accidental or unsafe channel acceptance.

Security candidateSupport async signing of interactive-tx initial commitment signaturesby Wilmer Paulino · ee742092 · Feb 5, 2026 · 3 filesMessage 73 · AdequateLow 27Details
Commit message · Wilmer Paulino

Support async signing of interactive-tx initial commitment signatures

This commit allows for an async signer to immediately return upon a call
to `EcdsaChannelSigner::sign_counterparty_commitment` for the initial
commitment signatures of an interactively funded transaction, such that
they can call back in via `ChannelManager::signer_unblocked` once the
signatures are ready. This is done for both splices and dual-funded
channels, though note that the latter still require more work to be
integrated. Since `tx_signatures` must be sent only after exchanging
`commitment_signed`, we make sure to hold them back if they're ready to
be sent until our `commitment_signed` is also ready.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 27/100

This commit adds support for asynchronous (delayed) signing when opening or splicing Lightning channels that use the newer interactive-funding protocol. Previously, if a hardware or remote signer was not ready to produce the initial commitment signature, the code either did not support the delay or could accidentally send transaction signatures before the commitment signature was ready. The change holds back the transaction-signature message until the commitment signature is available, and adds a regression test for splicing. It is a protocol-correctness and robustness improvement rather than a fix for an active exploit.

Security candidatefuzz: fix ChaCha20 encrypt_single_block to preserve databy Joost Jager · dde2c822 · Feb 5, 2026 · 1 fileMessage 83 · StrongLow 27Details
Commit message · Joost Jager

fuzz: fix ChaCha20 encrypt_single_block to preserve data

The fuzzing ChaCha20 implementation's encrypt_single_block was not
copying src to dest, causing encrypted data to be lost (dest remained
zeros). This broke payment flows where metadata is encrypted into
payment_secret - the receiver would decrypt zeros and detect the wrong
payment method (LdkPaymentHash instead of UserPaymentHash), causing
payments to fail with "mismatching preimage".

Fix by making encrypt_single_block copy src to dest (identity
encryption), matching the behavior of the process() method.

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
fuzzing or regression evidencecryptography-sensitive path
AI analysis · Low 27/100

This commit fixes a bug in a fuzzing-only (test-only) fake version of the ChaCha20 encryption code. The fake encryptor accidentally left the output as all zeros instead of copying the input, which caused simulated Lightning payments to fail during testing. The fix makes the test fake copy input to output unchanged. This is not a real cryptographic vulnerability and does not affect production code.

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.

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.

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.

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.

Security candidateIntroduce custom TLVs in `pay_for_bolt11_invoice`by shaavan · 6b20feee · Jan 30, 2026 · 6 filesMessage 73 · AdequateInformational 23Details
Commit message · shaavan

Introduce custom TLVs in `pay_for_bolt11_invoice`

Custom TLVs let the payer attach arbitrary data to the onion packet,
enabling everything from richer metadata to custom authentication on
the payee's side.

Until now, this flexibility existed only through `send_payment`. The
simpler `pay_for_bolt11_invoice` API offered no way to pass custom
TLVs, limiting its usefulness in flows that rely on additional context.

This commit adds custom TLV support to `pay_for_bolt11_invoice`,
bringing it to feature parity.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
access control
AI analysis · Informational 23/100

This commit is a routine API enhancement for the Lightning Dev Kit's rust-lightning library. It adds the ability for users to include custom data (called 'custom TLVs') when paying a BOLT11 invoice through the simpler `pay_for_bolt11_invoice` API, matching a capability already available in the more advanced `send_payment` API. The change mostly refactors how optional payment arguments are passed, grouping route settings, retry settings, and the new custom TLVs into a single `OptionalBolt11PaymentParams` struct. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a feature addition for flexibility.

Security candidateDrop Deref indirection for EntropySourceby Valentine Wallace · 32e6e100 · Jan 30, 2026 · 31 filesMessage 68 · AdequateInformational 19Details
Commit message · Valentine Wallace

Drop Deref indirection for EntropySource

Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

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
entropy or randomnesscryptography-sensitive pathsigning or wallet path
AI analysis · Informational 19/100

This commit is a large internal cleanup in the rust-lightning codebase. It removes an extra layer of pointer indirection (the Deref trait) from how randomness sources are passed around, replacing it with a direct EntropySource trait bound. The change simplifies type signatures and reduces boilerplate but does not appear to fix a security bug or introduce a new vulnerability. A blanket implementation of EntropySource for any type that dereferences to an EntropySource is added to preserve backward compatibility with existing callers.

Security candidateDrop Deref indirection for NodeSignerby Valentine Wallace · fb2759e8 · Jan 30, 2026 · 17 filesMessage 68 · AdequateInformational 18Details
Commit message · Valentine Wallace

Drop Deref indirection for NodeSigner

Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

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
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 18/100

This commit is a code cleanup change in the Lightning Dev Kit Rust library. It removes an extra layer of pointer-like wrapping (called Deref indirection) around the NodeSigner type, which is responsible for node-level cryptographic operations like signing messages and deriving keys. The change simplifies type signatures across many files but does not alter what the code actually does or fix any security bug. The commit message explicitly states the goal is to reduce generics and verbosity while providing equivalent behavior.

Security candidateSupport funding_transaction_signed for unfunded dual-funded channelsby Wilmer Paulino · be67c67f · Jan 29, 2026 · 2 filesMessage 85 · StrongLow 32Details
Commit message · Wilmer Paulino

Support funding_transaction_signed for unfunded dual-funded channels

Now that we require users to first call
`ChannelManager::funding_transaction_signed` before releasing any
signatures, it's possible that it is called before we receive the
initial commitment signed from our counterparty, which would transition
the channel to funded. Because of this, we need to support the API call
while the channel is still in the unfunded phase.

Note that this commit is mostly a code move of
`FundedChannel::funding_transaction_signed` to
`Channel::funding_transaction_signed` that doesn't alter the signing
logic.

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 boundary
AI analysis · Low 32/100

This commit moves the handling of funding-transaction signatures so it can be called earlier, while a dual-funded Lightning channel is still unfunded. Previously the API required the channel to already be in a funded state, which could fail if a user signed before the counterparty's first commitment arrived. The change is described by the authors as mostly a code move that does not alter the actual signing logic.

Security candidateRework ChannelManager::funding_transaction_signedby Wilmer Paulino · 83b2d3ec · Jan 29, 2026 · 6 filesMessage 58 · ThinLow 33Details
Commit message · Wilmer Paulino

Rework ChannelManager::funding_transaction_signed

Previously, we'd emit a FundingTransactionReadyForSigning event once the
initial commitment_signed is exchanged for a splicing/dual-funding
attempt and require users to call back with their signed inputs using
ChannelManager::funding_transaction_signed. While this approach worked
in practice, it prevents us from abandoning a splice if we cannot or no
longer wish to sign as the splice has already been committed to by this
point.

This commit reworks the API such that this is now possible. After
exchanging tx_complete, we will no longer immediately send our initial
commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call
back before releasing both our initial commitment_signed and our
tx_signatures. As a result, the event is now persisted, as there is only
one possible path in which it is generated. Note that we continue to
only emit the event if a local contribution to negotiated transaction
was made.

Future work will expose a cancellation API such that we can abandon
splice attempts safely (we can just force close the channel with
dual-funding).

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Low 33/100

This commit reorders the splicing/dual-funding handshake in LDK so that the node does not send its initial commitment signature until after the user has had a chance to sign the funding transaction. Previously, the commitment was sent first, which locked the node into the splice even if the user could not or did not want to sign. The change also makes the 'ready to sign' event persistent across restarts and adds a forward-compatibility note that downgrading while a splice is pending is not supported with async monitor updates. It is a protocol-flow hardening change, not a fix for an active exploit.

Security candidatefuzz: convert send helpers to closures with node indicesby Joost Jager · 0a48663f · Jan 22, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Joost Jager

fuzz: convert send helpers to closures with node indices

Replace the standalone `send_noret` and `send_hop_noret` functions with
closures defined inside the main loop. This allows them to capture the
`nodes` array and use simple node indices (0, 1, 2) instead of passing
`&nodes[x]` references at each call site.

The `send_payment` and `send_hop_payment` functions are modified to take
pre-computed `PaymentSecret`, `PaymentHash`, and `PaymentId` parameters,
with the closures handling the credential generation. This centralizes
where `PaymentId` is constructed, which will make it easier to add
payment tracking in a future change.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Matt Corallo <git@bluematt.me>

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
fuzzing or regression evidencecredential or privilege state
AI analysis · Informational 15/100

This commit is a code cleanup inside a fuzzing test file. It converts helper functions into closures and changes how payment identifiers are passed around. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix or vulnerability.

Security candidatenet-tokio: add `fn tor_connect_outbound`by Leo Nash · 105521ff · Jan 20, 2026 · 4 filesMessage 73 · AdequateInformational 17Details
Commit message · Leo Nash

net-tokio: add `fn tor_connect_outbound`

Routes `fn connect_outbound` through Tor.

This uses a unique stream isolation parameter for each connection: the
hex-encoding of 32 random bytes sourced from the `entropy_source`
parameter.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomness
AI analysis · Informational 17/100

This commit adds a new optional feature to rust-lightning that lets the networking code connect to peers through the Tor anonymity network. It is a feature addition, not a fix for a known security bug. The code uses fresh random data for each connection to keep Tor streams isolated, which is a privacy-conscious design choice. There is no indication in the commit that it addresses an active vulnerability or that a security issue was disclosed.