rust-lightning

This commit is purely a code-formatting cleanup. It removes a #[rustfmt::skip] annotation and lets Rust's automatic formatter reformat one function in the Lightning channel manager. No logic, behavior, or security properties of the code are changed.

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 purely a code formatting cleanup. It removes manual rustfmt skip annotations and lets rustfmt reformat several match statements and function signatures in the Lightning channel code. There are no logic changes, no security fixes, and no behavior differences.

This commit improves how the Lightning node handles reconnections after a network interruption. Previously, when re-establishing a channel, the node sometimes had to ask an external signer for a cryptographic proof point and could not proceed until the signer responded. The change keeps the two most recent revoked proof points cached locally so the common case no longer needs to wait for the signer. It only defers to the signer asynchronously in the rare 'stale state' case, where the peer claims our node is behind. That stale case either proves data loss (causing a protective panic) or proves the peer is lying (causing a force-close). The commit is a defensive hardening/feature change, not a fix for an active exploit.

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations from a few functions in the Lightning channel manager and lets rustfmt reformat the code. No logic, behavior, or security properties of the program change.

This is a trivial code cleanup: a developer removed a temporary variable that held an error message and instead put the message text directly into the logging call. The program's behavior, error messages, and security posture are unchanged.

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 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 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 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 commit is a routine code cleanup in the Lightning Dev Kit Rust library. It takes advantage of a newer Rust language feature (available since Rust 1.75) to remove unnecessary 'Box' heap allocations around futures returned from certain trait methods. There is no indication this change fixes a security bug or introduces a vulnerability; it is a refactoring to simplify the code and reduce allocations.

This commit is a routine code cleanup that swaps one Rust standard-library mechanism for pinning futures (`Box::pin`) with a newer, allocation-free equivalent (`pin!`). It removes heap allocations in a few internal loops and sync wrappers, but does not change program logic, trust boundaries, or behavior. There is no security relevance.

This is a one-line change that adds a Rust compiler feature gate to silence a warning. It does not change program behavior or fix any security issue.

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 only changes internal test helper code in the Lightning Dev Kit repository. It extends a test macro and a test reconnection helper so that automated tests can optionally capture and forward a `tx_abort` message during channel re-establishment scenarios. No production code is modified, and there is no indication this fixes or introduces a security issue.