rust-lightning

This commit only adds a new test mode to the Lightning Dev Kit's internal functional test framework. It exercises the existing ability to report multiple block disconnections at once through the chain::Listen interface. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit renames an internal method and adjusts how block heights are passed during blockchain reorganizations so the internal API matches the public `Listen` interface. It is a code-consistency refactor with no apparent security impact.

This commit changes how the Lightning Dev Kit (LDK) library is told about blockchain reorganizations. Previously, callers had to provide the full headers of every block being disconnected, one at a time. Now they only provide the new 'fork point' (the last block that is still on both the old and new chain). This makes it easier to recover from deep reorgs or switch to a new node that doesn't have old fork headers. The change removes some internal consistency checks that relied on seeing each disconnected block in order, which slightly weakens defensive assumptions but is described by the authors as acceptable because LDK now provides its own block-sync helper.

This commit adds an async version of the FilesystemStore in the Lightning Dev Kit's Rust library. It changes how file locks are managed and introduces version numbers to keep async writes in order. The change is a feature/refactor rather than a clear security fix, but it touches concurrency and persistence code where bugs could affect data integrity. There is no vendor statement or external report saying this is a security issue.

This commit removes a leftover debug print statement from a test file. It has no security relevance: the println only ran during automated tests, printed non-sensitive JSON test data, and could not be exploited by users or attackers.

This commit adds a new access-control rule to the LSPS5 (webhook) service in rust-lightning. Before accepting a state-allocating LSPS5 request such as 'set webhook', the service now requires proof that the requesting peer is already 'engaged' with the LSP: either an open Lightning channel, an active LSPS2 JIT-channel flow, or an active LSPS1 order flow. If none of those exist, the request is rejected with a new 'NoPriorActivity' protocol error. The change is framed by the authors as a DoS protection, because registering webhooks consumes server-side state and previously any peer could do it without prior relationship.

This change fixes a security issue in the LSPS2 (Lightning Service Provider Specification 2) implementation used by Lightning Dev Kit. Previously, a service's fee-quote 'promise' could be reused by any client who obtained it, potentially letting someone else claim another client's reserved channel-opening terms. The patch now includes the client's unique node identifier in the cryptographic promise, so only the originally quoted client can redeem it.

This commit is purely a formatting cleanup. It removes a `#[rustfmt::skip]` directive and lets Rustfmt reformat the `static_invoice_received` method with standard indentation and trailing commas. No logic, behavior, or security checks were changed.

This commit is purely a code-style cleanup. It renames a local variable and removes line breaks introduced by an automatic formatter in the previous commit. There is no functional change to the program's behavior and no security relevance.

This commit is purely a formatting cleanup. It removes a 'rustfmt::skip' directive and lets the Rust formatter reformat a single method's signature, destructuring pattern, and function call argument list. No logic, behavior, or security properties of the code change.

This commit only reformats a single Rust function using rustfmt. It removes a #[rustfmt::skip] attribute and adjusts line breaks and indentation. No logic, behavior, or security properties of the code are changed.

This commit is a routine feature addition and API cleanup. It adds a way to change the user's configuration while the Lightning node is running, and renames an existing getter method to match. There is no indication of a security bug being fixed.

This commit is a straightforward internal refactor: it wraps a shared configuration object in a read-write lock and renames a field from `default_configuration` to `config`. There is no security fix here and no exploitable weakness introduced in the diff itself. It is preparation for a future feature that will allow runtime updates to the configuration.

This commit removes an unused internal variable called original_funding_txo from the code that handles Bitcoin Lightning channel splicing. The variable was stored during splicing setup but never actually used afterward. There is no security issue here—it's a straightforward cleanup that reduces code clutter and avoids storing unnecessary data.

This is a minor fix to a single automated test. The test previously assumed port 80 was unused, which failed on machines running a web server like Apache. The change finds an unused local port instead. It does not affect production code or user-facing behavior.

This commit makes a small privacy improvement to how the OutputSweeper selects which funds to spend. Previously, the order of inputs in a sweep transaction was predictable. Now the code puts them into a hash set and back into a list, which shuffles their order. There is no security bug being fixed here; it is a hardening/privacy tweak.

This commit changes how Lightning channel 'splicing' (a way to resize a payment channel's on-chain funds) is started. Instead of immediately sending a splice request, the code now first enters a 'quiet' (quiescent) state where both sides pause normal updates, then sends the splice request once both sides agree. It also adds serialization support for new internal data structures so node state can be saved and restored. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a protocol-correctness and state-management improvement for an in-development splicing feature.

This commit only adds a code comment (a TODO note) suggesting future work on combining two types of channel funding updates. It changes no program logic, no data handling, and no security behavior. There is nothing here that could directly cause a bug or be exploited.

This commit only adds a new automated test to the rust-lightning project. It does not change any production code. The test verifies that a Lightning node will disconnect a peer if the peer fails to send a required follow-up message after both sides have agreed to pause (quiesce) a channel. Because no actual behavior is modified, this commit does not introduce or fix a security vulnerability on its own.

This commit adds a safety check in the Lightning Dev Kit's channel code to refuse splice-in operations unless the channel is in a quiet, stable state called 'quiescent.' Before this change, the code apparently allowed splice initiation even when the channel was busy with other activity. The patch prevents potential protocol confusion or unsafe splice handling by disconnecting the peer with a warning if a splice is requested at the wrong time.

This commit fills in two previously-empty fields in a Lightning channel recovery message. These fields tell each side which funding transaction the other side last confirmed as locked. Setting them correctly helps nodes resume a channel after a disconnect without disagreeing about which funds are active. The change is a follow-up to a prior commit that added the message fields but left them unset.

This commit adds new optional message fields to the Lightning channel-reestablish protocol so peers can compare which funding transaction each side believes is active after reconnecting. It is a partial implementation of a protocol extension (splicing). The actual logic that uses these new fields to detect or retransmit lost messages is not included in this commit, so the immediate security risk is very low. It mainly prepares the wire format and data structures for future behavior.

This commit fixes the order in which two Lightning protocol messages are resent when a channel connection is restored after an outage. The 'commitment_signed' message must now be sent before 'tx_signatures'. Sending them out of order could cause a peer to reject or mishandle the channel re-establishment, potentially disrupting dual-funded channels. It is a protocol correctness fix rather than a clear exploit for theft of funds.

This commit adds support for advertising a new Lightning protocol feature called 'Splicing' in the feature-bit flags that nodes exchange when connecting. It does not implement splicing itself and does not change any security-sensitive logic. It is a routine protocol-compatibility change.

This commit is a code-cleanup refactor in a Bitcoin Lightning Network library. It splits one overloaded channel-state check into three more precise checks so that saving channels to disk, deciding when to broadcast force-close transactions, and emitting 'channel is opening' events no longer rely on a single ambiguous flag. The change appears aimed at preventing subtle bugs in dual-funded channel opening, but the commit itself does not claim to fix a known security vulnerability and no exploit is described.