rust-lightning

This commit is a routine internal refactor for the rust-lightning project. It adds a key-value store parameter to the LiquidityManager component and introduces a synchronous wrapper (LiquidityManagerSync) so existing code can keep using the manager while the underlying implementation becomes asynchronous. There is no indication of a security fix or vulnerability being addressed.

This commit adds serialization support for LSPS5 (webhook-related) state types so they can be saved to disk and restored. It is a routine feature patch: it makes app names, webhook URLs, webhook records, and peer state persistable. There is no direct evidence in the commit that this fixes an active security bug, but adding serialization can indirectly improve reliability and reduce state-loss risks.

This commit fixes a missing notification in the Lightning Dev Kit's channel monitoring logic. When a splice (a planned funding change) never confirms on the blockchain and instead the original commitment transaction confirms, the software now emits a 'DiscardFunding' event. Previously, this event was only emitted when one of the splice candidates confirmed. Without this event, wallets or users relying on it to stop watching or clean up unconfirmed splice funding transactions could leave those transactions being monitored indefinitely, potentially causing confusion, wasted resources, or delayed cleanup.

This commit only adds new test code. It does not change any production logic. The tests verify that when a Lightning channel is force-closed during a splice, the correct commitment transaction is broadcast depending on whether the splice is unconfirmed, confirmed, or fully locked. This is a defensive regression test, not a security fix.

This fix corrects a Lightning channel protocol bug during 'splicing,' where a channel's funding transaction is replaced. The code was already computing signatures for pending in-flight payments (HTLCs) when creating the new initial commitment, but it was discarding those HTLC signatures and sending an empty list to the peer. That incomplete 'commitment_signed' message could cause the peer to reject or mis-handle the spliced channel state, potentially leading to channel force-closure or stuck payments. The patch returns and includes the HTLC signatures in the message.

This commit moves an experimental Lightning network feature flag called HtlcHold from bit number 1053 to bit number 153. Feature bits are like numbered flags that tell other nodes what capabilities a node supports. The change is being made because bits 0-255 are reserved for official BOLT specifications, while higher numbers can be used by informal bLIPs. This is a cleanup to keep the experimental feature in the right numbering space and avoid future conflicts. It is not a security patch and does not fix a vulnerability.

This commit moves an experimental Lightning network feature bit from position 41 to position 141 (a +100 offset) while keeping the same user-facing names. It appears to be a protocol-compatibility change to avoid clashing with the official BOLTs feature bit while testing. There is no direct evidence in the commit of a security vulnerability being fixed.

This commit simply changes two methods of an internal Rust struct from public (`pub`) to private (`fn`). It is a routine code-cleanup change that reduces how much of the code is exposed outside the module. There is no bug fix, no change in behavior, and no security issue visible in the diff.

This commit is a code-quality and correctness fix in rust-lightning's interactive transaction signing. It changes how counterparty (remote) signatures are stored during a Lightning channel funding flow. Previously, counterparty signatures were immediately added to a data structure named 'unsigned_tx', meaning that structure was no longer truly unsigned. Now, both sides' signatures are kept separately in the signing session and only combined into the final transaction at the last moment. The commit does not describe a security vulnerability, and there is no direct evidence it fixes an exploitable bug, but it removes a confusing state where sensitive signature data was stored inside a supposedly unsigned transaction object.

This commit refactors how a Lightning node decides which side sends transaction signatures first during an interactive funding transaction. Previously, the node stored separate running totals for local and remote input values inside a data structure called ConstructedTransaction. Now it computes those totals on demand from the input metadata. The change is intended to match the protocol specification, which says the entire shared input value should be counted toward whichever node proposed that input—not split into local and remote portions. There is no direct evidence in the commit that this fixes an active security bug, but it removes a place where stored and computed values could become inconsistent and affect the ordering rule.

This commit is a simple code cleanup: it removes two bookkeeping fields (local_outputs_value_satoshis and remote_outputs_value_satoshis) from an internal transaction-construction structure because they were never actually used. The change also renumbers the remaining data fields saved to disk. There is no security-relevant behavior change visible in the diff.

This commit changes how a Lightning node decides when to stop forwarding gossip messages to a peer. Previously, the node dropped gossip if a peer's outbound message queue reached 24 messages or if too many messages had been sent since the last ping reply. Now it drops gossip only when the total buffered data for that peer exceeds 128 KiB. The change is described by the authors as a performance/flexibility improvement to reduce unnecessary gossip drops, not as a security fix. There is no direct evidence in the commit or supplied references that this resolves an exploitable vulnerability.

