rust-lightning

This commit fixes a bug in rust-lightning's encrypted stream reader where reaching the end of a data stream could cause the program to get stuck in an endless loop instead of stopping cleanly. The fix makes the reader recognize the end-of-stream signal and return a 'short read' error. The bug was found by a fuzz tester, not reported as an active attack.

This is a one-line performance micro-optimization in Rust's async waker code. It changes a waker call from 'wake without consuming' to 'wake and consume' because the code already owns the waker and no longer needs it. There is no security relevance.

This commit is purely a code-formatting cleanup. It rewrites a Rust macro called handle_new_monitor_update to follow the project's rustfmt style rules, splitting long lines and adjusting braces. No logic, behavior, or security properties of the code are changed.

This commit fixes a state cleanup bug in the Lightning Dev Kit's handling of failed or aborted splice negotiations. Previously, if a peer disconnected during a splice negotiation, the channel could be left in a 'quiescent' (frozen) state and retain leftover splice data, preventing future splice attempts and possibly blocking normal payments. The patch ensures that when a splice fails before signatures are exchanged, all related temporary state is cleared both on disconnect and when a tx_abort message is received, and it adds tests for these scenarios.

This change fixes a bookkeeping problem in Lightning Dev Kit's interactive transaction negotiation. Previously, if something went wrong while finalizing a funding or splicing transaction, the list of inputs and outputs the user had contributed could be lost before the user could be told about them. The patch delays consuming that constructor object until after all error checks pass, so on failure the software can still report which coins were involved and let the user spend them again. It is a correctness/availability improvement rather than a remote exploit.

This commit narrows a numeric field used to track a shared transaction input from a 32-bit integer to a 16-bit integer. The change is safe because the protocol already caps the number of inputs at 4,096, which fits comfortably in a 16-bit value. It is a small cleanup or consistency fix, not a security patch.

This commit is a small internal cleanup in the code that builds Bitcoin funding transactions for the Lightning interactive-tx protocol. It records the position of the shared funding output inside a data structure, just as the shared input position was already recorded. The immediate change only refactors how the code checks that the shared output exists, and it adds serialization for the new field. There is no direct security fix here, but it prepares the ground for later error-handling logic that will need to ignore the shared output when building protocol error messages.

This commit is a small internal refactor in the code that builds Bitcoin transactions for Lightning channel operations. It changes how the list of inputs and outputs is walked through during the interactive transaction protocol: instead of permanently removing each item from the list as it is sent, the code now keeps the original list and advances an index. The commit message says this is done so the original inputs and outputs can be reused later when constructing an error. There is no direct security fix visible in the diff itself, and no public references claim otherwise.

This commit changes an internal Rust utility module from private to public so that other parts of the library can use its types. It is a routine API-visibility change with no security implications.

This commit fixes Rust type definitions for placeholder constants used when starting the Lightning background processor without optional components. The constants were supposed to be usable in multi-threaded and async code, but they were missing required Send and Sync markers, meaning async users could not actually compile code using them. The fix adds those markers and adjusts related type aliases. It is a compile-time API usability fix, not a runtime vulnerability patch.

This is a small Rust API cleanup. It changes one method signature so that the future it returns can safely borrow from the object it is called on. There is no security bug being fixed and no behavior change for callers.

This commit removes an older, less-safe way to restore the OutputSweeper object from disk. The old method let users load it without providing the current blockchain tip, which could leave the sweeper unaware of recent blocks and potentially miss on-chain events it needs to react to. The remaining method forces callers to supply the latest 'best block' so the sweeper can resync on startup, matching how other critical components already work. It is a hardening/correctness change rather than a clear-cut remote exploit fix.

This commit fills in missing plumbing for a synchronous wrapper around an existing async component (OutputSweeperSync). It adds the ability to receive block updates, handle chain reorganizations, and restore state from disk—features that the async version already had but the sync wrapper lacked. The change is best described as a bug fix / API completeness patch rather than a direct security vulnerability. However, missing these interfaces could have caused a node to miss on-chain events, which in a Lightning context can eventually lead to loss of funds if outputs aren't swept in time.

