rust-lightning

This commit adds a new read-only field called next_splice_out_maximum_sat to the public ChannelDetails struct. It exposes how much bitcoin can be spliced out of a channel in the next splice operation. There is no change to logic, permissions, or cryptographic checks; it is purely an API/data exposure addition. No security issue is evident from the diff.

This commit fixes how rust-lightning calculates the maximum amount a user can splice out of a Lightning channel. Previously the calculation ignored channel reserve rules and a requirement to keep at least one output, which could have allowed a user to request an invalid splice-out that the protocol or counterparty would reject. The new field properly accounts for both constraints, making splice-out operations safer and more likely to succeed.

This commit tightens validation when Lightning channels are re-funded or 'spliced.' Previously, some checks used rough estimates and debug-only assertions; now the code builds a realistic candidate funding state and runs the same balance/reserve checks against it. The key fix is ensuring that after a splice, both sides' commitment transactions still have at least one output, which matters for zero-reserve channels. Without this, a malicious or malformed splice proposal could potentially reduce a party's balance so low that their commitment transaction becomes empty or invalid, risking loss of funds or channel failure.

This change only moves the project's fuzzing test data from a GitHub Actions cache into a separate public repository. It updates CI scripts to clone that repository, copy files into place, and open pull requests with any newly discovered fuzz inputs. There is no change to the actual Lightning Dev Kit code that users run, and nothing in the diff suggests a security vulnerability or fix.

This commit fixes a small but meaningful typo in a Rust macro used to encode Lightning protocol data. The misplaced parenthesis could cause the macro to match the wrong pattern when encoding optional fields that use a custom encoding. That could lead to messages being serialized incorrectly, which in a Lightning node might cause peers to reject messages, fail to parse state, or potentially behave in unexpected ways during channel operations. The fix is one character moving a closing parenthesis.

This commit changes how optional data fields are serialized in Lightning Dev Kit. Previously, the code could move (consume) values when wrapping them for encoding. Now it borrows them via `.as_ref()` first. The change is framed as a cleanup to avoid future bugs, but the prior workaround suggests there was a real risk of incorrect serialization or use-after-move behavior. There is no direct evidence of an exploitable vulnerability in the diff itself.

This commit only adds a code-formatting check for the fuzz testing workspace in the project's continuous integration (CI). It also reformats a few lines in one fuzz test file to satisfy the new check. There is no functional code change and no security impact.

This commit fixes a bug in the Lightning Dev Kit where reconnecting after a channel 'splice' (a funding update) could cause one peer to send outdated channel announcement signatures. The peer receiving those stale signatures would reject them and force-close the channel. The fix skips generating announcement signatures until the splice has been promoted to the new funding, so both sides agree on the current channel state.

This change fixes a bug where a Lightning node would unnecessarily force-close a payment channel if its peer sent an outdated 'announcement_signatures' message referencing the old channel identifier after a splice (a channel funding update). The node now simply ignores these stale messages, keeping the channel open. The bug was not a direct theft of funds, but it could cause unwanted channel closures and disruption.

This commit fixes a bug in a fuzzing test harness, not in the production Lightning Dev Kit code. The test was incorrectly treating splice transactions as confirmed immediately, which could cause simulated force-closes when multiple RBF (fee-bump) replacements existed. The fix adds a fake mempool so the test models real Bitcoin behavior: only one transaction spending the same funding output can be confirmed. End users running real Lightning nodes are not directly affected.

This commit is a straightforward rename of the Rust type `BestBlock` to `BlockLocator` across the rust-lightning codebase. The struct's fields, serialization format, and behavior are unchanged; only identifiers, comments, and documentation are updated to reflect that the value now also carries recent ancestor block hashes (a 'block locator') rather than just a single best block. There is no security-relevant code change.

This commit swaps a custom-built URL parser for a well-known library (bitreq::Url) when handling LSPS5 webhook URLs. The goal is to reduce home-grown parsing bugs and make accepted URLs match what the HTTP client actually understands. It keeps the rule that only HTTPS URLs are allowed and still enforces a length limit elsewhere. The change is a hardening/refactoring move rather than a fix for a known active vulnerability, though it could close gaps between the old parser and the real HTTP client.

This is a small fix to a fuzz-testing harness (a tool that automatically feeds random inputs to software to find crashes). The change teaches the test harness to recognize one more type of internal event, `DiscardFunding` carrying a full transaction, so the harness does not panic and abort the fuzzing run. It is not a fix in the production Lightning protocol code itself, and there is no indication it can be exploited by an attacker on a real network.

