rust-lightning

This commit is a straightforward internal code cleanup in the transaction-building module. It replaces several repetitive helper functions with more general ones and removes duplicated logic, reducing line count and indentation. There is no indication it fixes a security bug or changes behavior in a security-relevant way.

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations and lets rustfmt re-wrap long function signatures, error messages, and calls in several Lightning channel setup functions. No logic, checks, or behavior were changed.

This commit adds an internal-only option for V2 Lightning channels to disable the usual channel reserve requirement. It is marked by the authors as not matching the official protocol specification, using a temporary experimental message field. Because it is internal and not exposed to end users, the immediate security risk is limited, but it introduces assumptions about how peers will behave when reserves are skipped.

This commit adds a new, clearly labeled API for opening Lightning channels to a trusted peer where the counterparty is allowed to keep zero reserve funds. The reserve normally prevents a peer from spending their entire balance, which protects against a specific cheap attack. The new method removes that protection intentionally, so it is only safe with a trusted counterparty. The commit itself documents this risk and does not appear to be a hidden vulnerability.

This commit changes how the Lightning node handles incoming payment requests (HTLCs) that would push the node's own balance below the 'channel reserve' amount chosen by the other party. Previously, the node would reject such HTLCs and close the channel, treating it as a violation. The new behavior accepts these HTLCs, because the developers consider it the counterparty's problem, not theirs. A related safety assertion is now only checked in tests, not in production code. This is a protocol-behavior change rather than a traditional memory-safety or cryptography bug, but it removes a defensive check that previously prevented the local balance from dropping below a reserve threshold on inbound HTLCs.

This commit only changes a fuzzing test file. It expands an existing test harness to exercise two new channel types—zero-fee commitment transactions and zero-reserve channels—so the project's automated fuzzer can look for bugs in those features. There is no change to production code, no fix for a known bug, and no security patch.

This commit adds a large set of unit tests for a new 'zero reserve' channel feature in the Lightning Dev Kit. Zero-reserve channels let one peer spend almost all of its channel balance, which is normally disallowed because it can leave a channel with no money left to pay on-chain fees during a dispute. The tests exercise the new APIs, check that balances and fee buffers are computed correctly, and verify that dangerous edge cases (such as a commitment transaction with no outputs at all) are rejected or handled safely. The commit itself only contains test code, so it does not introduce a live vulnerability, but it documents behavior that could be risky if the production logic has bugs.

This commit renames and expands a special Lightning channel-acceptance API. Previously, users could manually accept an inbound channel from a trusted peer and treat it as confirmed immediately (zero-conf). Now the same API also allows setting the counterparty's required channel reserve to zero. A zero reserve means the peer can spend their entire balance and force-close the channel at no cost to themselves, which removes a key financial deterrent against cheating. The change is explicitly documented as dangerous and only appropriate for trusted peers, but it introduces a new risky option that did not exist before.

This commit adds a marker to saved channel data so that older versions of the software will refuse to load it if the channel uses a zero-satoshi reserve chosen by the local user. That prevents accidental downgrades that could mishandle such channels, because older releases only understood zero-reserve channels when the remote side chose the zero reserve. It is a forward-compatibility guard, not a fix for an active attack.

This change tightens the rules for fee-bumping (RBF) during Lightning channel splicing. After 10 RBF attempts, any new attempt must use a feerate high enough to actually get the transaction confirmed according to the node's own fee estimator. Before this patch, a user or counterparty could keep submitting slightly higher but still-too-low fees, draining the RBF budget without ever confirming. The patch enforces the BOLT spec requirement to 'set a high enough feerate to ensure quick confirmation.'

This commit fixes a bug in Lightning Dev Kit's channel splicing logic. When users add or remove funds from a channel (splicing), the software now re-checks whether the proposed funding contribution is still valid once the channel becomes 'quiescent' (paused for the splice). The bug was that new outbound payments sent between when the contribution was first accepted and when quiescence actually occurred could reduce the user's balance, making a previously-valid splice-out invalid. Without this fix, the splice could proceed based on stale balance information, potentially creating an invalid funding transaction or putting the channel in an inconsistent state. The fix emits failure events and disconnects the peer so both sides cleanly abort the splice.

This commit fixes a bug in the Lightning Dev Kit where a payment channel could end up with a commitment transaction that has zero spendable outputs. In Bitcoin, a transaction with no outputs is invalid and cannot be broadcast, which would make it impossible to enforce or recover funds from the channel if something goes wrong. The patch adds checks during channel opening, fee updates, and HTLC handling to ensure that zero-reserve channels always keep at least one valid output.

This commit fixes a swap in how reserve amounts are calculated for a new type of Lightning channel (V2). Each side's reserve has a minimum floor based on the other side's 'dust limit' (the smallest transaction output they consider meaningful). The code had the two dust limits reversed: the local reserve floor was using the remote dust limit and vice versa. That could let one side set a reserve floor lower than intended, potentially creating a channel state where tiny, uneconomic outputs are created or where balance protections are weaker than the protocol expects.

