rust-lightning

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 commit only adds a new unit test to the Lightning Dev Kit codebase. It does not change any production code, fix a bug, or alter behavior. The test exercises a specific scenario involving small ('dust') HTLCs in a v3 commitment transaction. There is no security-relevant change in the diff itself.

This commit adds support for Bitcoin's new Testnet4 network in the rust-lightning library. It mainly bumps a dependency version and maps Testnet4 invoices to use the existing Testnet currency type. The change is a routine compatibility update, not a security fix, though it removes a fallback that previously treated unknown networks as regtest.

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 changes how hidden (blinded) Lightning payment paths are created and checked. It adds a new 'receive authentication key' used when encrypting the final hop's details, and it makes the receiving node verify that the final hop was encrypted with that key. This is a defensive hardening change that reduces the data sent in payment paths and makes the verification logic consistent with another similar feature (blinded message paths).

This commit only adds new test code. It introduces test vectors for a new Lightning channel type (v3 / zero-fee anchor commitments) and a small helper function for converting hex strings to payment hashes in test utilities. There is no change to production code, no bug fix, and no security patch.

This commit only changes test code. It updates a Lightning channel test helper so that test vectors explicitly provide payment preimages instead of the helper guessing them from a hardcoded loop. There is no change to production code and no security risk to users.

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 is a test-only change. It replaces fuzz-testing coverage for the older 'quiescence' protocol with coverage for the newer 'splicing' feature in a Lightning channel consistency fuzz target. It adds test wallets, message handlers, and fuzz actions to exercise splicing, but makes no changes to production code that handles real user funds or network messages.

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 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 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 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 is a cleanup of the project's continuous integration fuzz-testing script. It replaces a custom, per-target method of limiting how long each fuzz test runs with a built-in honggfuzz command-line option (`--run_time 30`). There is no change to the actual Lightning protocol code, cryptography, networking, or any code that end users run. It only affects how long automated fuzzing jobs run in CI.

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.