rust-lightning

This change makes the Lightning node ignore certain channel update messages that carry a 'do not forward' flag. Previously, the node may have accepted and stored these private-channel updates in its public network map. The fix prevents private channel information from being treated as public routing data, which could leak channel details or pollute the routing graph.

This commit only adds release notes to the CHANGELOG.md file. It does not change any source code, so it cannot introduce or fix a security vulnerability by itself. The changelog text does mention prior bug fixes in earlier releases, but those changes are not part of this commit.

This commit only expands an existing automated test. It renames a test function, adds assertions, and uses new test helpers to verify that custom extra data fields (called 'custom TLVs') are preserved when paying a BOLT11 invoice. There is no change to production code, no bug fix, and no security-related behavior change.

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

This commit is a code cleanup, not a security fix. It moves the existing checks that validate custom Lightning payment data (custom TLVs) from one place in the code into a new dedicated wrapper type called RecipientCustomTlvs. The same rules—type numbers must be large enough, must not duplicate reserved protocol types like keysend, and must not repeat—are preserved. No new restrictions are added and no vulnerability is described.

This is a routine Rust code cleanup change. It removes an unnecessary layer of pointer-like indirection (the Deref trait) from the UtxoLookup type used in Lightning gossip processing. The code now requires types to directly implement UtxoLookup, and adds a blanket implementation so that references and smart pointers to UtxoLookup implementers still work. There is no security-relevant behavior change visible in the diff.

This commit is a large internal refactoring of how message-handler traits are wired together in the Lightning Dev Kit Rust library. It removes the requirement that handlers be wrapped behind a Deref pointer (like Arc or reference), and instead makes the traits themselves automatically work through any Deref wrapper. The stated goal is to reduce generic complexity and verbosity. There is no direct security fix or vulnerability patch here; it is a code-cleanup change that could, in principle, slightly affect type-checking boundaries around untrusted network message handling, but the diff shows behavior-preserving forwarding implementations.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's Rust library. It removes an unnecessary layer of pointer-like indirection (the Deref trait) around the SignerProvider type used throughout channel and monitor code. The change simplifies type signatures and reduces boilerplate but does not alter what the code actually does or how it protects funds.

This is a routine Rust code cleanup change. It removes the requirement that an OutputSpender must be wrapped in a Deref pointer (like Arc or reference), and instead makes OutputSpender work directly through a blanket implementation. The commit message says it reduces generics and verbosity while keeping the same behavior. There is no security fix here.

This is a routine Rust code cleanup change. It removes an unnecessary layer of pointer-like indirection (the Deref trait) around a component called NodeIdLookUp, replacing it with a direct trait bound. The commit message and diff show no functional change intended, and no security bug is fixed or introduced.

This is a routine internal refactoring in a Rust Lightning library. It removes an extra layer of pointer-like indirection (the Deref trait) from how the chain watcher type is used, replacing it with a blanket implementation so the same types still work. The commit explicitly states the goal is to reduce generics and verbosity while keeping behavior equivalent. There is no security fix, bug patch, or externally reported issue.

This commit is a code cleanup change in the Lightning Dev Kit Rust library. It removes an extra layer of pointer-like wrapping (called Deref indirection) around the key-value store trait (KVStore). The stated goal is to reduce generic type complexity and verbosity. The change does not alter how data is stored or encrypted, and the commit message does not describe it as a security fix. A new blanket implementation is added so that any wrapper type that can be dereferenced to a KVStore still behaves like a KVStore, preserving backward compatibility for callers that pass references or smart pointers.

This commit is a routine internal code cleanup in the Lightning Dev Kit Rust library. It removes an extra layer of generic pointer indirection (the Deref trait) for the chain filter type and instead uses the Filter trait directly. The commit message and diff show no security-related intent, and the change preserves equivalent behavior while making the code less verbose.

This is a large but straightforward internal refactoring of the Rust Lightning code. It removes an extra layer of pointer indirection (the Deref trait) from how the Logger type is passed around, replacing it with direct Logger trait bounds. The commit message says the goal is to reduce generics and verbosity while keeping the same behavior. There is no change to cryptographic logic, network protocol handling, or security-sensitive operations.

This is a routine Rust code cleanup change. It removes an extra layer of pointer-like wrapping (the Deref trait) around the MessageRouter type used for routing onion messages in the Lightning Dev Kit. The commit explicitly states the goal is to reduce generics and verbosity while keeping behavior the same. There is no indication of a security fix, bug fix, or behavior change.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's Rust library. It removes an extra layer of pointer-like indirection (the `Deref` trait) around the `Router` type, replacing it with a blanket implementation that makes smart pointers automatically satisfy the `Router` trait. The commit message explicitly states the goal is to reduce generics and verbosity while preserving equivalent behavior. There is no indication of a security fix, behavior change, or vulnerability.

This commit is a large but mechanical cleanup of the Rust code. It removes an unnecessary layer of pointer-wrapping (the `Deref` indirection) around the fee-estimator type used throughout the Lightning library. Instead of requiring a generic pointer that points to something implementing `FeeEstimator`, the code now directly requires a type that implements `FeeEstimator`. The commit also adds a blanket implementation so that any pointer/reference to a `FeeEstimator` still automatically counts as a `FeeEstimator`. The stated goal is to reduce generics and verbosity while keeping behavior the same. There is no direct evidence in the commit of a security vulnerability being fixed.

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

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

This commit is a large but straightforward internal code cleanup in the Lightning Dev Kit Rust library. It removes an extra layer of pointer-like generic wrapping (the `Deref` indirection) around the transaction-broadcasting interface and instead uses the trait directly. The commit message says the goal is to reduce generics and verbosity while keeping the same behavior. There is no indication this fixes a security bug or changes runtime behavior in a way that introduces a vulnerability.

This commit only updates version numbers in two package configuration files. It does not change any actual program code, so it cannot introduce or fix a security vulnerability on its own. It is a routine housekeeping step to prepare for later changes.

This commit simply changes one log message from 'warning' level to 'debug' level. It does not fix a security bug, change any behavior, or alter how the software processes network messages. The change reduces log noise when LDK receives a channel_update it does not recognize.

This commit is a routine test improvement. It extends an existing fuzzing harness to exercise the new Lightning channel splicing feature, adding test-only code and a deterministic seed that walks through a splice-in flow. There is no change to production code, no bug fix, and no security patch.

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

This change is a defensive fix for the Lightning Dev Kit's handling of channel splicing. Previously, when a counterparty sent their initial commitment signature during a splice negotiation, LDK would immediately apply an irreversible monitor update. That made it impossible for the user to safely cancel the splice if they changed their mind. The patch buffers that counterparty message and only processes it after the user explicitly approves the splice by calling funding_transaction_signed. This prevents a state where a splice could be partially committed to before the user actually wanted to proceed.