rust-lightning

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.

This commit reorders the splicing/dual-funding handshake in LDK so that the node does not send its initial commitment signature until after the user has had a chance to sign the funding transaction. Previously, the commitment was sent first, which locked the node into the splice even if the user could not or did not want to sign. The change also makes the 'ready to sign' event persistent across restarts and adds a forward-compatibility note that downgrading while a splice is pending is not supported with async monitor updates. It is a protocol-flow hardening change, not a fix for an active exploit.

This commit fixes a race condition in how the Lightning Dev Kit processes background checks on channel announcements (UTXO lookups). Previously, the result of a completed check could be thrown away before another part of the system could collect it, meaning valid gossip messages might be silently lost and not applied to the network graph. The fix keeps the result alive until it is explicitly collected.

This commit is purely a code cleanup: it removes formatting-suppression markers (`#[rustfmt::skip]`) from the file `lightning/src/routing/utxo.rs` and lets rustfmt reformat the code. There is no functional change, no bug fix, and no security-relevant behavior change.

This commit fixes a logging behavior bug where an outer log-context wrapper would overwrite context fields already set by an inner wrapper. The change makes context values stick to the closest (innermost) source, which is the intended behavior. There is no security vulnerability here—only a correctness improvement to log metadata.

This change is a code-quality and observability fix, not a security patch. The developers noticed that payment-related log messages from an internal component called OutboundPayments were missing useful context (like the payment hash), making it harder to search and debug logs. They fixed it by passing a specially-wrapped logger into each OutboundPayments call so the context is attached at the point where the call is made. There is no vulnerability being fixed here.

This commit only adds a new piece of information—the PaymentId—to log records so operators can search logs more reliably, especially for newer BOLT 12 payments where the payment hash isn't known early. It does not change any payment logic, cryptography, network handling, or access controls, and it does not fix or introduce any security vulnerability.

This is a routine internal code cleanup in a Lightning network library. It replaces a custom logger wrapper type with a shared, existing wrapper type. There is no change to user-facing behavior, no bug fix, and no security-relevant change.

This commit only changes test code in the Lightning Dev Kit Rust library. It extracts repeated logic for listing monitor files into a small helper function that ignores temporary `.tmp` files. There is no change to production code, no security fix, and no vulnerability being addressed.

This commit adds a documentation file (CLAUDE.md) that gives instructions to an AI coding assistant about how to work with the project. It does not change any program code, build scripts, tests, or configuration that could affect security.

This commit refactors when and where the Lightning node decides to intercept HTLCs (payments it is asked to forward). It moves the interception decision from a later forwarding stage to the earlier moment when the incoming HTLC is decoded. The change is preparatory work for a larger feature and includes a noted backwards-compatibility limitation: HTLCs first received on LDK versions before 0.2 will no longer be intercepted and will instead be forwarded or failed automatically. There is no direct evidence in the commit that this fixes an active security vulnerability, but it changes payment-handling logic in a security-sensitive area.