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

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
1310commits · 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 1 hour, 2 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
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 ↗
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 ↗
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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source commit ↗
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
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.

AI review queuedMerge PR 'tx-sync: Parallelize esplora status queries' (#4913)by Matt Corallo · c303f515 · Sep 15, 2026 · 1 fileMessage 81 · StrongInformational 19Details
Commit message · Matt Corallo

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

from max/2026-08-20-upstream-parallelize-esplora into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4913
Reviewed-by: tnull <tnull@noreply.git.rust-bitcoin.org>
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 19/100

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 that it fixes a security vulnerability, but it does add a small amount of new error-handling logic and changes timing/ordering assumptions that could affect correctness if the server returns inconsistent data.

AI review queuedMerge PR 'Skip Electrum creator transaction downloads' (#4992)by Matt Corallo · c36e50cb · Sep 14, 2026 · 2 filesMessage 81 · StrongLow 30Details
Commit message · Matt Corallo

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

from 2026-09-electrum-skip-creator-download into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4992
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Low 30/100

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 never spend its own output. This wasted bandwidth and could leak slightly more information to the Electrum server than necessary. The patch adds a simple skip and a test that verifies no such download happens.

AI review queuedMerge PR 'Use preferred sPK of watched txn in electrum, not rand ones' (#4867)by tnull · bfe5ca89 · Sep 14, 2026 · 3 filesMessage 81 · StrongLow 44Details
Commit message · tnull

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

from 2026-08-spk-electrum into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4867
Reviewed-by: tnull <tnull@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Low 44/100

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 registering a transaction, and instead picked an arbitrary output from the transaction when querying Electrum servers. The patch now records and prefers the script pubkey(s) the caller actually registered, falling back to an arbitrary non-OP_RETURN output only when needed. This makes the wallet more robust against Electrum servers that may not index certain script types (like OP_RETURN), and against callers that register a transaction with an incorrect script pubkey. It is a hardening fix rather than a clear-cut vulnerability patch, because the commit message and diff do not describe a specific exploitable bug.

AI review queuedMerge PR 'Serialize transient Event variants; move persist decision into ChannelManager' (#4791)by Matt Corallo · a0d4632e · Sep 11, 2026 · 8 filesMessage 81 · StrongLow 33Details
Commit message · Matt Corallo

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

from 4741-serialize-all-events into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4791
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Low 33/100

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 worth keeping across restarts. The commit is a defensive correctness improvement: it makes event persistence more consistent and prevents stale or meaningless events from being replayed after a node restarts. It does not appear to fix an active exploit, but it removes a class of bugs where an event could be silently lost or mishandled around restarts.

Security candidateMerge PR 'Document that funding signing events can go stale' (#4960)by Matt Corallo · 26eecf2d · Sep 9, 2026 · 2 filesMessage 81 · StrongInformational 15Details
Commit message · Matt Corallo

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

from bot/4951-fundingtransactionreadyforsignin-fa0568 into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4960
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarymerge-commit duplicate discount
AI analysis · Informational 15/100

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 behavior was changed.

Security candidateDrop the honggfuzz version pin from the CI fuzz jobby auto-pr-bot · 4a1635ef · Sep 8, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · auto-pr-bot

Drop the honggfuzz version pin from the CI fuzz job

The pin only ever existed because the job ran on our MSRV toolchain while
honggfuzz's own MSRV had moved past it, so each honggfuzz release broke
the job until someone picked an older version to install. With the job on
stable there is nothing left for the pin to guard: `cargo install
honggfuzz` and the `honggfuzz` 0.5 dependency the fuzz targets link
against both resolve to the current release, which is what we want to be
fuzzing with anyway.

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

Fixes #4968

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/issues/4968#issuecomment-445091

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
access controlfuzzing or regression evidence
AI analysis · Informational 15/100

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 protocol code, wallet logic, or any code that end users run in production.

AI review queuedRun the CI fuzz job on the stable toolchainby auto-pr-bot · 21c4ed2b · Sep 8, 2026 · 2 filesMessage 86 · StrongInformational 15Details
Commit message · auto-pr-bot

Run the CI fuzz job on the stable toolchain

@matt asked:

> Failing to build this time.
>
> ```
> error: cannot install package `honggfuzz 0.5.62`, it requires rustc 1.85 or newer, while the currently active rustc version is 1.75.0
> `honggfuzz 0.5.61` supports rustc 1.70
> ```
>
> @auto-pr-bot please fix.

The `fuzz` job doesn't compile anything we ship, it builds the fuzz
targets against `honggfuzz` and then runs them. That the targets build on
our MSRV is checked by the `fuzz_sanity` job, which compiles both fuzz
crates with 1.75 on every push, so there is nothing the `fuzz` job adds
by using the MSRV toolchain itself.

What it does add is a dependency on `honggfuzz` still supporting our
MSRV. It doesn't: 0.5.62 requires rustc 1.85, so the job can only install
progressively older releases of a tool we merely need to run, and each
`honggfuzz` MSRV bump breaks the job until someone moves the pin.

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

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/issues/4968

86/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
fuzzing or regression evidencesecond-pass: broader security terminology
AI analysis · Informational 15/100

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 issue with the honggfuzz fuzzing tool. It does not change any shipped code, user-facing behavior, or security-sensitive logic.

Security candidateExpose the dummy-hop tail constructor publiclyby auto-pr-bot · c5443353 · Sep 8, 2026 · 1 fileMessage 91 · StrongInformational 19Details
Commit message · auto-pr-bot

Expose the dummy-hop tail constructor publicly

@matt asked on the diff:

> @auto-pr-bot this and the remining fns in this impl block shouldn't be
> crate-public.

@matt asked on the diff:

> @auto-pr-bot this should be public.

`BlindedPaymentPath::new_with_dummy_hops` is public, but the `DummyTlvs` it
takes could only be built by hand, leaving external callers to rederive the
per-hop constraint chaining themselves. Expose the constructor that does it,
and document what the returned upstream constraints are for.

The entropy source is only unused under `cfg(test)`, so name the parameter
rather than leaving an underscore-prefixed one in the public signature.

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

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4501#issuecomment-445043
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4501#issuecomment-445044

91/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomnesssigning boundary
AI analysis · Informational 19/100

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 security bug. The function's behavior is unchanged; only its visibility and documentation were updated.

Security candidateFail commitment sig verification without counterparty paramsby auto-pr-bot · de7ecc2f · Sep 7, 2026 · 1 fileMessage 100 · StrongModerate 54Details
Commit message · auto-pr-bot

Fail commitment sig verification without counterparty params

@matt asked on the diff:

> @auto-pr-bot this example is adding nothing to public docs, please
> remove it.

@matt asked on the diff:

> Since this is now the "primary" error message we send to peers,
> @auto-pr-bot please change this to read "Received commitment sigs failed
> verification". Same for the version in `validate_commitment_signed`.

@matt asked on the diff:

> @auto-pr-bot just for extra belt-and-suspenders, can you add
> `debug_assert!(false);`, `log_error(...)` and a failure return if the
> `channel_transaction_parameters` is missing `counterparty_parameters`?
> Same for the similar code in `validate_commitment_signed`.

Verifying the counterparty's signatures on a holder commitment requires
their funding pubkey and selected contest delay, so with
`counterparty_parameters` unset we'd panic somewhere down in building the
commitment transaction. That should never happen, as we only accept
`commitment_signed` (initial or otherwise) once the counterparty's
parameters are known, but rather than risk a panic on a peer-driven path
we now log and close the channel. As on the other failure paths here, we
clear the funding outpoint for inbound channels first, so that we don't
broadcast a commitment for funding the counterparty may never publish.

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444803
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444937
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444942

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarydefensive validation
AI analysis · Moderate 54/100

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 it logs an error and closes the channel gracefully instead. The commit message says this situation should never happen in normal operation, so this is defensive hardening against a potential peer-triggered crash.

Security candidateClarify the commitment validation failure messageby auto-pr-bot · 3284a006 · Sep 7, 2026 · 4 filesMessage 100 · StrongInformational 15Details
Commit message · auto-pr-bot

Clarify the commitment validation failure message

@matt asked on the diff:

> @auto-pr-bot this example is adding nothing to public docs, please
> remove it.

@matt asked on the diff:

> Since this is now the "primary" error message we send to peers,
> @auto-pr-bot please change this to read "Received commitment sigs failed
> verification". Same for the version in `validate_commitment_signed`.

@matt asked on the diff:

> @auto-pr-bot just for extra belt-and-suspenders, can you add
> `debug_assert!(false);`, `log_error(...)` and a failure return if the
> `channel_transaction_parameters` is missing `counterparty_parameters`?
> Same for the similar code in `validate_commitment_signed`.

Now that no signature checking remains in channel, this error is what we
send our peer whenever the holder commitment they sent us fails to
validate - because their signatures don't verify, but also, e.g., because
the commitment has no outputs at all. Say so, rather than the vaguer
"Failed to validate our commitment", which reads as though the fault were
on our side.

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444803
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444937
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885#issuecomment-444942

100/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validation
AI analysis · Informational 15/100

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'. No code logic, signature checks, or security behavior is altered. It is a documentation/clarity improvement, not a security fix.

AI review queuedMerge PR 'Move holder commit sig checks to `InMemorySigner`' (#4885)by Matt Corallo · 83f5ba55 · Sep 7, 2026 · 24 filesMessage 81 · StrongModerate 61Details
Commit message · Matt Corallo

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

from 2026-08-signer-validates-commits into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4885
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
defensive validationsigning or wallet pathmerge-commit duplicate discountsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Moderate 61/100

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 done directly inside the channel state machine. Now, the signer itself is responsible for verifying those signatures. This is a security-relevant refactor: it makes the signer the authoritative place for validating signatures, which is important for users running LDK with external or hardware signers. The commit also adds tests that corrupt signatures to ensure invalid signatures are rejected. There is no direct evidence in the commit message or diff that this fixes a known exploitable vulnerability, but it strengthens the architecture so that custom signers cannot accidentally skip these checks.

Security candidateMerge PR 'Drop stale splice signature on disconnect' (#4954)by Matt Corallo · c9a77251 · Sep 2, 2026 · 2 filesMessage 86 · StrongLow 42Details
Commit message · Matt Corallo

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

from drop-stale-splice-sig-on-disconnect into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4954
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

86/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarymerge-commit duplicate discount
AI analysis · Low 42/100

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 reconnecting, which might let a peer apply an old splice state or confuse the channel re-establishment logic. The patch is small and adds a test showing the signature is dropped and no monitor update occurs at that point.

Security candidateDrop stale splice signature on disconnectby Wilmer Paulino · 71405b4b · Sep 2, 2026 · 2 filesMessage 73 · AdequateModerate 58Details
Commit message · Wilmer Paulino

Drop stale splice signature on disconnect

An initial splice `commitment_signed` can be buffered while waiting for
the user to provide funding signatures. While this was dropped after a
node restart as it's only intended to be live & in-memory state, it was
not dropped after a disconnection. This could lead to a duplicate
message being received after the negotiation has already completed,
leading to a force close.

This was discovered by the `chanmon_consistency` fuzzer via:

06a4721e111911191119401119407019bd411a1f0d91401119111911194070bec111b70e5df11611ffffffffffffffff411f0aa97210b6ff21b6ff5ba2ffad10

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 boundaryfuzzing or regression evidence
AI analysis · Moderate 58/100

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 reconnected and finished the splice, that old buffered signature could be processed again, triggering a safety shutdown (force close) of the channel. The patch now clears that buffered signature when the connection drops, just like it was already cleared on restart.

Security candidateMerge PR 'offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice' (#4942)by Matt Corallo · a476cf92 · Aug 31, 2026 · 3 filesMessage 81 · StrongInformational 20Details
Commit message · Matt Corallo

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

from offer-key-can-sign-invoice into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4942
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 20/100

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.

Security candidateoffers: rename matches_invoice_signing_pubkey to key_can_sign_invoiceby Vincenzo Palazzo · 388187ca · Aug 31, 2026 · 3 filesMessage 73 · AdequateInformational 15Details
Commit message · Vincenzo Palazzo

offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice

Follow-up to #4884 addressing Matt's naming nit.

Co-authored-by: Cursor <cursoragent@cursor.com>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

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.

AI review queuedMerge PR 'offers: add Offer::permits_invoice_signed_by' (#4884)by Matt Corallo · 016af8f9 · Aug 31, 2026 · 5 filesMessage 81 · StrongInformational 18Details
Commit message · Matt Corallo

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

from lightning-payer-proof-offer-api into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4884
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 18/100

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 an existing internal validation function to reuse the same logic. There is no direct bug fix or security patch in the diff; it is an API addition with tests and a changelog entry.

AI review queuedSupport retired TLV fields in object-constructing macrosby Jeffrey Czyz · 6d7c2bda · Aug 26, 2026 · 2 filesMessage 85 · StrongLow 29Details
Commit message · Jeffrey Czyz

Support retired TLV fields in object-constructing macros

The retired field type was initially limited to manual
`write_tlv_fields!`/`read_tlv_fields!`-style implementations because the
macros which construct the deserialized object (`impl_ser_tlv_based!`,
the enum macros, and `impl_writeable_msg!`) emit a struct literal or
match pattern naming every field, and a retired field has no backing
struct field to name.

Extend the `lightning-macros` filters that already drop `legacy` fields
from those positions to also drop `retired` fields, and route
`impl_writeable_msg!`'s constructed literal through the same filter,
which it previously bypassed. This lets any TLV field list mark a
retired type number rather than falling back to a manual implementation
just to reserve one.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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
second-pass: broader security terminology
AI analysis · Low 29/100

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. The change itself is not a security bug fix; it is infrastructure that makes it easier to safely reserve obsolete TLV type numbers. There is no direct exploit here, but it helps prevent future protocol-versioning mistakes.

Security candidateReplace splice failure wire tests with a 0.2 downgrade testby auto-pr-bot · 80f2b44f · Aug 26, 2026 · 3 filesMessage 91 · StrongInformational 17Details
Commit message · auto-pr-bot

Replace splice failure wire tests with a 0.2 downgrade test

@matt said:

> Feel free to squash.

@jkczyz said:

> Squashed

@matt asked:

> This is at least straightforward now. There's a lot of tests checking
> low-level serialization which I don't really buy as a way to test the
> 0.2 deserialization logic - if we want to test the 0.2 deserialization
> logic we need to actually use the 0.2 deserialization logic, not a copy
> of it using 0.3 types. Gonna go ahead and land this since the code is
> right and we need to get it over the line, but @auto-pr-bot can you
> replace the tests in events/mod.rs with tests in `lightning-tests` that
> use the 0.2 code to check the events? There's already some tests that do
> this in the PR so check that you're not duplicating coverage first.

@matt asked on the diff:

> I don't see the point of any of these tests. They feel like tests for
> tests sake rather than actually testing something meaningful.
> @auto-pr-bot

@matt asked on the diff:

> Same here. If we want to test upgrade/downgrade semantics the correct
> way is a `lightning-tests` multi-version test, not a test that checks
> the "wire" encoding of an `Event`.
>
> @auto-pr-bot

@matt asked on the diff:

> Yes, this is implied by the lack of implementation lol there's no need
> to document this @auto-pr-bot.

The `events` tests removed here built an `Event` by hand, wrote it, and
asserted on the bytes, or read bytes assembled to look like something
0.2 would have written. Either way they only ever exercised current
code's reader and writer, so they could not have caught a mismatch with
what 0.2 actually does -- the thing the encoding changes were about.
Checking that requires running 0.2's serialization, which is what
`lightning-tests` is for.

The reloads there already cover a splice failure releasing its whole
contribution, both for a negotiation aborted in flight and for one still
queued on quiescence, along with the `DiscardFunding` event type 0.2 has
to skip. What none of them cover is a contribution which reuses inputs
or outputs already committed to a pending splice: that is refused with
only the parts unique to it released, and those are what a downgraded
0.2 node has to learn about via `SpliceFailed`, since the
`DiscardFunding` carrying them is written under an event type it
ignores. Add a reload of a manager written with such a partial failure
pending, asserting 0.2 surfaces exactly the released output.

`FundingContribution::new_for_test` existed only to build contributions
for the removed tests, so it goes with them, as does the
`FailedSpliceContribution` note about having no serialization of its
own -- that is implied by the lack of any `Writeable`/`Readable`
implementation, so it tells callers nothing they need.

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

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442672
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442657
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442658
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4920#issuecomment-442669

91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
update trust
AI analysis · Informational 17/100

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 serialized state from current code. There is no change to production logic, no fix for an active vulnerability, and no new attack surface. The work is defensive testing to ensure future serialization changes stay compatible with older LDK versions.

Security candidateDocument duplicate HTLC handling on revoked commitmentsby auto-pr-bot · c5bd8b11 · Aug 25, 2026 · 1 fileMessage 98 · StrongLow 28Details
Commit message · auto-pr-bot

Document duplicate HTLC handling on revoked commitments

@matt said:

> Bitcoin red team flagged that if there's two HTLCs with identical
> `(payment_hash, amount)`s on a channel and the counterparty broadcasts a
> revoked commitment tx and then claims both we will only propagate the
> claim backwards on one of the two. This is, of course, not a
> "vulnerability" because we'll still get our money by taking our
> counterparty's funds via the revocation path, but it might be nice to
> claim both HTLCs cause, why not, free money.
>
> @auto-pr-bot can you do this? try to keep the code change small and
> contained, if its too big I'll respond in review and we'll switch to
> just leaving a comment instead.

@matt said:

> @auto-pr-bot try again.

@matt asked:

> Turned out to be way too much code. @auto-pr-bot can you instead just
> add a comment?

HTLC outputs on a revoked counterparty commitment transaction don't come
with an `HTLCSource`, so when one is spent we search the counterparty's
non-revoked commitment transactions for an HTLC with a matching
direction, payment hash and value. If a channel had two HTLCs which
share both a payment hash and a value, spends of either output match the
same first source.

Thus, if the counterparty claims both outputs with the preimage, we
propagate only one fulfillment upstream and fail the second upstream
HTLC, even though each matching upstream HTLC is independently claimable
once we have the preimage. Because the counterparty broadcasted a
revoked commitment we still recover the channel balance via the
revocation path, so this doesn't leave us out of pocket, but it does
give up an upstream claim we were entitled to.

Resolving the outputs against distinct sources means resolving every
matching source when a spend reveals a preimage and deterministically
matching duplicate outputs to sources otherwise, which is more than the
lookup here can do. Describe the behavior in a comment instead so the
next reader doesn't have to rediscover it.

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

Fixes #4904

Requested-by: @matt
Link: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/issues/4904#issuecomment-442538

98/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
explicit security language
AI analysis · Low 28/100

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 the other fail. The commit itself does not change behavior, and the comment notes the user still recovers funds through the revocation penalty path, so no money is lost. It is a documentation-only change for a known, low-consequence edge case.

Security candidateAbort active splice RBF when prior candidate confirmsby Wilmer Paulino · 7587d2cd · Aug 25, 2026 · 4 filesMessage 73 · AdequateModerate 60Details
Commit message · Wilmer Paulino

Abort active splice RBF when prior candidate confirms

Rejecting new RBF attempts after confirmation does not cover an RBF
negotiation which began while the prior candidate was still unconfirmed.
When an earlier candidate confirms, inspect any active RBF and reset it
if is still safe and holder funding signatures have not been provided.
Propagate a structured abort through the chain-event path so
ChannelManager can notify a connected peer, fail any local contribution,
and release holding-cell updates. If signing has advanced too far,
retain the RBF until it completes, as splice promotion is blocked on its
completion.

Co-Authored-By: Codex <noreply@openai.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 · Moderate 60/100

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 software could get stuck with two conflicting splice attempts active. The patch detects that situation, safely cancels the newer RBF attempt, tells the peer, returns any locked-up funds, and resumes normal channel operation. If signing has already progressed too far, it keeps the RBF alive until it finishes to avoid unsafe cancellation.

Security candidateClear pending signer state when aborting splice RBFby Wilmer Paulino · cb81afaa · Aug 25, 2026 · 2 filesMessage 78 · AdequateLow 44Details
Commit message · Wilmer Paulino

Clear pending signer state when aborting splice RBF

If an asynchronous signer blocks the initial commitment signature for an
RBF, aborting the `AwaitingSignatures` negotiation discards its signing
session but previously left `signer_pending_funding` set. A later
`signer_unblocked` callback would then retry signing funding state which
no longer exists.

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

This commit fixes a state-cleanup bug in Lightning Dev Kit's splice RBF (fee-bump) flow. When a user aborts a splice while waiting for an asynchronous hardware signer, the code now properly clears an internal 'signer still has pending funding work' flag. Before the fix, that flag could remain set, causing a later 'signer is ready' callback to try to continue signing a funding transaction that no longer exists. The patch is small and defensive; the main risk is a confused internal state leading to unexpected retries or errors, not direct theft of funds.

Security candidateIgnore messages from aborted splice negotiationsby Wilmer Paulino · 76791c85 · Aug 25, 2026 · 2 filesMessage 73 · AdequateLow 37Details
Commit message · Wilmer Paulino

Ignore messages from aborted splice negotiations

An aborted splice negotiation exits quiescence before the `tx_abort`
exchange has fully completed. An in-flight `interactive-tx` or
`commitment_signed` message for the discarded negotiation may therefore
arrive after the splice state has been removed, and treating them as
active-protocol violations can disconnect unnecessarily.

Ignore `interactive-tx` messages once the channel is no longer
quiescent, while retaining a warning disconnect for unexpected messages
received during quiescence. Check a single `commitment_signed` message's
funding txid before enforcing batch delivery so a signature for
discarded funding is ignored.

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 · Low 37/100

This patch fixes a bug where a Lightning node could unnecessarily disconnect from a peer after a splice negotiation was aborted. When both sides agree to stop a splice, some related messages can still be in flight. Previously, those late messages were treated as protocol violations and caused a disconnect. Now the node ignores the stale messages instead, keeping the channel open. There is no direct evidence this was exploitable to steal funds, but unnecessary disconnects can hurt reliability.

Security candidateDisconnect on overlapping splice RBF negotiationby Wilmer Paulino · d6e24380 · Aug 25, 2026 · 3 filesMessage 78 · AdequateLow 45Details
Commit message · Wilmer Paulino

Disconnect on overlapping splice RBF negotiation

An inbound `tx_init_rbf` cannot identify a separate negotiation while
another funding negotiation is active. Sending `tx_abort` would
ambiguously abort the active negotiation and exit quiescence while
retaining its protocol state.

Return `WarnAndDisconnect` instead, preserving an `AwaitingSignatures`
negotiation for resumption across the disconnect rather than treating
the duplicate request as an abort. Remove the now-unused
NegotiationInProgress abort reason and update the existing
simultaneous-RBF regression coverage accordingly.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Low 45/100

This change fixes a protocol edge case in Lightning splicing where receiving a second overlapping RBF (fee-bump) request during an active funding negotiation could accidentally abort the wrong negotiation. Instead of sending tx_abort, which would ambiguously cancel the ongoing negotiation, the node now disconnects with a warning and keeps the existing negotiation state so it can resume after reconnecting. This prevents a remote peer from potentially disrupting an in-progress splice/RBF by sending a conflicting request.

Security candidateAdd cross-version tests for queued splice failure eventsby Jeffrey Czyz · 04252a94 · Aug 24, 2026 · 1 fileMessage 83 · StrongInformational 22Details
Commit message · Jeffrey Czyz

Add cross-version tests for queued splice failure events

A ChannelManager written with a splice contribution still queued
waiting on quiescence embeds synthesized failure events. Verify that a
downgraded 0.2 node reads such a manager and surfaces the failure as
its own SpliceFailed event carrying the contributed outputs, and that
a manager written by 0.2 with a queued splice -- which 0.2 persisted
in a legacy form current versions do not read -- loads with the queued
intent dropped and no events.

Co-Authored-By: Claude Fable 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
update trust
AI analysis · Informational 22/100

This commit only adds new regression tests for upgrading and downgrading Lightning node state across software versions. It does not change any production code. The tests verify that a splice contribution stuck waiting for network quietness is handled safely when moving between LDK 0.2 and current versions: an older 0.2 node reading newer state gets a failure event so the user can reclaim funds, while a newer node reading an older 0.2 state simply drops the stale queued splice with no harmful effects. There is no vulnerability being introduced or fixed here.

Security candidateWrite SpliceNegotiationFailed contributions for 0.2by Jeffrey Czyz · 88ed3f41 · Aug 21, 2026 · 8 filesMessage 93 · StrongLow 33Details
Commit message · Jeffrey Czyz

Write SpliceNegotiationFailed contributions for 0.2

When downgrading to 0.2 with a splice negotiation pending, the
synthesized `Event::DiscardFunding` containing the contribution is
ignored (see previous commit), leaving a 0.2 user without the set of
UTXOs freed by the abandoned negotiation.

0.2 read those UTXOs from the `contributed_inputs` and
`contributed_outputs` fields of `Event::SpliceFailed`, which it wrote
at TLV types 11 and 13 of event type 52. Write the inputs and outputs
released by the failure there too -- excluding any still committed to
an existing splice attempt -- so a downgraded node surfaces the same
event 0.2 would have written itself.

To that end, the event's `contribution` field is now an
`Option<FailedSpliceContribution>`, which holds the released inputs and
outputs alongside the `FundingContribution` available for retry. The
released inputs and outputs are also read back so that they survive
re-serialization.

Note that this makes a `ChannelManager` written with a splice failure
event pending unreadable by v0.3.0-beta1, which used those TLV types
for other fields.

Completes the fix for #4919.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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

This commit fixes a backward-compatibility bug in the Lightning Dev Kit (LDK) when a user downgrades from a newer version to version 0.2 while a splice negotiation is in progress. Without the fix, the newer version would generate an event telling the wallet to discard freed UTXOs, but version 0.2 could not understand that event, so those coins would appear stuck or lost to the downgraded node. The patch makes the newer version also write the freed UTXOs in the older event format that 0.2 understands, so the downgraded node surfaces the same information. It is a compatibility/data-loss fix, not a remote-exploitable vulnerability.