This commit is purely a code-formatting cleanup. It removes a `#[rustfmt::skip]` directive from a Rust function and lets rustfmt reformat the code. There is no functional change, no bug fix, and no security relevance.

This commit is a code cleanup (refactor) in a Bitcoin Lightning Network library. It changes how invoice creation gets its payment details so that the amount used to build the payment hash, secret, and payment path all come from one place instead of potentially different places. The commit message says this prevents subtle bugs from mismatched amounts, but the actual code change does not appear to fix any currently reachable bug by itself. It is a defensive improvement rather than a clear security fix.

This commit is a code cleanup and API redesign in the Lightning Dev Kit library. It splits one large internal method into two smaller, type-specific methods and moves invoice signing from a helper into the main ChannelManager. The change is described by the authors as improving compile-time safety and making the API more consistent. There is no indication in the commit that it fixes a security bug or vulnerability.

This commit is a code-quality and type-safety refactor in rust-lightning's BOLT12 offers handling. It reintroduces VerifiedInvoiceRequest with a generic signing-key strategy so the Rust compiler can prevent mismatched invoice builders (e.g., trying to use automatically derived keys when explicit keys are required). The change itself does not fix a runtime crash or a known exploit; it makes a class of programming mistakes impossible at compile time. There is no vendor statement that this is a security fix, and no independent researcher is credited.

This commit is a pure code cleanup: it takes an existing function and turns it into a reusable macro (template). The actual behavior of the code does not change; it is only reorganized so the same logic can be reused in future commits. There is no security-relevant change visible in the diff.

This commit is a minor code cleanup in the LSPS2 liquidity service. It removes an unnecessary copy (clone) of a Bitcoin transaction when retrieving and broadcasting a funding transaction. The change returns a reference to the existing transaction instead of duplicating it. There is no security issue here—only a small performance improvement and cleaner code.

This commit only adds a documentation comment explaining an existing behavior in the code. It does not change any logic, fix any bug, or alter how the software operates. There is no security issue present in the change itself.

This commit adds a new LSPS2 trust model called client_trusts_lsp. In this model, a Lightning Service Provider (LSP) delays broadcasting the Bitcoin funding transaction for a new channel until the client has actually paid the channel-opening fee via a forwarded payment. The commit also adds a new ChannelManager method that lets LDK validate a funding transaction without immediately broadcasting it. The changes are primarily a feature addition with safety checks to avoid broadcasting funding transactions after a channel has closed or force-closed.

This patch fixes a race condition in the Lightning Dev Kit's liquidity service plugins (LSPS2 and LSPS5). Previously, when the code decided a peer's state should be removed from disk, it could drop the in-memory lock before deleting the stored data. In that gap, another operation could re-add state for the same peer. The removal could then delete the newly-written state, or an outdated write could overwrite newer data, leading to lost or inconsistent peer records. The fix holds the appropriate locks until the storage write or remove operation is started, and re-checks whether the peer is still removable before deleting anything. If the peer was re-added, it now forces a fresh persist instead of removing.

This commit fixes race conditions in how two liquidity-service modules (LSPS2 and LSPS5) save their state to disk. Previously, multiple 'persist' operations could run at the same time, which could cause stale or partially-written state to overwrite newer data, or cause a peer's state to be removed incorrectly. The fix adds a simple in-flight flag so only one persist runs at a time, and if new changes arrive during a persist, the process loops around and saves them before finishing.

This commit is a one-word documentation correction in a Rust comment. It changes the recommended idempotency key for handling an LSPS2 service event from a temporary routing identifier (intercept_scid) to a stable user-supplied identifier (user_channel_id). There is no code change, no security fix, and no vulnerability.

This commit only adds automated CI test commands for a newly added optional 'tokio' feature in the lightning-persister crate. It does not change application code, fix a bug, or alter any security-relevant behavior. It is purely a testing/continuous integration configuration change.