rust-lightning

This patch fixes a logic gap in Lightning Dev Kit's interactive splicing handshake. During a channel reconnection, the code could re-send a commitment signature for a new funding transaction before the user had actually approved and provided their own transaction signatures. The fix gates that retransmission so it only happens after the user calls funding_transaction_signed, preserving the intended 'cancel up to the last moment' behavior.

This commit fixes a fee-reservation bug in a Lightning Network node implementation. When a node calculates how much money it can still send through a channel, it must set aside enough funds to pay the on-chain transaction fee if the channel later closes. Previously, the calculation only considered the node's own view of the commitment transaction. Because the two channel partners can agree on different 'dust limits,' the actual fee on the partner's version of the commitment can be higher. If the node did not reserve enough, it could propose a payment that is valid by its own numbers but violates the protocol when the partner checks it, potentially causing the channel update to be rejected or the channel to become inconsistent. The patch now reserves the larger of the two possible fees.

This commit is a pure code cleanup: it takes one large function that calculates how much money can still be sent over a Lightning channel and splits it into smaller, named helper functions. The actual arithmetic and rules appear unchanged, and the commit message explicitly says most of the changes are code moves. There is no indication this fixes or introduces a security problem.

This commit fixes a bug in how the Lightning node calculates the maximum amount a user can splice out of a channel. Previously, the calculation only looked at the user's own view of the channel (the local commitment). It now also checks the peer's view (the remote commitment). If the two views differ because an HTLC is considered 'dust' (too small to be worth including as an output) on one side but not the other, the old code could advertise a splice-out limit that the node's own safety rules would later reject. In debug builds this triggered an internal assertion failure; in release builds it could lead to inconsistent or rejected splice attempts. The fix makes the advertised limit valid under both commitments.

This commit tightens validation of Lightning network gossip messages. It now rejects channel announcements where the two node IDs are not in sorted (ascending) order, replacing a weaker rule that only blocked a node from announcing a channel with itself. This aligns the code with an updated Lightning protocol specification. The change is defensive and reduces the risk of inconsistent or duplicate channel records being accepted from the network.

This change only modifies a fuzz-testing harness (a tool used to automatically find bugs). It adds new test commands that let the fuzzer decide when to save each simulated node's ChannelManager state, instead of automatically saving after every command. There is no change to the actual Lightning Dev Kit library code that real users run, so this commit does not introduce or fix a security issue in production software.

This commit fixes an ordering bug in LDK's Lightning channel reconnection logic. When two peers reconnect after a channel splice (a way to resize a Lightning channel), LDK can infer that the splice has finalized even if the explicit 'splice_locked' message was missed. Previously, LDK would release queued payment updates before applying that inferred splice, which could cause it to generate commitment transactions based on the old channel state. The fix applies the inferred splice first, then releases queued updates. The bug was found by an internal fuzz test, not reported as an external security issue.

This patch fixes a Lightning protocol bug where a 'splice_locked' message could fail to be sent after a channel reconnects. If a splice transaction confirmed after the peers reconnected but before they finished reestablishing the channel, the node would not tell its peer that the new funding was locked, potentially leaving the channel stuck or unable to route payments. The fix tracks which funding transaction was already mentioned during reestablishment and sends the missing 'splice_locked' immediately afterward.

This patch fixes a logic bug in how a Lightning node responds when a peer asks to pause channel activity (a protocol feature called 'quiescence'). Previously, the node would wrongly apply its own local splice/RBF fee checks before replying to the peer's pause request, which could prevent it from responding and stall the protocol. The fix separates 'we initiated the pause' from 'the peer initiated the pause' so the node can answer promptly without running the local checks.

This patch fixes a crash bug in the Lightning routing code. When a user disabled the normal cap on routing fees, a malicious or specially crafted payment invoice containing route hints with extremely high proportional fees could cause an internal arithmetic overflow. Previously this overflow made the program panic; now the code detects the overflow and treats that route as unusable, so routing fails cleanly instead of crashing.

This commit only changes a fuzzing test harness (a tool used to automatically find bugs). It adds a new test mode that simulates deferred channel-monitor persistence. There is no change to production code, no fix for a real vulnerability, and no indication this is a security patch.

This change is a fix to an internal fuzz-testing harness, not to the production Lightning node code. It makes the test loop keep running one more round when test-only bookkeeping steps (like completing a monitor update or processing a forwarded payment) happen, so the harness can reach a fully settled state. There is no indication this affects real users, live funds, or deployed software.

