LDK

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 29 minutes ago

Informational 19 AI analysisMessage 81 · Strong

1 week, 1 day ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

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

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

1 week, 2 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

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

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

1 week, 2 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

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

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

1 week, 5 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

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

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

2 weeks ago

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

2 weeks, 1 day ago

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

2 weeks, 1 day ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Run the CI fuzz job on the stable toolchain

21c4ed2bby auto-pr-bot+3−32 files

No security note in commit

Open full analysis →Source commit ↗

Informational 19 AI analysisMessage 91 · Strong

2 weeks, 1 day ago

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

2 weeks, 2 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fail commitment sig verification without counterparty params

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

2 weeks, 2 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Clarify the commitment validation failure message

3284a006by auto-pr-bot+11−114 files

No security note in commit

Open full analysis →Source commit ↗

Moderate 61 AI analysisMessage 81 · Strong

2 weeks, 2 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

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

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

3 weeks ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

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

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

3 weeks ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Drop stale splice signature on disconnect

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

3 weeks, 2 days ago

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

3 weeks, 2 days ago

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

3 weeks, 2 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

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

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

4 weeks ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Support retired TLV fields in object-constructing macros

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

4 weeks, 1 day ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Replace splice failure wire tests with a 0.2 downgrade test

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

4 weeks, 1 day ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Document duplicate HTLC handling on revoked commitments

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

4 weeks, 2 days ago

LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Abort active splice RBF when prior candidate confirms

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

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

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

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

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

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

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

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.