rust-lightning

This commit is a straightforward internal code reorganization in the onion messaging module. It moves the construction of outbound onion messages to happen before they are placed in a send queue, and renames a helper function to clarify it handles outbound traffic. There is no indication of a security fix or behavior change.

This commit is a code cleanup: it pulls out the logic for forwarding onion messages into a reusable helper function. The behavior is essentially unchanged, except log messages now include the original sender's node ID for better debugging. There is no indication this fixes or introduces a security vulnerability.

This change fixes a denial-of-service (DoS) risk in the Lightning Dev Kit's 'static invoice server' feature. Previously, when an invoice server forwarded a request to an often-offline recipient, it would internally buffer those messages and try to connect to the offline node, which could pile up and overwhelm the server. Now these forwarded requests are handled like normal onion message forwards: if the next hop is offline, the message is either dropped or handed off to the user via an interception event, pushing the DoS management burden onto the user instead of the server node.

This commit changes how public keys appear in log and error messages. Previously they were logged using Rust's Debug format, which prints raw byte arrays. Now they use the Display format, which prints the standard readable string form of a public key. This is a code-quality and readability improvement; it does not fix a security vulnerability and does not change program behavior beyond log formatting.

This commit is a performance and robustness improvement for the LSPS5 service handler in rust-lightning. It adds a 'needs_persist' flag so that peer state is only written to disk when something has actually changed, rather than on every persistence call. It also handles the case where a peer's state has already been dropped, returning success instead of an error. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability.

This commit only adds a new automated test to the project. It checks that a service's webhook registration state survives a restart when using a persistent key-value store. There are no changes to production code, no bug fixes, and no security-related behavior changes.

This change fixes a cleanup bug in a Lightning liquidity service. Previously, when peer state was pruned from memory, the corresponding saved data was left behind in the persistent key-value store. Over time this could accumulate stale entries and potentially allow old or expired peer data to be reloaded after a restart. The patch now deletes those stale store entries during regular persistence cycles.

This commit only changes documentation comments in a Rust source file. It adds a note reminding developers that a user-supplied identifier (user_channel_id) must be unique and that channel creation should be idempotent based on it. No code behavior was changed, so there is no direct security vulnerability or fix in the commit itself.

This commit changes several LSPS2 (a Lightning service protocol) API methods from synchronous to asynchronous so they can save peer state to disk inline, right when state changes. It also adds synchronous wrapper methods that immediately poll the new async versions. The change is a reliability improvement: it makes sure state is persisted before returning, reducing the chance of losing track of a payment or channel if the program crashes. There is no direct evidence in the commit that this fixes a security vulnerability, but inconsistent persistence can lead to loss-of-funds or state-confusion bugs in Lightning nodes.

This commit only adds a new automated test to verify that LSPS2 service state survives a restart when stored in a key-value store. It does not change production code behavior, fix a bug, or introduce any security-relevant change. There is no indication of a vulnerability or security issue in the commit itself.

This commit adds a save-to-disk feature for a new Lightning service protocol (LSPS5) so that webhook registration state is not lost when the program restarts. It is a routine reliability improvement, not a security fix, and does not change any access controls or cryptographic behavior.

This commit changes how the Lightning Dev Kit liquidity manager starts up: it now reads previously saved LSPS2 service state from disk when created. Previously, the manager started with empty in-memory state even if data had been saved, which could cause it to lose track of active liquidity requests and routing information after a restart. The change also makes the constructors return errors if the saved data is corrupt or inconsistent, rather than silently starting fresh. This is a reliability and data-integrity improvement, not a typical remote-exploitable vulnerability.

This commit adds the ability to save (persist) the LiquidityManager's event queue to disk so events survive application restarts. It is a feature commit, not a security patch. Most event types are explicitly documented as not persisted, while LSPS2 'OpenChannel' and LSPS5 'SendWebhookNotification' events are now saved and replayed after restart. The code includes safety notes warning callers to make their channel-opening logic idempotent because persisted events may be replayed.

