rust-lightning

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 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.

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 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 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 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 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 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 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 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 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 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 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 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 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 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.