rust-lightning

This commit is a code cleanup: it moves repeated ChaCha20 encryption calls into a single helper function without changing the underlying math or behavior. There is no indication it fixes a security bug or introduces a new vulnerability.

This commit changes an internal fuzz-testing harness (a tool used to automatically find bugs during development), not the production Lightning node code that users run. It adds bookkeeping so the test harness can track which simulated payments were created before or after a saved snapshot of node state. When the harness reloads an older snapshot, it now discards payments that were born after that snapshot, keeping the test's internal tracking consistent. There is no direct security fix to real user funds here.

This is a code cleanup change inside a fuzz-testing file. It moves some bookkeeping helper methods from one struct to another without changing what the code actually does. There is no user-facing or security-relevant change.

This change is an internal performance optimization for the Lightning Dev Kit (LDK). It reduces unnecessary disk writes by skipping ChannelManager persistence when a monitor completion event only produces messages and does not change any important channel state. The commit does not fix a vulnerability and does not change protocol behavior; it only changes when the software decides to save data to disk.

This commit is a small internal code cleanup in the Lightning Dev Kit (LDK) Rust library. It changes a helper function so it returns a richer status code instead of a simple true/false, letting callers decide more precisely whether to save state and whether to keep processing events. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a correctness and maintainability improvement.

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.