This commit is a routine API refactor in a Lightning network library. It merges two user-facing methods, `splice_channel` and `rbf_channel`, into one, and adds a way to reuse a previous funding contribution when bumping transaction fees (RBF). The changes are mostly code cleanup and convenience; they do not appear to fix an active security bug. There is one small defensive improvement: a helper now filters out inputs/outputs that are still committed to an earlier splice round when reporting a failed splice, which reduces the chance of accidentally double-spending a contribution. No independent security advisory, CVE, or researcher attribution is present in the materials.

This commit fixes a bug in Lightning Dev Kit's channel splicing/RBF logic. When a counterparty started a fee-bump (RBF) negotiation that later aborted, the local node's record of its own funding contribution was accidentally left at the higher, adjusted fee rate instead of reverting to the original. The fix makes the contribution history append-only and pops the unconfirmed round's entry on abort, restoring the original contribution. The bug could cause incorrect fee accounting and, in some abort paths, a panic or wrong wallet events when the node later initiated its own RBF.

This commit is a straightforward code-quality improvement: it replaces generic, uninformative error returns with a new descriptive error type for funding/splicing operations. It does not change the underlying checks or security boundaries; it only gives callers clearer messages about why an operation failed. There is no indication this fixes a vulnerability or changes exploitable behavior.

This commit fixes a protocol edge case in Lightning splicing. If a user prepared a splice contribution at a low fee rate, and meanwhile the other party completed their own splice, the user's contribution might no longer satisfy Bitcoin's RBF (Replace-By-Fee) minimum-bump rule. The patch makes the node automatically raise its contribution's fee rate when the budget allows, so the splice can proceed immediately as an RBF instead of stalling or falling back to a fresh splice. If the budget doesn't allow it, the node gracefully waits instead of sending an invalid message.

This commit fixes an internal consistency bug in LDK (a Lightning Network implementation in Rust). When a new block created a channel announcement while a peer was offline, the announcement was placed in that specific peer's queue. After a later change started checking that peer queues are empty on reconnect, this leftover message caused assertion failures (crashes in debug builds). The fix moves these broadcast messages into a global broadcast queue, where they belong, instead of a per-peer queue.

This commit changes how the project's automated fuzz testing is run in CI. It replaces a fixed 30-second fuzzing run with a scaled iteration count, adds an optional corpus minimization step, prints a summary table, and tweaks runtime flags. There is no change to production code, user-facing behavior, or cryptographic logic. It is purely a testing infrastructure improvement.

This is a routine GitHub Actions CI workflow change. It moves a pre-fuzz sanity check (running cargo test on fuzz targets) out of the main fuzz job into its own parallel job so the actual fuzz run is no longer blocked waiting for the sanity check. There is no change to application code, cryptography, networking, or any user-facing behavior.

This commit fixes a bug where LDK would incorrectly crash (panic) when restarting after switching a setting from asynchronous to synchronous persistence. The crash happened because replayed background tasks looked like they completed out of order. The fix tells LDK to skip that order-check for replayed tasks, since they are expected to look out of order during startup replay. It is a reliability/stability fix, not an exploitable security vulnerability.

This change is purely a developer tooling cleanup. It moves three special Rust compiler flags used only for fuzz testing into a Cargo configuration file inside the fuzz directory, so developers no longer have to type them by hand. It does not change any production code, user-facing behavior, or security-sensitive logic.

This commit fixes an internal bug in the Lightning Dev Kit's chain monitoring code. When a channel is being force-closed (because the funding transaction was spent), the code could previously get stuck: it would report a monitor update as 'in progress' forever, blocking legitimate payment completion events like 'PaymentClaimed' or 'PaymentForwarded'. In some cases, this could also break the ordering rules for monitor updates. The fix defers the completion signal until after the force-close events are processed, allowing payments to complete normally and preventing the ordering violation. There is no direct evidence this was exploitable by an attacker; it appears to be a correctness/robustness fix.

This commit only changes internal fuzz-testing helper programs so they exit cleanly on macOS instead of getting stuck when a crash occurs. It does not affect the actual Lightning Dev Kit library, real Lightning nodes, or any user-facing code. There is no security vulnerability being fixed or introduced.

This commit fixes a bug in the Lightning Dev Kit where, during a special channel operation called splicing, the node could release its signatures for the new funding transaction before the local channel monitor had durably saved the counterparty's signature for the new commitment. If the funding transaction confirmed on-chain while the counterparty's signature was not yet persisted, the node could be left unable to enforce its funds, creating a potential loss of funds scenario. The fix delays sending `tx_signatures` until the asynchronous monitor update completes, and adds tests to cover this case.