This commit changes an internal fuzz-testing harness for the Lightning Dev Kit (LDK) project. It does not modify production code, user-facing APIs, or network behavior. Instead, it improves how the fuzzer simulates saving and reloading channel monitor data during restarts, making the test more realistic. There is no indication this fixes a security vulnerability in real LDK software.

This is a small fix to a fuzzing test harness (a tool used to automatically find bugs), not a fix to the main Lightning library. It changes how a test simulates restarting a node so that the simulated restart matches the configured persistence behavior. There is no indication this affects real users or production code.

This commit fixes a bug in the project's automated fuzzing (stress-testing) script. Previously, the script counted test input files using a command that ignored symbolic links (shortcuts to other directories), so it could undercount the real corpus and run too few fuzzing iterations. The change makes the script follow symbolic links when counting files and aborts loudly if a linked corpus directory appears empty. This is a reliability/quality fix for internal testing infrastructure, not a vulnerability in the Lightning protocol code itself.

This commit is a simple code cleanup: it removes a type alias named FundingTxInput and replaces every use of it with the existing type ConfirmedUtxo. There is no change to program logic, no bug fix, and no security-related behavior change. It is purely a naming/refactoring change.

This commit relaxes a safety check in how Lightning channels calculate available balances during fee spikes. Previously, the code tried to ensure a commitment transaction would still have at least one output even if fees spiked. The change says that for one specific calculation (get_available_balances), it's okay not to guard against the 'no outputs' case under fee spikes, because the worst outcome is that an HTLC you just sent gets failed back by the receiver. The change keeps the stricter guard in another function (get_next_commitment_stats).

This commit only removes test cases that covered old-style ('legacy') Lightning channels with zero reserve. It does not change the actual production code that runs in users' nodes. The remaining tests now focus on modern anchor-style channels. There is no direct security fix or vulnerability introduced by this change.

This commit tightens the rules for a special kind of Lightning channel. In older-style ('legacy') channels, it now prevents the local side from setting a zero channel reserve. A channel reserve is a small amount of bitcoin each party must keep on their side of the channel as a security deposit. Allowing it to be zero on legacy channels could remove an economic deterrent that helps stop certain cheating tactics, so the code now rejects that configuration. Anchor-style channels, which use a newer design, can still use zero reserve.

This commit only adds new test code. It does not change any production logic. The tests verify that the software already rejects opening so-called '0-reserve legacy channels' and returns clear error messages. Nothing in the commit fixes a bug or introduces a security-relevant behavior change.

This commit adds an early safety check in the code that builds Bitcoin funding transactions for Lightning channels. It now rejects duplicate inputs and duplicate outputs right when the transaction is being constructed, rather than waiting until later negotiation. Duplicate inputs could let someone try to spend the same coin twice in one transaction, and duplicate outputs could create bookkeeping confusion. The commit message says this was already blocked later in the process, so this is a fail-early hardening change.

This commit tightens a safety check in Lightning Dev Kit's splicing code. When a user tries to splice funds out of a channel, the library now records how much balance is actually spliceable right at the start and rejects requests that would overdraw it earlier in the process. Previously, that check happened later, so a user could construct a splice request that looked valid locally but would only be rejected when sent to the peer. The change also removes an internal helper type and carries the spliceable balance directly in the funding template. It is a defensive hardening change, not an obvious exploitable bug fix, but it prevents a class of invalid splice-out attempts from proceeding further.

This commit adds a new way to fund or top up a Lightning channel by letting the user explicitly pick which Bitcoin inputs (UTXOs) to use, with each input's full value going into the channel. It is a feature addition, not a fix for a known vulnerability. The change introduces careful checks to prevent mixing this manual-input mode with automatic coin selection, and it updates fee and balance accounting to handle full-input consumption safely. There is no evidence in the commit or supplied references that this resolves a security incident or was reported by an outside researcher.

This commit fixes an internal accounting issue that only appears when running the code under a special fuzz-testing build of the secp256k1 cryptography library. In that test-only mode, dummy signatures can be one byte larger than normal, so the code now adds a small buffer to transaction weight estimates. This prevents debug-only assertions from failing and keeps batch-size calculations from being slightly too optimistic during fuzz testing. It does not change behavior in normal production builds and does not introduce a real-world security vulnerability.

This commit fixes a fuzz-testing configuration issue. The project has a feature called 'grind_signatures' that makes cryptographic signatures slightly smaller on average, but it is meant only for real network use because it changes transaction weights. The fuzz tests were accidentally inheriting this feature, which could make fuzzing miss bugs that appear with the normal signature size. The patch disables the feature in fuzz builds and adds a compile-time guard to prevent accidentally enabling it in fuzzing mode. It also updates a hard-coded test seed to match the new (slightly larger) transaction weight.