rust-lightning

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 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 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 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 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.

This commit fixes a fee-estimation bug in LDK's experimental splicing code. When the optional `grind_signatures` feature is enabled, signatures are guaranteed to be one byte smaller than the normal maximum. The splice funding-transaction fee estimator was not accounting for that smaller signature, so it could slightly overestimate fees. The patch subtracts one weight unit from the relevant estimates when the feature is on, and updates tests to match. It is a correctness/efficiency fix rather than a critical vulnerability.

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 commit is a simple internal cleanup in the project's test code. It removes a helper macro named `get_revoke_commit_msgs!` and replaces every use with an already-existing function of the same name. There is no change to how the software behaves in production, no fix for a bug, and no security-relevant change.

This commit is a small internal cleanup in the project's test code. It replaces a few uses of a test helper macro with a direct call to an equivalent helper function. 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 is a straightforward internal cleanup in the project's test code. It removes a helper macro used only in tests and replaces its remaining uses with an equivalent regular function. There is no change to the actual Lightning protocol logic, network-facing behavior, or production code, so it does not create or fix a security issue.

This commit is a test-only refactoring change. It replaces uses of a test helper macro (`commitment_signed_dance!`) with direct calls to an equivalent test helper function (`do_commitment_signed_dance`) in many test files. There is no change to production code, no change to behavior, and no security fix or vulnerability introduced.

This commit is a test-only refactoring change. It replaces uses of a macro called `commitment_signed_dance!` with direct calls to a helper function `do_commitment_signed_dance` in many test files. There is no change to production code, no security fix, and no vulnerability introduced.

This commit fixes an internal inconsistency in how LDK estimates Bitcoin transaction fees. Some parts of the code assumed signatures could be 73 weight units (WU) long, while others used 72 WU. Since 73 WU signatures are non-standard and LDK never produces them, the 73 WU assumption caused fee estimates to be slightly too high. The patch standardizes on 72 WU and replaces magic numbers with named constants. The practical effect is slightly lower, more accurate fee estimates for Lightning channel funding and splicing transactions. It is not a direct vulnerability fix, but incorrect fee estimation could in edge cases cause transactions to be over-funded or, more importantly, could contribute to fee-related negotiation failures.

This change fixes a Lightning channel splicing behavior where one side would unnecessarily force-close the channel if the counterparty tried to abort a splice before both sides had exchanged their first commitment signatures. Previously, any tx_abort during the signature-waiting phase triggered a force close. The patch makes the protocol more forgiving: aborting is allowed until the counterparty has actually sent its initial commitment_signed, because before that point no dangerous on-chain transaction has been committed to. Once commitment_signed is received, aborting remains unsafe and still triggers a force close. The change also cleans up internal state when aborting early and adds tests for the new behavior.

This commit is a pure code cleanup: it changes where one internal type, ChannelTransactionParameters, is imported from. There is no functional change, no bug fix, and no security relevance visible in the diff or commit message.

This commit is a documentation-only change in the Rust Lightning library. It adds a comment explaining that a generic signing helper trait called SignFn is intentionally not exposed to language bindings (for users of other programming languages), because each specific signing method already has its own trait and the generic wrapper is awkward to map across languages. No code behavior changed, and there is no security fix or vulnerability here.

This commit is purely a documentation update: it drafts the release notes for rust-lightning version 0.2 and removes the corresponding pending changelog snippets. No source code, logic, or configuration changes are made, so it cannot introduce or fix a security vulnerability on its own.

This commit only adds a missing documentation comment to the splice_channel function. It explains that a FundingTransactionReadyForSigning event will be generated after signatures are exchanged, and that funding_transaction_signed should then be called. There is no code change, bug fix, or security patch.