This commit adds a new save-to-disk feature for the LSPS2 service handler in the Lightning Dev Kit's liquidity module. It makes the handler remember peer state across restarts by writing it to a key-value store. There is no direct security bug visible in the diff, but the change introduces new code paths that handle locks, serialization, and storage, and it removes the kv_store field from the top-level LiquidityManager in favor of embedding it inside the handler. A small typo in a doc comment was also introduced.

This commit fixes a bug where the LSPS5 service (a liquidity service feature) was not reloading previously saved peer state when the LiquidityManager was restarted. Previously, after a restart, any stored webhook or peer settings could be forgotten, potentially causing service inconsistencies. Now the code reads saved state from disk during startup, similar to how LSPS2 state was already being handled.

This commit fixes a bug where the LiquidityManager would start with an empty event queue after a restart, even if important events had been saved to disk before shutdown. Now it reads the saved queue when it starts up, so no events are lost. This is a reliability/correctness fix rather than a typical security vulnerability.

This commit changes how the background processor saves the LiquidityManager's state to disk. Previously, the LiquidityManager's persistence was not driven by the regular background task, which could lead to state not being saved promptly. The patch adds a new background persistence call and changes the wake-up signal so it also fires when the LiquidityManager needs to be repersisted. This is a reliability improvement that reduces the risk of losing or getting inconsistent LiquidityManager state after a crash or restart.

This change is a performance and reliability optimization, not a security fix. It teaches the liquidity service's event queue to skip writing to disk when nothing has changed, and to wake the background persister only when a save is actually needed. Previously, the queue may have been persisted repeatedly even when unchanged. The patch also ensures that if a persistence write fails, the system marks the queue as needing to be saved again so it won't lose data.

This commit is a performance and reliability optimization for the LSPS2 (Lightning Service Provider Specification 2) service handler in rust-lightning. It adds a flag so the code only writes peer state to disk when something has actually changed, instead of writing it every time. If a write fails, it marks the state as needing to be saved again later. There is no direct security vulnerability being fixed here; it is mainly about avoiding unnecessary disk writes and making sure failed writes are retried.

This commit adds a thin synchronous wrapper around an existing asynchronous LSPS2 service handler in the Lightning Dev Kit's liquidity module. It does not change any security logic, cryptography, or network behavior; it only exposes the same methods in a non-async API style. There is no indication this fixes or introduces a vulnerability.

This commit adds data-saving (serialization) support for internal LSPS2 state types in the lightning-liquidity crate. It does not change network behavior, fix a bug, or alter security checks. It is a routine feature addition that enables these objects to be written to disk or restored later.

This commit is a routine internal refactor for the rust-lightning project. It adds a key-value store parameter to the LiquidityManager component and introduces a synchronous wrapper (LiquidityManagerSync) so existing code can keep using the manager while the underlying implementation becomes asynchronous. There is no indication of a security fix or vulnerability being addressed.

This commit adds serialization support for LSPS5 (webhook-related) state types so they can be saved to disk and restored. It is a routine feature patch: it makes app names, webhook URLs, webhook records, and peer state persistable. There is no direct evidence in the commit that this fixes an active security bug, but adding serialization can indirectly improve reliability and reduce state-loss risks.

This commit adds a symbolic link (a file that points to another file) so that a shared helper file can be reused between two Rust crates. It also adjusts the helper's imports to work in both crates. There is no security-relevant change here.

This commit fixes a missing notification in the Lightning Dev Kit's channel monitoring logic. When a splice (a planned funding change) never confirms on the blockchain and instead the original commitment transaction confirms, the software now emits a 'DiscardFunding' event. Previously, this event was only emitted when one of the splice candidates confirmed. Without this event, wallets or users relying on it to stop watching or clean up unconfirmed splice funding transactions could leave those transactions being monitored indefinitely, potentially causing confusion, wasted resources, or delayed cleanup.