rust-lightning

This commit fixes a fee-calculation bug in an experimental Lightning channel-splicing feature. When two parties splice a channel, the initiator pays the on-chain Bitcoin transaction fee. The code previously forgot to count a small but mandatory 8-weight-unit 'empty script signature' cost for the old funding input it re-spends. That made the initiator's fee estimate slightly too low. The fix adds that missing weight, so the initiator contributes enough fee and the splice transaction is more likely to confirm at the intended fee rate. It is a correctness/economic bug, not a direct theft-of-funds vulnerability, but a low fee could cause a transaction to stall or be dropped from mempools.

This commit changes an internal Lightning protocol message so that a wallet tells a static invoice server which database 'slot' to use when storing an invoice. It is a protocol/API simplification, not a security fix. There is no evidence it prevents or fixes any exploit.

This commit removes an unused field that tracked how much money the other party was putting into a channel. The field was marked as dead code and only relevant for future dual-funding/splicing features. The commit message says the value is no longer needed because it has already been used to create a FundingScope. There is no indication of a security bug being fixed.

This commit removes a wrapper that limited individual Bitcoin transactions to 65,535 bytes. The old limit was too generous in some places and too strict in others: it did not account for other fields in the same message, so a transaction just under the limit could still make the overall wire message too large. The patch moves the size check into the context of the enclosing message (TxAddInput) and lets the transaction field hold a normal Bitcoin transaction. It is a correctness/refactoring change for the Lightning protocol implementation, not a clear-cut remote exploit.

This commit fixes a potential integer overflow in the experimental splicing feature of the Lightning Dev Kit. When a user or peer tried to splice a channel with a contribution larger than the total Bitcoin supply (about 21 million BTC), the code could overflow while converting the amount from satoshis to millisatoshis. The patch adds explicit checks that reject contributions above SignedAmount::MAX_MONEY and begins storing contributions using the safer SignedAmount type instead of raw i64 values. The bug is only reachable through the still-experimental splicing code path.

This commit is a straightforward internal refactoring in the Lightning Dev Kit codebase. It changes how transaction 'witness weights' (a measure of data size) are stored alongside funding inputs during channel creation and splicing. The weights are now kept in a shared negotiation context so they can be used later when calculating change outputs. There is no indication this fixes a security bug; it appears to be preparatory cleanup for upcoming dual-funding and splicing features.

This change fixes a channel-recovery edge case in the Lightning Dev Kit. When an older serialized channel state is loaded after an upgrade, the code now tries to re-derive a missing 'current commitment point' from the signer instead of leaving it blank. That lets splicing work immediately after restore; if the signer cannot provide the point, the code falls back to the old behavior rather than failing. It is a robustness improvement, not a clear exploitable vulnerability.

This is a one-line bug fix in a Bitcoin Lightning Network library. A new field called `current_point` was added to track a cryptographic key for the current channel state, but when loading older saved channel data, the code accidentally left it blank (None) instead of restoring the saved value. This could cause the node to lose track of the correct key for the current commitment transaction, potentially leading to failures when signing or broadcasting channel state updates. It appears to be a data-corruption-on-upgrade bug rather than an obvious remote exploit.

This commit changes a single word in a code comment, replacing 'current' with 'next' to accurately describe which commitment point is being populated when restoring a channel after an upgrade. There is no code change, no functional change, and no security impact.

This tiny patch changes how one specific splicing failure is handled in a Lightning channel. Previously, when the local node's commitment point was not ready, the code only warned the peer. Now it also disconnects the peer. The goal is to take the channel out of a temporary 'quiet' (quiescent) state so it can be used for normal payments again. Without the disconnect, the channel could get stuck and be unable to process payments after a failed splice attempt. This is a reliability/availability fix rather than a direct theft-of-funds bug.

This commit only rewords an error message shown when a user tries to splice a Lightning channel before it is ready. No code behavior, logic, or security boundary changes.

This commit only changes test code and the visibility of an equality-checking feature. It makes a test comparison ignore a field that gets rewritten when data is loaded back from disk, and it hides the equality trait from public use because the comparison is fragile. There is no runtime security fix here.

This commit only updates an internal test and its comments. It removes an outdated assumption that a component called ChainMonitor saves ChannelMonitors on every new block, and instead makes clear that the test does not rely on that behavior. There is no change to production code, no fix for a security issue, and no security relevance stated by the project.

This commit improves developer experience in the Lightning Dev Kit by allowing users to request a channel pause (called 'quiescence') even when the peer is temporarily disconnected. Previously, the action would fail and the developer had to retry manually. Now, the request is remembered and automatically retried when the peer reconnects. This is a usability fix, not a security bug fix, and the commit message explicitly frames it as a developer-experience improvement.

This commit removes a small optimization in the Lightning quiescence protocol. Previously, if both sides were about to request a pause (quiescence) at nearly the same time, the code tried to let one side 'go first' based on a tie-breaker. The commit simplifies this by always treating the peer that sends its pause message first as the initiator. This is a cleanup change that reduces state-tracking complexity and lowers the chance of subtle state-machine bugs, but it does not by itself fix a known active exploit.

This commit adds internal bookkeeping so that when a Lightning channel enters a quiet 'pause' state (called quiescence), the code remembers what action triggered the pause. Right now the only action is a placeholder used in tests, so this is a development-only infrastructure change with no immediate security impact on users.

This commit simply moves an existing test function from one file to another within the project's test suite. No production code, behavior, or security properties changed. It is a code-organization cleanup with no security relevance.

This commit only rewrites comments and reorders assertions inside a single test function. It does not change any production code, cryptographic logic, network handling, or behavior visible to users. There is no security issue here.

This commit is a minor cleanup of a single test file. It introduces local variables for node IDs and reuses an Init message object to make the test code shorter and more readable. There is no change to production code or to the test's actual behavior.

This commit adds an internal consistency check (a debug-only assertion) to make sure two different places storing the same counterparty commitment transaction number agree. It does not change release behavior, fix a known bug, or alter how funds are secured. It is a defensive code-quality improvement.

This commit reverts two accidental changes in a fuzzing test file. The changes were mistakenly included during a previous rebase and caused the fuzzing test to break. The fix restores the original expected test values so the fuzz test passes again. There is no indication this affects real Lightning node behavior or introduces a security vulnerability.

This commit adds a small convenience method to make it easier to copy invoice descriptions from one Lightning invoice to another. It is a routine developer-experience improvement with no apparent security relevance.

This patch fixes a logic bug in how a Lightning node validates the first commitment signature after a channel splice. Previously, the code checked the new commitment against the wrong commitment number and public key, which could cause the node to reject a valid splice or, in some edge cases, accept an inconsistent state. The fix stores and compares against the commitment number and point that were actually in use before the splice.

This patch fixes a bug in the Lightning Dev Kit's channel-splicing code. When a channel is being spliced, the first new commitment transaction was being built with the wrong commitment number and the wrong counterparty public key (the 'commitment point'). The fix makes the code use the previous commitment number and the previous commitment point instead, matching what the counterparty already expects. Using the wrong values could cause the commitment transaction to be rejected or, in the worst case, lead to an invalid or unenforceable on-chain transaction if a dispute arises.

This commit removes an outdated code comment and adjusts how a future commitment public key is serialized to disk. It is a cleanup/refactoring change with no apparent security relevance.