rust-lightning

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 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 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 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 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 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 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 patch fixes a bug in rust-lightning's Electrum-based transaction sync. When checking whether watched transactions were confirmed, the code previously treated unconfirmed mempool entries from Electrum's get_history as if they were already confirmed. It would then try to fetch a Merkle proof of block inclusion, which cannot exist for an unconfirmed transaction, causing a failure. The fix skips any history entry whose height is 0 or -1 (unconfirmed) in the watched-transaction path, matching what was already done for watched outputs. A debug assertion was also replaced with a proper error log and return if a server returns duplicate history entries.

This commit is a code cleanup inside a fuzzing test file. It converts helper functions into closures and changes how payment identifiers are passed around. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix or vulnerability.

This commit adds a new optional feature to rust-lightning that lets the networking code connect to peers through the Tor anonymity network. It is a feature addition, not a fix for a known security bug. The code uses fresh random data for each connection to keep Tor streams isolated, which is a privacy-conscious design choice. There is no indication in the commit that it addresses an active vulnerability or that a security issue was disclosed.

This commit is a performance-focused internal refactor in the Lightning Dev Kit. It moves the freeing of 'holding cells' (temporary queues of pending payment updates inside a channel) from the message-sending path to the moment the channel state changes. The goal is to avoid doing extra work, including possible disk I/O, while the node is trying to send messages. The commit does not fix a known exploit, but it changes how and when channel state is updated and persisted, which has security-adjacent implications for consistency and denial-of-service.

This commit adds a new 'dummy hop' feature for blinded payment routes in LDK. It lets senders insert fake intermediate routing steps before the real recipient in a private Lightning payment path. Because these dummy hops look and behave like real forwarding nodes, outside observers watching timing or route structure have a harder time figuring out where the payment actually ends up. The change is defensive: it strengthens recipient privacy rather than fixing an active bug or vulnerability.

This commit is a pure internal refactoring of the project's test code. It removes a Rust macro named `check_added_monitors!` and replaces every call with an identically-named regular function `check_added_monitors(...)`. There is no change to production code, user-facing behavior, or security logic. It only affects how tests are written.

This commit is a code cleanup in the Lightning Dev Kit's peer message handling. It changes internal functions so they consistently use a single `wire::Message` wrapper type when preparing messages to send, instead of accepting many different message types directly. It also switches from borrowing messages to moving them. There is no obvious security bug being fixed; it is primarily a maintainability and type-safety improvement.

This is a routine internal code cleanup in the Lightning Dev Kit's message serialization layer. It removes an old helper function (`wire::write`) and a macro (`encode_msg!`), replacing them with direct calls to `Message::write`/`Type::write`. The change does not alter the wire format or add any new behavior; it is purely a refactoring to simplify the code.

This commit only changes how an internal test helper is exposed. It renames a private test-only function and makes it callable from integration tests, with no effect on normal production code. There is no security issue.

This commit fixes a bug in the Lightning Dev Kit (LDK) where a channel could get stuck waiting on itself after a multi-path payment (MPP) was claimed. Previously, when a monitor update completed but another monitor update was blocked, LDK skipped important follow-up actions, such as emitting the PaymentClaimed event and releasing held HTLCs. The fix ensures these follow-up actions run even when the channel still has blocked monitor updates, preventing channels from hanging.

This commit is a straightforward cleanup of log messages. It removes duplicate channel IDs from the text of log lines when the same ID is already attached as a structured field. There is no change to program logic, network behavior, cryptography, or access control. It only affects what developers and operators see in logs, making them more consistent and easier to read.

This commit is a pure code cleanup: it removes a Rust macro used in tests and replaces every call to that macro with an equivalent function call. The behavior of the tests remains the same; no production code or security logic was changed.

This commit removes an older, now-redundant HMAC/nonce authentication mechanism from LDK's blinded payment paths. The code had already introduced a newer 'ReceiveAuthKey' way to authenticate the same data, so the old (hmac, nonce) fields are being stripped out to simplify the codebase. The change is described by the project as a cleanup, not a security fix, and the diff shows the old verification checks being replaced by reliance on the newer mechanism. There is no direct evidence in the commit of an exploitable vulnerability, but removing a redundant authentication layer is a normal hardening step.

This commit is a straightforward internal cleanup in the rust-lightning test code. It removes a helper macro called `get_htlc_update_msgs!` and replaces every use of it with an already-existing function of the same name. There is no change to production code, user-facing behavior, or security logic.

This commit fixes how rust-lightning estimates the final size of a Bitcoin transaction during the interactive-tx protocol used to build funding transactions for Lightning channels. The old estimate double-counted a fixed empty-signature weight and forgot to add the SegWit marker/flag bytes, so it could wrongly allow a transaction that is actually too large to be accepted by the Bitcoin network. Such a transaction would not propagate through standard Bitcoin nodes, potentially causing a channel-funding attempt to fail or get stuck.

This change relaxes a fee-checking rule during Bitcoin Lightning channel transactions. When two parties jointly build a transaction, the code now accepts a remote party's fee contribution that is up to 5% lower than the agreed rate, matching how another major implementation (Eclair) behaves. This avoids false failures caused by real-world coin-selection quirks, but it also means the local node may accept slightly less fee than strictly required.