rust-lightning

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 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 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 Rustfmt reformat the `static_invoice_received` method with standard indentation and trailing commas. No logic, behavior, or security checks were changed.

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

This change fixes a logic bug in how the Lightning node decides whether to send a 'channel is being force-closed' update to its on-disk channel monitor. Previously, the code used a broad channel-state check that could incorrectly skip sending the update during some interactive funding flows, or send it too early in other cases. The patch replaces that broad check with a precise counter that tracks when the original monitor was first created, ensuring the close update is only generated when a monitor already exists. The practical effect is more reliable recovery of funds during force-closes involving modern interactive channel-opening protocols.

This change fixes a logic bug in how the Lightning node decides whether to accept a 'shutdown' message from a peer. Previously, the code used a broad helper called 'is_pre_funded_state' to skip shutdown handling, but that helper did not correctly cover newer V2-style channels that have negotiated funding but not yet sent the node's own transaction signatures. In those cases, a peer could send shutdown and the node might try to run full shutdown logic (including signing a spending transaction) even though the funding transaction was not actually broadcastable yet. The patch narrows the check to the exact channel states where shutdown should be short-circuited.

This commit only adds new tests and updates an existing test helper. It does not change production code behavior. The tests verify that dummy hops can be inserted into blinded paths and that padded versus compact path formats behave as expected. There is no security fix or vulnerability patch here.