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

Lower-priorityMerge PR 'Fix linting CI' (#4984)by Matt Corallo · d9f73d7c · Sep 9, 2026 · 1 fileMessage 76 · AdequateTriage 0Details
Commit message · Matt Corallo

Merge PR 'Fix linting CI' (#4984)

from 2026-09-ci-fix into main

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

76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
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.

Lower-priorityFix linting CIby Matt Corallo · 0a2651f5 · Sep 9, 2026 · 1 fileMessage 50 · ThinTriage 0Details
Commit message · Matt Corallo

Fix linting CI

due to unused test fn

50/100 · ThinMessage clarity
✓ Subject identifies a change✓ Explains rationale or failure mode✓ Mentions testing or verification! No meaningful explanatory body
Lower-priorityMerge PR 'Abandon queued quiescent action on incoming shutdown after sending stfu' (#4974)by Matt Corallo · 474bc32c · Sep 9, 2026 · 4 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Abandon queued quiescent action on incoming shutdown after sending stfu' (#4974)

from stfu-shutdown-reconnect-loop into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4974
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
merge-commit duplicate discount
Lower-priorityMerge PR 'Don't archive un-advanced monitors with pending events' (#4983)by Matt Corallo · 1a122fd1 · Sep 9, 2026 · 2 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Don't archive un-advanced monitors with pending events' (#4983)

from 2026-09-dont-archive-mon-w-evs into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4983
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
merge-commit duplicate discount
Lower-priorityAdd release notes for 0.2.6by Matt Corallo · 17bf9ef5 · Sep 9, 2026 · 2 filesMessage 60 · AdequateTriage 0Details
Commit message · Matt Corallo

Add release notes for 0.2.6

Forward port of 1a987b4e93ec01558cabf41ba8177a298734f009

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
documentation-only discount
Lower-priorityMerge PR 'fuzz resource manager' (#4962)by Matt Corallo · bf158576 · Sep 9, 2026 · 8 filesMessage 86 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'fuzz resource manager' (#4962)

from resource-mgr-fuzz-test into main

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

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 evidencemerge-commit duplicate discount
Lower-priorityMerge PR 'reject open_channel with both anchors and zero fee set' (#4976)by Matt Corallo · c41dd894 · Sep 9, 2026 · 2 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'reject open_channel with both anchors and zero fee set' (#4976)

from reject-invalid-open-channel into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4976
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
merge-commit duplicate discount
Lower-priorityMerge PR 'Pin honggfuzz on a stable-toolchain fuzz CI job' (#4978)by Matt Corallo · 512a7269 · Sep 8, 2026 · 6 filesMessage 91 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Pin honggfuzz on a stable-toolchain fuzz CI job' (#4978)

from bot/4968-fuzz-is-failing-again-a9f6b5 into main

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

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
fuzzing or regression evidencemerge-commit duplicate discount
Lower-priorityFix test callsites left broken by the dummy-hop mergeby auto-pr-bot · 828336d4 · Sep 8, 2026 · 3 filesMessage 100 · StrongTriage 5Details
Commit message · auto-pr-bot

Fix test callsites left broken by the dummy-hop merge

@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 dummy-hop merge (ac8b6b99c, #4501) resolved textually but not
semantically. While that branch was open, main gained the
`Bolt12RefundContext::invoice_request` field and two more callers of
`claim_bolt12_payment`, and the branch meanwhile added refund contexts
without that field and dropped the no-fee `claim_bolt12_payment` wrapper in
favour of the fee-aware one. The result is that `lightning`'s test build does
not compile at that merge, so nothing in the crate can be tested.

Fill in the missing field and pass the extra-fee expectation at the two new
`claim_bolt12_payment` callsites, which pay a single-hop offer over the same
realistic dummy hops the sibling offer tests already charge 50 msat for.

`pay_for_bolt12_invoice_partial_amount{,_multi_payer}` are in the same
position: they predate dummy hops charging anything, so their expected HTLC
and claimable amounts are now short by the dummy-hop fees. Fold those fees
into the expected amounts, as the surrounding tests do.

This is unrelated to the rest of the branch; it is here only so that every
commit builds and tests on its own.

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

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

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
fuzzing or regression evidence
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.

Lower-priorityMerge PR 'Fix DummyTlvs helper visibility for the dummy-tail constructor' (#4965)by Matt Corallo · bee704f1 · Sep 8, 2026 · 1 fileMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Fix DummyTlvs helper visibility for the dummy-tail constructor' (#4965)

from bot/4501-introduce-realistic-constraints-878b64 into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4965
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
merge-commit duplicate discount
Lower-priorityMerge PR 'Introduce Realistic constraints for Dummy Hops' (#4501)by Matt Corallo · ac8b6b99 · Sep 8, 2026 · 7 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Introduce Realistic constraints for Dummy Hops' (#4501)

from shaavan/dummy-follow into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4501
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
merge-commit duplicate discount
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.

Lower-priorityMake DummyTlvs relay/constraint helpers privateby auto-pr-bot · 7a9c746c · Sep 8, 2026 · 1 fileMessage 86 · StrongTriage 0Details
Commit message · auto-pr-bot

Make DummyTlvs relay/constraint helpers private

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

`derive_payment_constraints`, `default_relay` and `random_relay` are only
ever called from within this module, either from the dummy-tail constructor
or from the test-only `Default` impl. Crate visibility advertises them as a
shared helper API they are not, so drop it.

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

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
Lower-priorityMerge PR 'Address review of the holder commit sig checks move' (#4964)by Matt Corallo · 3c605e99 · Sep 8, 2026 · 5 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Address review of the holder commit sig checks move' (#4964)

from bot/4885-move-holder-commit-sig-checks-to-cd7c04 into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4964
Reviewed-by: tankyleo <tankyleo@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
merge-commit duplicate discount
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.

Lower-priorityDrop the `DecryptedOurPeerStorage` doc exampleby auto-pr-bot · e6d9081d · Sep 7, 2026 · 1 fileMessage 86 · StrongTriage 8Details
Commit message · auto-pr-bot

Drop the `DecryptedOurPeerStorage` doc example

@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`.

The example only demonstrated encrypting and decrypting a byte vec,
which the type's method docs already describe, while requiring a
throwaway `Logger` implementation to construct a `KeysManager`. It added
nothing for readers of the public docs, and the roundtrip it exercised is
already covered by `test_peer_storage_encryption_decryption`.

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

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
defensive validation
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.

Lower-priorityMerge PR 'Fix docs on the connection constructors' duplicate descriptor case' (#4959)by Matt Corallo · 0345e694 · Sep 4, 2026 · 1 fileMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Fix docs on the connection constructors' duplicate descriptor case' (#4959)

from fix-conn-docs into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4959
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
merge-commit duplicate discount
Lower-priorityMerge PR 'Don't emit `SpliceNegotiationFailed` when `funding_contributed` returns an error' (#4955)by Matt Corallo · 1a9b1a04 · Sep 3, 2026 · 7 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo

Merge PR 'Don't emit `SpliceNegotiationFailed` when `funding_contributed` returns an error' (#4955)

from 2026-09-splice-sync-err-no-event into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4955
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
merge-commit duplicate discount
Lower-priorityMerge PR 'Always provide funding txn in `ChannelMonitor::get_relevant_txids`' (#4943)by wpaulino · ee27415e · Sep 3, 2026 · 5 filesMessage 81 · StrongTriage 0Details
Commit message · wpaulino

Merge PR 'Always provide funding txn in `ChannelMonitor::get_relevant_txids`' (#4943)

from 2026-08-monitor-relevant-txids into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4943
Reviewed-by: wpaulino <wpaulino@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
merge-commit duplicate discount
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.