This commit changes when a Lightning node checks whether a proposed fee change would create risky 'dust' exposure. Previously, the check happened immediately when the peer sent an `update_fee` message. Now, the check is deferred until the peer sends `commitment_signed`, which is the moment the new fee would actually take effect. This allows a peer to send a fee update that temporarily looks risky, as long as they add or remove HTLCs before signing the commitment so that the final state is safe. The change also removes some duplicated fee-calculation code and moves an affordability check into the same deferred validation path.

This commit relaxes an internal requirement about when a special fee rate (used to limit dust exposure) must be provided when computing commitment transaction statistics. Previously, callers had to fabricate a fake fee rate just to avoid triggering a debug assertion, even when they did not care about dust exposure. The change allows callers to pass None for that fee rate, simplifying internal code. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a cleanup/refactoring change.

This commit changes how Lightning Dev Kit calculates 'dust exposure'—a risk measure for tiny outputs that can be abused to make a channel uneconomical to close. The old code only counted extra fees on the counterparty's transaction when the counterparty set a feerate above a configured limit, and it stored that as an optional value. The new code always adds excess fees to dust exposure on counterparty transactions and returns a plain number for the extra exposure if one more accepted HTLC were added. The change appears to fix an accounting gap where excess fees on counterparty commitments were not always included in the local node's dust-exposure check, which could let a remote peer push fees high enough to make the channel unrecoverable.

This change makes a Lightning channel more conservative when deciding whether to accept an incoming payment for forwarding. It now considers fee increases that have been proposed but not yet acknowledged by the other party. This reduces the risk that the node accepts a payment it cannot actually afford to forward once the higher fees take effect, which could lead to a forced channel closure or loss of funds.

This commit only adds a code comment suggesting a future improvement. It does not change any actual behavior. The comment notes that when processing pending HTLC additions, pending HTLC removals should probably also be processed at the same time to make better use of channel funds. There is no fix or active vulnerability present in this change.

This change makes the Lightning node more cautious when deciding whether to accept a forwarded payment (HTLC). Previously, the node only counted HTLCs that the counterparty already knew about when checking channel capacity limits. Now it also counts HTLCs that have been announced locally but not yet acknowledged by the remote side. This prevents the node from accepting a new forward that could push the channel over its limits once those in-flight HTLCs are committed, reducing the risk of being unable to fulfill obligations or being forced into an unfavorable state.

This commit removes a panic (crash) condition in the Lightning Dev Kit's channel transaction builder. Previously, if a channel's accounting reached an unexpected state where the holder's balance exceeded the total channel value, the code would panic and crash the node. Now it returns a proper error, allowing the node to close the channel gracefully instead of crashing. This is a defensive fix that prevents a potential denial-of-service where a malicious or buggy counterparty could crash your Lightning node by driving channel state into an overdrawn condition.

This commit is a code cleanup: it stops saving duplicate copies of Bitcoin transaction outputs (TxOuts) because the transaction itself already stores them. It keeps only the small pieces of metadata needed to remember which outputs belong to which party. There is no obvious security bug being fixed here, but the change touches serialization formats and how a Lightning channel identifies its funding output, so it has some security-adjacent relevance.

This commit is a simple internal code cleanup: it renames a Rust struct from NegotiatedTxInput to TxInMetadata and updates all references. The commit message explicitly says the rename is because the struct no longer holds a full transaction input. There is no functional change to transaction handling, cryptography, network behavior, or serialization format.

This commit only adds a new automated test for an existing feature. It does not change any production code, so it cannot introduce a security vulnerability or fix one. The test checks that a new asynchronous mode of the ChainMonitor component correctly waits for background writes to finish before reporting them complete.

This commit is a routine internal refactoring of a Lightning node storage helper. It rewrites the existing synchronous `MonitorUpdatingPersister` to be a thin wrapper around a new asynchronous implementation, without changing how data is stored, encrypted, or validated. The new async code is explicitly marked as beta and is not yet exposed to users. There is no indication this fixes or introduces a security vulnerability.

This is a small code cleanup inside a test-only helper. It removes a special case that used a different key format when the secondary namespace was empty, replacing it with one consistent format. It also avoids an unnecessary copy of a byte buffer. The change only affects internal test utilities and does not alter production code or real user data handling.

This commit fixes a bug where setting a configuration value called `maximum_pending_updates` to 0 in a Lightning node persistence helper would cause the program to crash (panic) due to division by zero. The fix makes the code skip storing incremental updates when the limit is 0, which is a valid 'do not store updates' setting. It is a robustness fix rather than an exploitable security vulnerability, and the crash would only affect the node operator who configured the value to 0.