rust-lightning

This commit fixes a state-tracking bug in the experimental splicing feature of a Lightning Network implementation. Previously, during a splice, the code used the wrong commitment point (the 'next' one instead of the 'current' one) when sending or receiving the first commitment_signed message. The fix stores the current commitment point explicitly and adds guards that prevent splicing until the commitment point has been advanced at least once. It also persists the new field across restarts. The change is defensive and corrects protocol behavior, but it is not a clear-cut critical security patch on its own.

This commit is a straightforward internal rename of variables and struct fields in the Lightning Dev Kit's channel management code. It changes names like `point` to `next_point` and `transaction_number` to `next_transaction_number` to make the code clearer for an upcoming feature (splicing). No behavior changes, bug fixes, or security fixes are present.

This commit is a simple internal rename of a struct field and its related variables from `next_point` to `pending_next_point`, plus updated comments and log messages. It does not change program behavior, fix a bug, or alter any security-relevant logic. It is preparation for a future rename of another field.

This commit is purely a code-style cleanup. It removes a `#[rustfmt::skip]` annotation from a single test function and reformats the code so that the project's automated formatter can handle it. No behavior of the program or test logic was changed.

This commit only changes a test file. It updates an existing unit test to exercise a new behavior: after a node reloads from an older backup, it should detect that it is behind by comparing against peer storage data. The test is gated behind a compile-time feature flag and does not alter production code. There is no indication this fixes or introduces a security vulnerability in live code.

This commit adds a safety check in LDK that compares a backup of channel data received from a peer against the local state. If the peer's backup shows a newer state than what the local node has, the code now deliberately crashes with a panic and tells the user to use a recovery tool to force-close the channel and reclaim funds. The goal is to detect when the local node has lost critical channel data and prevent it from accidentally losing money.

This commit adds an experimental feature (gated behind a special compile-time flag) that serializes sensitive Lightning channel backup data and sends it to peers for storage. The code itself is a work-in-progress: the authors explicitly note they are unsure which sensitive fields should be omitted from the backup, and the feature is disabled by default. There is no direct vulnerability in the diff, but it introduces a new attack surface where a bug or misconfiguration could leak channel secrets to counterparty peers.

This commit adds new data structures for serializing and deserializing Lightning channel backup information stored with peers. It is purely foundational code that defines how channel data should be formatted for storage and transmission. There is no indication this commit introduces a security vulnerability or fixes one—it appears to be a building block for a future peer-storage backup feature.

This commit is purely a formatting cleanup. It removes a directive that told the Rust formatter to ignore a specific function, then applies standard formatting (line breaks, indentation) to that function. No behavior of the code changes.

This commit fixes a crash (panic) in the Lightning Dev Kit's rust-lightning library. The crash could happen if a user called a specific function, `batch_funding_transaction_generated`, too early in the channel-opening process—before the channel was actually ready to be funded. The fix adds a state check so the function returns a normal error instead of crashing. It was discovered by an internal fuzzer, not reported by an outside researcher.

This commit changes a fuzz test (a randomized testing harness) so it no longer crashes when it tries to fund a channel that isn't ready to be funded. The change only affects test code, not the real Lightning node software that users run. It is a test-hardening fix, not a security patch for a vulnerability in production code.

This commit is purely a code cleanup: it moves a large number of channel-opening test functions from one test file (functional_tests.rs) into another, more focused test file (channel_open_tests.rs). No production code, protocol logic, or security behavior is changed. The goal is simply to reduce the size of the large functional_tests.rs file.

This commit simply renames a test file from channel_acceptance_tests.rs to channel_open_tests.rs and updates the module reference in mod.rs. The actual test code is unchanged except for adding a standard license/copyright header and a module doc comment. There is no change to production code, no security fix, and no vulnerability introduced.

This commit fixes a validation bug in how Lightning offers (BOLT12) are checked. Previously, an offer that included an issuer ID but had an empty list of payment paths was incorrectly rejected. The fix allows empty paths when an issuer ID is present, because the issuer ID itself can be used for signing. The bug was a logic error, not a clear-cut security vulnerability, but it could cause valid offers to be rejected or force users to add unnecessary paths, which may have privacy or usability implications.

This commit is a routine performance cleanup, not a security fix. It moves a once-a-day cleanup task (pruning old webhook records) so it only runs when peers connect or disconnect, instead of running during every message-handling operation. The change reduces unnecessary work and avoids briefly holding a write lock during common read-only operations. There is no indication this fixes a vulnerability.

This patch fixes a logic bug in how webhook notifications are paced. Previously, if a notification was sent while a client was connected, the system would wait for the client to reconnect before resetting the cooldown timer. If the client disconnected right after the notification, the cooldown could block future notifications from being sent promptly. The fix now resets the cooldown when the peer disconnects, so notifications can resume on schedule.

This commit only adds or fixes standard open-source license header comments at the top of several source files. It makes no changes to actual program logic, data handling, or security behavior. There is no security vulnerability here.

This commit is a code cleanup in the LSPS5 (webhook) service module. It replaces a flat hash map of webhooks with a per-peer state object, moving webhook storage from a Mutex to an RwLock and adding helper methods. The stated goal is to prepare for future serialization/persistence work and to match the design used in LSPS1/LSPS2. There is no direct security fix here, but any refactor that changes locking and data structures can introduce subtle concurrency or correctness bugs.

This commit is a code cleanup (prefactor) that changes how a webhook notification cooldown is tracked. Previously, the system remembered the last time each type of notification was sent separately. Now it only remembers the last time any notification was sent. This means a user could hit the cooldown for one kind of alert and then not receive a different kind of alert for up to a minute, even though the old behavior would have allowed it. The change is intentional and documented in the commit message, and the tests were updated to match. It is not a hidden vulnerability, but it does slightly broaden when notifications can be suppressed.

This commit moves the responsibility for detecting when a channel-closing transaction has been confirmed from the ChannelManager to the ChannelMonitor. This is a preparatory architectural change for splicing, where a spend of the funding output does not necessarily mean the channel is closed. The change introduces a new MonitorEvent::CommitmentTxConfirmed event so the ChannelMonitor can reliably inform the ChannelManager when to actually close and remove a channel. Most of the diff is test updates adjusting the order in which closure-related events and monitor updates are expected.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel state management. It replaces an enum (a type with two distinct variants) with a struct (a simple container of fields) for tracking the holder's per-commitment point. The behavior is intended to be equivalent; the change only simplifies naming and removes redundant pattern matching. There is no indication of a security fix or vulnerability being addressed.

This commit only updates comments in a fuzz test file. It changes wording to reflect that recent code changes have made the tests less fragile. No code behavior is modified, and there are no security implications.

This commit changes only a fuzzing test harness, not production code. It alters how fake random numbers are generated during automated fuzz testing so that test inputs remain useful even when the underlying software changes. There is no security vulnerability or fix to a real system here.

This commit is a fuzz-testing infrastructure change, not a security fix. It changes how a test harness feeds fake fee estimates to the Lightning library during automated fuzzing so that existing test inputs don't become useless every time the library asks for fees in a slightly different place. There is no change to production code or to how real users' fee estimates are handled.

This commit is a minor code cleanup. It removes leading underscore prefixes from variable names (like `_recipient_id` becoming `recipient_id`) after a feature flag was removed. These underscores are a Rust convention meaning 'this variable is currently unused.' Once the feature became always-enabled, the variables are now used, so the underscores were no longer appropriate. There is no functional change and no security impact.