rust-lightning

This commit tightens the rules for Lightning channel splicing (a way to add or remove funds from an existing channel). It makes sure that after a splice, each side still has enough money left in the channel to meet the required 'channel reserve'—a safety buffer meant to discourage cheating. Before this change, the code did not fully enforce that reserve check when a splice removed funds, which could have let one party drain too much money and leave the channel in a risky state. The patch also cleans up overflow checks and fee handling.

This commit changes an internal function called `for_splice` so it no longer returns an error. Previously, the function could fail and callers used `?` to propagate that failure. Now it always succeeds. The change is small and appears to be a code-cleanup step in the unfinished splicing feature, but the commit message gives no explanation of why the function was made infallible or what error conditions were removed. Without more context, it is unclear whether this removes a safety check that protected against invalid splice parameters.

This commit adds a small helper function to include transaction fees when calculating Lightning channel balances. It also makes an existing internal function's code style match the new helper. There is no obvious security bug being fixed; it appears to be a routine code cleanup and convenience addition.

This commit only reformats a single Rust function using rustfmt. It removes a #[rustfmt::skip] attribute and adjusts line breaks and indentation. No logic, behavior, or security properties of the code are changed.

This commit changes how Lightning channel 'splicing' (a way to resize a payment channel's on-chain funds) is started. Instead of immediately sending a splice request, the code now first enters a 'quiet' (quiescent) state where both sides pause normal updates, then sends the splice request once both sides agree. It also adds serialization support for new internal data structures so node state can be saved and restored. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a protocol-correctness and state-management improvement for an in-development splicing feature.

This commit only adds a code comment (a TODO note) suggesting future work on combining two types of channel funding updates. It changes no program logic, no data handling, and no security behavior. There is nothing here that could directly cause a bug or be exploited.

This commit is purely a formatting cleanup. It removes a `#[rustfmt::skip]` directive and lets rustfmt reformat the `can_send_update_fee` function in the Lightning channel code. No logic, behavior, or security checks were changed.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `can_accept_incoming_htlc` function in a single file. No logic, behavior, or security checks were changed.

This commit is purely a code-formatting cleanup. It removes a `#[rustfmt::skip]` directive and lets rustfmt reformat the `validate_update_fee` function. No logic, behavior, or security checks were changed.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `validate_update_add_htlc` function in the Lightning channel code. No logic, behavior, or security checks were changed.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `get_next_commitment_htlcs` function in the Lightning channel code. No logic, behavior, or security properties of the code were changed.

This commit is purely a code cleanup: it removes formatting suppression markers (`#[rustfmt::skip]`) from one file and lets the Rust formatter reformat the code. The actual logic, calculations, and behavior of the transaction builder do not change.

This commit adds a new internal helper method that estimates the fees, dust exposure, and balances for a future Lightning channel commitment transaction. It does not change any existing behavior or fix a known bug; it appears to be preparatory/refactoring work to support future channel-fee logic. There is no indication in the commit that it addresses a security vulnerability.

This commit is a code clarity and variable-naming refactor in a function that calculates how much money a Lightning channel could lose due to tiny ('dust') transactions plus extra fees. It renames variables, removes an unnecessary mutable parameter, and reorders calculations so the math is easier to follow. The actual arithmetic result appears unchanged, so this is not a security fix.

This commit is purely a code-style cleanup. It removes a `#[rustfmt::skip]` annotation from a single test function and reformats the code so that the project's automated formatter can handle it. No behavior of the program or test logic was changed.

This commit fixes a crash (panic) in the Lightning Dev Kit's rust-lightning library. The crash could happen if a user called a specific function, `batch_funding_transaction_generated`, too early in the channel-opening process—before the channel was actually ready to be funded. The fix adds a state check so the function returns a normal error instead of crashing. It was discovered by an internal fuzzer, not reported by an outside researcher.

This change is a small observability improvement, not a security fix. When a Lightning channel is force-closed because an HTLC (a conditional payment) timed out, the payment hash of the blamed HTLC is now included in the channel-closed event. Previously only a generic 'HTLCs timed out' reason was reported. This helps developers debug payment failures but does not change when or how channels close, nor does it fix any vulnerability.

This commit only adds a new fuzzing test target for StaticInvoice deserialization. It does not change any production code, fix any bug, or alter behavior. It is a testing/infrastructure addition with no direct security relevance.

This change alters how Lightning anchor channel commitment transactions are broadcast. Previously, if a commitment transaction already paid enough in fees, the software would silently broadcast it without telling the user. Now it always emits a 'bump' event so the user (or a delegated service like an LSP) can see what is happening and decide whether to broadcast. The change is described as a safety improvement: broadcasting a commitment without reserves can make HTLCs unclaimable, so users should be notified and given control.

This commit removes unnecessary uses of the `concat!` macro in test code. The `concat!` macro was being called with only a single string literal, which has no effect. The change is purely cosmetic and only affects unit tests in a serialization utility module. There is no security relevance.

This commit only changes test code. It replaces a few instances of cloning a test value to make a single-element slice with a helper that borrows the value instead. This avoids an unnecessary clone in unit tests and has no effect on the production library or real Lightning node behavior.

This commit is a code-cleanup change only. It updates Rust lifetime syntax in type signatures to satisfy a new Clippy lint. There is no functional change, no bug fix, and no security impact.

This commit simply updates three dependency version numbers in a package configuration file (Cargo.toml). It bumps electrum-client from 0.23.1 to 0.24.0, electrsd from 0.34.0 to 0.35.0, and corepc-node from 0.7.0 to 0.8.0. There is no code change and no claim in the commit that this fixes a security issue.