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.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This commit makes on-chain 'MonitorEvent' notifications durable and replay-safe. Previously, if a node crashed after a ChannelMonitor persisted a block update but before the ChannelManager processed the resulting event, the event could be …
Durability/atomicity fix for async persistence: prevents lost MonitorEvents across crashesNew ack-based event lifecycle with random event IDsArchival gating on unacknowledged events to avoid losing preimage/timeout information
This commit refactors how LDK nodes claim incoming Lightning payments. It replaces a separate 'claim with known custom TLVs' method with an options struct passed to the normal claim call, and fixes two edge cases in payment attribution dat…
API change: claim_funds now takes ClaimFundsOptions, consolidating TLV-known behavior into one pathFailure-packet length bound added to prevent oversized onion error messagesIncoming failure packet truncated at 32 KiB before processing
This change fixes a wallet bookkeeping problem in rust-lightning's built-in coin-selection wrappers. Previously, when a splice attempt failed or coin selection errored after picking UTXOs, those UTXOs stayed marked as 'reserved' in memory …
Resource exhaustion / denial-of-service via permanent in-memory UTXO reservationIncorrect state tracking in coin-selection wrapperNew API method required for correct lifecycle management (release_utxos)
This commit fixes a bug in the wallet's coin-selection code. When the wallet picked UTXOs to spend, it locked them immediately so they couldn't be reused. But if a later step—fetching the change address or the previous transaction—failed, …
Resource lock leak on error pathUTXO lock state inconsistency between selection and confirmationDenial-of-service/funds-unavailability risk from persistent UTXO locks
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
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
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
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
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 …
This commit fixes a design flaw in LDK's built-in wallet helper where coins selected for a splice-in (or other unclaimed funding) were permanently reserved in memory if the transaction was abandoned. Over repeated failed splices, all spend…
Denial-of-service via UTXO exhaustion from repeated failed splice negotiationsRisk of inability to broadcast fee-bumping/claim transactions due to lack of available UTXOsNew API surface (release_utxos) introduced to mitigate resource leak
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…
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…
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
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
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…
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'
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
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
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.
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.
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Lower-priorityTrivial: ChannelManager::read var rename prefactorby Valentine Wallace · 3246010b · Feb 12, 2026 · 1 fileMessage 65 · AdequateInformational 15Details
Commit message · Valentine Wallace
Trivial: ChannelManager::read var rename prefactor
Makes an upcoming commit cleaner: when we add a next_hop variable we want to distinguish it from the previous hop.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100
This is a purely cosmetic code cleanup. It renames local variables in the ChannelManager deserialization code from 'hop_data' to 'prev_hop' and 'is_channel_closed' to 'is_downstream_closed' to make a future change easier to read. No logic, behavior, or security properties change.
Lower-prioritySelect the channel with the highest balance for blinded pathsby Matt Corallo · 8022d1e7 · Feb 12, 2026 · 1 fileMessage 73 · AdequateInformational 23Details
Commit message · Matt Corallo
Select the channel with the highest balance for blinded paths
When building a compact blinded path we need to pick a channel for an SCID that we think is mostl likely to stick around the longest. We don't really have any great options cause we have no idea what downstream code does, but "highest balance" seems marginally better than the previous criteria of "oldest channel".
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 23/100
This commit changes how the Lightning node picks which payment channel to advertise when creating compact 'blinded paths' for private routing. Previously it picked the oldest channel; now it picks the channel with the highest local balance. The stated goal is to choose a channel most likely to remain open and usable, improving reliability of incoming payments rather than fixing a security flaw.
Lower-priorityDrop `ChannelHandshakeLimits::max_funding_satoshis`by Elias Rohrer · 4bb33b2d · Feb 12, 2026 · 4 filesMessage 63 · AdequateLow 35Details
Commit message · Elias Rohrer
Drop `ChannelHandshakeLimits::max_funding_satoshis`
Previously, LDK would by default limit channels pre-Wumbo sizes and leave it to the user to bump `ChannelHandshakeLimits::max_funding_satoshis`. This has mostly historical reasons that aimed to allow limiting risk when Lightning and LDK were not as matured as today. By now, we do however expect ~all users to eventually want to bump this limit, and having them pick an arbitrary value (or pick a default ourselves) is kinda odd. Users that still want to limit risks have ample other means to do so, for example manually rejecting inbound channels via the manual-acceptence flow (via `Event::OpenChannelRequest`) or soon even limiting risk on a per-HTLC basis via general purpose HTLC interception.
Furthermore, it turns out that our current implementation is wrong, as we do always announce `Wumbo`/`option_supports_large_channels` support via the `IN` feature in `ChannelManager` defaults, irrespective of what limit is configured. This has us announcing support for Wumbo channels to only then reject inbound requests in case a counterparty dares to actually try to open one.
To address this, we here simply propose to drop the `max_funding_satoshis` field and corresponding checks entirely, and do what we've announced to the network for a long time: enable Wumbo by default.
This commit removes a default cap on how large an incoming Lightning channel can be. Previously, LDK advertised support for large ('Wumbo') channels but would still reject them unless the user manually raised a hidden limit. The change makes the advertised behavior real: large inbound channels are now accepted by default. It is a behavior change, not a buffer-overflow or key-theft bug, but it could surprise users who relied on the old implicit cap to limit their financial exposure.
AI review queuedRustfmt ChannelManager::internal_splice_initby Wilmer Paulino · 77526192 · Feb 12, 2026 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Wilmer Paulino
Rustfmt ChannelManager::internal_splice_init
35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100
This commit is purely a code-formatting cleanup. It removes a #[rustfmt::skip] directive and lets the Rust formatter rewrap the internal_splice_init function and its call sites. No logic, behavior, or security checks were changed.
✓ Specific, descriptive subject! No meaningful explanatory body
AI analysis · Informational 15/100
This commit is purely a code-formatting cleanup. It removes a `#[rustfmt::skip]` directive and lets Rustfmt reformat the `internal_commitment_signed` function in the Lightning channel manager. No logic, behavior, or security properties of the code are changed.
AI review queuedRustfmt ChannelManager::internal_tx_abortby Wilmer Paulino · 0eadc17e · Feb 12, 2026 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Wilmer Paulino
Rustfmt ChannelManager::internal_tx_abort
35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100
This commit is purely a formatting cleanup. It removes a #[rustfmt::skip] annotation and lets the Rust formatter reformat the internal_tx_abort function. No code behavior, logic, or security properties were changed.
AI review queuedRustfmt ChannelManager::internal_splice_ackby Wilmer Paulino · e1d0566d · Feb 12, 2026 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Wilmer Paulino
Rustfmt ChannelManager::internal_splice_ack
35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100
This commit is purely a code-formatting cleanup. It removes a #[rustfmt::skip] annotation and lets Rustfmt reformat the internal_splice_ack function in the Lightning channel manager. No logic, behavior, or security properties of the code were changed.
✓ Descriptive subject! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
signing boundary
AI analysis · Informational 15/100
This commit is purely a code-formatting cleanup. It removes a manual 'do not format' marker from one function and lets the Rustfmt tool reformat the code. No logic, behavior, or security properties of the software were changed.
AI review queuedRustfmt ChannelManager::internal_tx_completeby Wilmer Paulino · 4d35de57 · Feb 12, 2026 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Wilmer Paulino
Rustfmt ChannelManager::internal_tx_complete
35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100
This commit is purely a code formatting cleanup. It removes a #[rustfmt::skip] annotation and lets the Rustfmt tool reformat the internal_tx_complete function in the Lightning channel manager. No logic, behavior, or security properties of the code were changed.
Refactor missing peer/channel APIError from ChannelManager methods
We have the same error being returned from several `ChannelManager` API methods, so we DRY it up. Doing so also lets us get rid of the inlined `format!` call, which for some reason prevents `rustfmt` from formatting code around it.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit is a straightforward internal cleanup: it replaces several copies of the same error-message formatting code with a single shared helper. The actual error type returned to callers (APIError::ChannelUnavailable) and the information included in the message remain the same. There is no security fix or behavior change.
Refactor missing peer/channel error from ChannelManager message handlers
We have the same error being returned from several `ChannelManager` message handlers, so we DRY it up. Doing so also lets us get rid of the inlined `format!` call, which for some reason prevents `rustfmt` from formatting code around it.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit is a straightforward code cleanup: it replaces repeated, copy-pasted error-message strings in Lightning message handlers with two shared helper functions. The actual error behavior and the messages returned to peers are essentially unchanged (one message now also includes the channel ID, but that is a minor informational improvement). There is no security fix or vulnerability here.
Lower-priorityAdd methods to fetch an `OfferBuilder` for "phantom" node configsby Matt Corallo · 10391b71 · Feb 11, 2026 · 6 filesMessage 73 · AdequateLow 30Details
Commit message · Matt Corallo
Add methods to fetch an `OfferBuilder` for "phantom" node configs
In the BOLT 11 world, we have specific support for what we call "phantom nodes" - creating invoices which can be paid to any one of a number of nodes by adding route-hints which represent nodes that do not exist.
In BOLT 12, blinded paths make a similar feature much simpler - we can simply add blinded paths which terminate at different nodes. The blinding means that the sender is none the wiser.
Here we add logic to fetch an `OfferBuilder` which can generate an offer payable to any one of a set of nodes. We retain the "phantom" terminology even though there are no longer any "phantom" nodes.
Note that the current logic only supports the `invoice_request` message going to any of the participating nodes, it then replies with a `Bolt12Invoice` which can only be paid to the responding node. Future work may relax this restriction.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 30/100
This commit adds a new feature to rust-lightning that lets a group of Lightning nodes create a single BOLT 12 offer that can be paid to any node in the group. It is a feature addition for 'phantom node' setups, not a fix for a known security bug. There is no evidence in the commit or supplied references that this resolves an active vulnerability or incident.
Security candidateAccept blinded paths built by a phantom node participantby Matt Corallo · c10a0af6 · Feb 11, 2026 · 8 filesMessage 85 · StrongLow 37Details
Commit message · Matt Corallo
Accept blinded paths built by a phantom node participant
In the next commit we'll add support for building a BOLT 12 offer which can be paid to any one of a number of participant nodes. Here we add support for validating blinded paths as coming from one of the participating nodes by deriving a new key as a part of the `ExpandedKey`.
We keep this separate from the existing `ReceiveAuthKey` which is node-specific to ensure that we only allow this key to be used for blinded payment paths and contexts in `invoice_request` messages. This ensures that normal onion messages are still tied to specific nodes.
Note that we will not yet use the blinded payment path phantom support which requires additional future work. However, allowing them to be authenticated in a phantom configuration should allow for compatibility across versions once the building logic lands.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
cryptography-sensitive path
AI analysis · Low 37/100
This commit prepares the Lightning Dev Kit (LDK) to support a new 'phantom node' feature for BOLT 12 offers. It changes how encrypted control data in blinded payment paths and onion messages is authenticated: instead of checking one extra node-specific key, it now checks two keys (the existing node-specific key and a new shared phantom-node key). The commit itself does not enable the actual phantom-node building logic yet, but it adds the cryptographic plumbing so that future versions can authenticate blinded paths from any participant in a phantom-node setup while still keeping normal onion messages tied to a specific node.
Security candidateAdd an `ExpandedKey` key for phantom blinded path authenticationby Matt Corallo · 14a47405 · Feb 11, 2026 · 2 filesMessage 78 · AdequateInformational 19Details
Commit message · Matt Corallo
Add an `ExpandedKey` key for phantom blinded path authentication
In the coming commits we'll add support for building a blinded path which can be received to any one of several nodes in a "phantom" configuration (terminology we retain from BOLT 11 though there are no longer any phantom nodes in the paths).
Here we adda new key in `ExpandedKey` which we can use to authenticate blinded paths as coming from a phantom node participant.
78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
access controlcryptography-sensitive path
AI analysis · Informational 19/100
This commit adds a seventh cryptographic key to an existing key-expansion routine. The new key is intended for a future feature where multiple nodes can share a 'phantom' blinded payment path. The change itself only extends the HKDF output and stores the extra key; it does not introduce a vulnerability or fix one.
Lower-priorityRestrict CI build matrix to Linux+MSRV for PRsby Joost Jager · 16856613 · Feb 11, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Joost Jager
Restrict CI build matrix to Linux+MSRV for PRs
Only run the full build matrix (Linux/Windows/macOS × stable/beta/MSRV) on pushes to main. PR and non-main push builds now only run Linux with the MSRV toolchain (1.75.0), which is the most important gate for catching issues.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit changes the project's automated testing configuration so that pull requests and non-main branches only run tests on Linux with the oldest supported Rust version. The full test matrix across Windows, macOS, stable, and beta Rust versions still runs, but only when code is pushed directly to the main branch. There is no code change to the actual software and no security vulnerability is introduced by this configuration change.
Lower-prioritySplit method to reconstruct pending HTLCs into twoby Valentine Wallace · 07b3deff · Feb 10, 2026 · 2 filesMessage 73 · AdequateInformational 13Details
Commit message · Valentine Wallace
Split method to reconstruct pending HTLCs into two
In the next commit, we want to dedup fields between the InboundUpdateAdd::Forwarded's HTLCPreviousHopData and the outer InboundHTLCOutput/Channel structs, since many fields are duplicated in both places at the moment. As part of doing this cleanly, we first refactor the method that retrieves these InboundUpdateAdds for reconstructing the set of pending HTLCs during ChannelManager deconstruction.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 13/100
This commit is a straightforward internal code refactor in the Lightning Dev Kit (LDK) library. It splits one method into three smaller, more focused methods and changes how pending payment forwarding data is organized. There is no new security vulnerability introduced; the change is preparation for a future cleanup of duplicated data fields.
Lower-priorityDedup data in InboundUpdateAdd::Forwarded::hop_databy Valentine Wallace · d3e9cd01 · Feb 10, 2026 · 2 filesMessage 85 · StrongInformational 17Details
Commit message · Valentine Wallace
Dedup data in InboundUpdateAdd::Forwarded::hop_data
Previously, the InboundUpdateAdd::Forwarded enum variant contained an HTLCPreviousHopData, which had a lot of fields that were redundant with the outer InboundHTLCOutput/Channel structs. Here we dedup those fields, which is important because the pending InboundUpdateAdds are persisted whenever the ChannelManager is persisted.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 17/100
This commit is a code cleanup that removes duplicated data stored when a forwarded Lightning payment is saved to disk. It does not change how payments are validated or how funds move; it only changes which fields are kept in memory versus reconstructed later. There is no direct security vulnerability visible in the diff, though any serialization change carries a small risk of compatibility bugs.
Security candidateTrivial: use full path in test macrosby Valentine Wallace · eb31aeb1 · Feb 10, 2026 · 1 fileMessage 70 · AdequateInformational 15Details
Commit message · Valentine Wallace
Trivial: use full path in test macros
Useful when using these macros in lightning-tests/upgrade_downgrade_tests
70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
update trust
AI analysis · Informational 15/100
This is a minor code cleanup change inside test helper macros. It replaces short internal names like `_reload_node` with fully qualified paths such as `$crate::ln::functional_test_utils::_reload_node`. This only affects how test macros resolve symbols when reused in other test crates; it does not change runtime behavior, user-facing APIs, or any security-sensitive logic.
Lower-priorityRemove explicit usage of test_default_channel_configby elnosh · 4e32d105 · Feb 10, 2026 · 2 filesMessage 83 · StrongInformational 15Details
Commit message · elnosh
Remove explicit usage of test_default_channel_config
test_default_channel_config is the default now so it does not need to be set explicitly in some of the tests.
Removes unnecessary extra None config.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit is a minor cleanup of internal test code. It removes redundant calls that explicitly set a default test configuration for Lightning channel managers, replacing them with simpler 'None' values that now produce the same default. There is no change to production code, no security fix, and no user-facing behavior change.
AI review queuedUse handle_and_accept_open_channel in async_signer testby elnosh · 8edfc915 · Feb 10, 2026 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · elnosh
Use handle_and_accept_open_channel in async_signer test
60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit is a minor cleanup of an internal test file. It replaces a small block of test code with an existing helper function when testing the non-zero-conf path. There is no change to production code, no security fix, and no user-facing behavior change.
AI review queuedUpdate changelog and remove manually_accept referencesby elnosh · db2a7eb7 · Feb 10, 2026 · 3 filesMessage 50 · ThinInformational 15Details
Commit message · elnosh
Update changelog and remove manually_accept references
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This is a small documentation and test cleanup commit. It removes leftover references to a 'manually_accept_inbound_channels' configuration option from two test files and a pending changelog entry. There is no code behavior change and no security fix or vulnerability present in the diff.
Lower-priorityBump `lightning-types` crate version to fix semver testsby Matt Corallo · 4deb2f7d · Feb 10, 2026 · 5 filesMessage 83 · StrongInformational 15Details
Commit message · Matt Corallo
Bump `lightning-types` crate version to fix semver tests
5427b0de7e93ce4ccf63c79de756e0da49e33d0b changed the `lightning-types` API but we forgot to bump the crate version to make semver tests pass.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit only updates version numbers in package configuration files (Cargo.toml) for the lightning-types crate and its dependents. It does not change any actual program code, fix a security bug, or alter runtime behavior. The change was made because a previous commit modified the crate's public interface but forgot to increase the version number, causing automated semver compatibility tests to fail.
AI review queuedDrop `proptest`s in `lightning-liquidity`by Matt Corallo · bd358f34 · Feb 10, 2026 · 5 filesMessage 90 · StrongLow 28Details
Commit message · Matt Corallo
Drop `proptest`s in `lightning-liquidity`
`proptest`'s transitive dependency tree has always been somewhat large, but one of them (`rusty-fork`'s `tempfile` dependency) just went ahead with a bump of their `rand` dependency, breaking our MSRV yet again.
Because we don't actually use `proptest` for anything interesting, the simplest solution is to simply drop it, which we do here. Note that we'll likely transition the LSPS5 URL type to simply use the `bitreq` URL type over the next few days anyway, so there's not much reason to care about its continued test coverage.
Further, in writing this commit it was discovered that our tests in `lsps2/utils.rs` were actually broken on the vast majority of inputs, but proptest wasn't testing with any interesting test cases at all, causing it to be missed entirely!
90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Low 28/100
This commit removes the proptest testing library from the lightning-liquidity Rust crate because one of proptest's indirect dependencies bumped its own minimum Rust version, breaking the project's MSRV (Minimum Supported Rust Version) policy. While removing the tests, the author also fixed a subtle rounding bug in the fee calculation helper: it now uses Rust's built-in div_ceil instead of the old add-999999-then-divide-by-1000000 trick. The commit also deletes a large block of URL parsing tests. There is no direct evidence this is a security fix, but the fee rounding change is a correctness improvement and the commit message explicitly notes that the previous tests were broken on most inputs.
Lower-priorityPass the `addr` field of `tor_connect_outbound` to connection setupby Leo Nash · 6f315f23 · Feb 9, 2026 · 1 fileMessage 73 · AdequateLow 38Details
Commit message · Leo Nash
Pass the `addr` field of `tor_connect_outbound` to connection setup
When `setup_outbound` was used to setup a connection proxied over Tor, it previously set the remote address of the peer to the address of the Tor proxy.
This address of the Tor proxy was assigned to the `PeerDetails::socket_address` for that peer in `PeerManager::list_peers`, and if it was not a private IPv4 or IPv6 address, it was also reported to the peer in our init message.
This commit refactors `tor_connect_outbound` to pass its own peer address parameter directly to the connection setup code.
This peer address will now appear in `PeerManager::list_peers` for outbound Tor connections made using `tor_connect_outbound`, and will be reported to the peer in our init message if it is not a private IPv4 or IPv6 address.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 38/100
This commit fixes a bug in the Lightning Dev Kit's Tokio networking code where Tor-proxied outbound connections were accidentally advertising the Tor proxy's address as the peer's address. After the fix, the actual peer address is used instead. This is mainly a privacy and correctness issue: previously a node might leak its Tor proxy's address to the peer and misreport who it was connected to.
AI review queuedUse `DirEntry::file_type` rather than `metadata...` in `list`by Matt Corallo · 36617833 · Feb 9, 2026 · 1 fileMessage 81 · StrongLow 31Details
Commit message · Matt Corallo
Use `DirEntry::file_type` rather than `metadata...` in `list`
In the discussions at #3799 it was noted that `DirEntry::file_type` will often use cached information rather than making a fresh syscall, fixing the `list` race condition where we lose files while iterating the directory for some filesystems on some Unix platforms.
For some reason, that fix didn't make it into the merged PR, and we rather stuck with `DirEntry::metadata()` which *always* does a fresh syscall and always exhibits the problematic behavior. Here we simply swap for `DirEntry::file_type` which at least fixes the issue for "some filesome filesystems (among them: Btrfs, ext2, ext3, and ext4)" (per `readdir(3)`).
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
second-pass: broader security terminology
AI analysis · Low 31/100
This commit fixes a subtle file-listing bug in the Lightning payment channel data storage code. When listing saved data, the program used to ask the filesystem for fresh details about each file, which on common Linux filesystems can briefly make a file appear missing if it is being changed at the same time. The change uses cached information already returned by the directory scan, avoiding that extra check and the race condition. It is a reliability fix rather than a direct exploit, but in the worst case it could cause the node to fail to load channel data it expected to find.