This commit fixes a bug in the Lightning Dev Kit where a timer meant to disconnect unresponsive peers could fire by mistake after a splice operation completed, was aborted, or after reconnecting. The fix makes sure the timer is cleared whenever the protocol leaves its 'quiet' (quiescent) state, preventing unnecessary peer disconnections.

This commit is a code-quality and correctness refactor for the Lightning Dev Kit's handling of splicing and RBF (fee-bump) negotiations. It makes error handling more consistent so that when a channel negotiation fails, the channel properly exits 'quiescence' (a paused state used during splicing) instead of getting stuck. The commit also adds tests confirming that misbehaving peers who send splice or RBF messages before quiescence are established receive a warning and are disconnected. There is no direct evidence this fixes an active exploit, but it removes a class of state-consistency bugs that could lead to stuck channels or incorrect behavior.

This commit is a code-cleanup refactor in a Lightning network library. It removes a redundant flag called `exited_quiescence` and instead decides whether to release queued payments by checking whether a `tx_abort` message was produced. The change is described by the authors as fixing a 'leaky abstraction' where error-handling code knew too much about channel quiescence. It is not a security patch for an exploitable vulnerability, but it touches logic that controls when HTLCs (payments) held during channel quiescence are released, so a bug here could theoretically affect payment liveness or state consistency.

This commit fixes a bug in the Lightning Dev Kit where a channel could get stuck in a 'quiet' state after a fee-bump (RBF) attempt is rejected. Normally, when an RBF request is rejected, the channel should resume normal operation and release any held payments. The bug left the channel frozen, which could delay or block payments. The fix ensures the channel exits the quiet state and frees held payments when an RBF rejection occurs.

This commit fixes a state-handling bug in the Lightning Dev Kit's splicing feature. When a splice attempt is rejected because the proposed transaction fee rate is too high, the code now properly exits 'quiescence' (a temporary pause in normal channel activity) before returning the error. Previously, the channel could remain stuck in quiescence, which might disrupt normal channel operation and message flow.

This commit is a code-quality improvement, not a security fix. It changes how a new version of a file-storage component reports that it has found leftover data from the older version. Previously it returned a generic I/O error; now it returns a dedicated, clearly typed error so callers can tell the two situations apart. No vulnerability is patched and no exploit is prevented.

This commit refactors how users build funding contributions for Lightning channel splicing and RBF (fee-bumping). It replaces several convenience methods with a builder-style API and changes the behavior so that, when a prior splice request exists, new calls amend (add to) the prior request instead of silently replacing it. The commit also removes the ability to start an RBF attempt when there is no prior contribution, and adds tests showing that prior contributions can be amended. There is no explicit security bug in the diff, but the behavioral change could affect how wallets construct splice transactions and could, if callers misunderstand the new semantics, lead to unintended transaction shapes or fee handling.

This commit refactors how Bitcoin Lightning channel 'splice' funding requests are built. It introduces a FundingBuilder API that lets callers amend an earlier contribution (for example, changing the amount or adding a withdrawal output) without re-running wallet coin selection when the existing inputs can still cover the new request. The change also moves prevtx-size validation into the builder and adds explicit error variants for missing coin-selection sources and oversized previous transactions. There is no direct evidence in the commit or supplied references that this fixes a known security vulnerability; it reads as a feature/refactoring change with defensive hardening.

This commit fixes a logic bug in Lightning channel 'splicing'—a way to add or remove funds from an existing channel. Previously, when a user tried to add funds to a channel while also requesting some money be sent elsewhere, the software could silently reduce the channel balance instead of increasing it. The change now ensures that when wallet inputs are provided to add value, the added value truly goes into the channel and any side payments come only from those wallet inputs, not from the existing channel funds.

This change fixes a fuzz-testing harness so it generates and stores real payment preimages instead of reusing payment hash bytes as fake preimages. It only affects internal test code, not the production Lightning library, so it has no direct security impact on real users.

This commit is a build-system and test-infrastructure refactor for the project's fuzzing (automated randomized testing) harness. It splits fuzz test runners into two groups based on whether they use fake or real cryptographic hashes, moves shared code into a common crate, and updates CI scripts, coverage tooling, and documentation accordingly. There is no change to the actual Lightning protocol library or to how production nodes behave, and no security vulnerability is introduced or fixed.

This commit refactors how a Lightning channel funding contribution calculates the amount being added to or removed from a channel. Instead of storing a separate 'value_added' field, the code now derives it from the inputs, outputs, change, and fees. The change removes an explicit input-sufficiency check and rewrites fee-buffer logic. It appears to be a code-cleanup and correctness refactor rather than a clear security fix, but it alters validation boundaries around fees and change in splicing transactions.