rust-lightning

This commit only changes CI test scripts to use cargo's --quiet flag instead of --verbose. It reduces log output size and makes CI logs easier to read. There is no change to application code, no security fix, and no vulnerability introduced.

This commit simply removes two unused import statements from Rust source files. It does not change any program logic, data handling, or security behavior. There is no security relevance.

This commit only adds and improves test code. It gives the project's test mock broadcaster the ability to remember what 'type' each broadcast transaction was (for example, a splice transaction), and updates tests to check that splice transactions are labeled correctly. There is no change to production code that handles real money or network messages, so it does not introduce or fix a security vulnerability on its own.

This commit is a straightforward API refactor: it adds a TransactionType label (Funding, Close, Claim, Sweep, etc.) to every place in the Lightning Dev Kit that broadcasts a Bitcoin transaction. The actual transactions being broadcast do not change; only the metadata passed alongside them changes. There is no security vulnerability being fixed or introduced here.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's invoice handling. It replaces the use of a generic SHA-256 hash type with a dedicated PaymentHash type when representing payment hashes inside BOLT11 invoices. There is no indication this fixes a security vulnerability; it is a type-safety and consistency refactor that touches many test files and a few production call sites.

This commit is a straightforward code cleanup in a Rust Lightning library. It stops hiding an internal module behind re-exports and exposes it directly in the public API. The change fixes an earlier accidental break in the public API where a type (CustomTlvs) was used in a public struct but not re-exported, making it hard for downstream developers to use. There is no runtime security issue, no bug fix in payment logic, and no exploit.

This commit is a small internal cleanup in the Lightning Dev Kit's channel manager. It moves the handling of two optional hash-map fields from a later processing stage into the deserialization stage, so the fields are always plain hash maps after loading. The change makes the code's invariants clearer and removes a potential source of inconsistency, but it does not appear to fix an active security bug on its own.

This commit is an internal code cleanup in the Lightning Dev Kit's channel manager. It moves the handling of old data formats (legacy TLV fields) from a later initialization stage into the deserialization stage, so the data structure is normalized earlier. There is no direct evidence this fixes an active security vulnerability; it appears to be a maintainability and correctness refactor to prevent inconsistencies when loading older persisted data.

This commit is a pure code refactoring: it moves an existing block of logic from one place inside a function into a newly created helper function, without changing what the logic actually does. There is no security-relevant behavior change visible in the diff.

This commit is a follow-up cleanup that rewrites three sections of deserialization logic in rust-lightning's ChannelManager to use more idiomatic Rust iterator methods. It does not change the underlying behavior, data formats, or security checks; it only makes the code shorter and easier to read.

This commit is a pure internal code reorganization. It splits the loading of a Lightning node's ChannelManager into two steps: first reading raw data into a temporary data holder, then validating and building the actual ChannelManager. No security behavior appears to change; it is a refactoring to make the code easier to maintain and test.

This is a small internal cleanup in the Lightning Dev Kit's Rust code. It removes unnecessary 'Option' wrappers from two data fields that are always set during deserialization, replacing later `.unwrap()` calls with direct use. The change does not introduce a new security vulnerability; it is a refactoring that makes the code clearer and slightly reduces panic risk by moving the unwrapping to a point where the value is guaranteed to exist.

This commit only removes a misleading documentation comment. It does not change any code behavior, fix a bug, or address a security issue. The previous comment incorrectly warned that using different data stores for different parts of the lightning node could be unsafe; the commit author clarifies that this is not actually a problem.

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.