rust-lightning

This is a tiny code cleanup change. It swaps one way of importing the same standard `Vec` type for another, purely to help an automated bindings generator understand the code. There is no security issue here.

This commit adds documentation comments (no-export tags) to two new Rust traits so that automated binding generators know not to expose them to users of language bindings. It is a build/tooling metadata fix, not a code behavior change. There is no direct security impact, but missing tags could previously have caused generated bindings to expose low-level streaming-read APIs that are not intended for bindings users.

This commit is a pure code cleanup: it changes where one internal type, ChannelTransactionParameters, is imported from. There is no functional change, no bug fix, and no security relevance visible in the diff or commit message.

This commit is a documentation-only change in the Rust Lightning library. It adds a comment explaining that a generic signing helper trait called SignFn is intentionally not exposed to language bindings (for users of other programming languages), because each specific signing method already has its own trait and the generic wrapper is awkward to map across languages. No code behavior changed, and there is no security fix or vulnerability here.

This commit only adds documentation comments to Rust structs, traits, and type aliases explaining that they are not exported to language bindings because async support is not available outside Rust. There are no code behavior changes, no bug fixes, and no security patches. It is a documentation-only change for bindings generation tooling.

This commit only adds documentation comments to two Rust error types explaining that an internal error detail is intentionally not exposed to language bindings users. There are no code behavior changes, no bug fixes, and no security implications.

This commit only adds documentation comments to several Rust functions, explaining that they are not exposed to language bindings (such as Java, Swift, or Python wrappers) because the builder-pattern code relies on Rust-specific move semantics. There are no code behavior changes, no bug fixes, and no security-relevant modifications.

This change fixes a race condition in a Lightning service's save-to-disk routine. Previously, the code would clean up certain in-flight peer requests right before saving state, which could accidentally drop a valid request and even disconnect a peer. Now, cleanup of those in-flight requests is done only when a peer disconnects, while saving only cleans up truly expired channel state. The fix reduces the chance of legitimate requests being lost or peers being wrongly removed.

This commit fixes a bug in rust-lightning's new async channel-monitor persistence code. When a background write finished, the program failed to ring a bell (notify a 'Notifier') that wakes up the background processor. That could leave the node temporarily unaware that a critical disk write completed, potentially delaying channel-state processing or, in edge cases, affecting safety guarantees. The fix moves the Notifier into a shared Arc so the async persister can ring it directly when writes finish.

This commit changes the project's GitHub Actions CI workflow to save and reuse fuzz testing data between runs. It is a build/test infrastructure improvement with no direct security vulnerability or code change to the Lightning library itself.

This commit changes the project's automated testing pipeline so that fuzz-testing data generated in one CI job is saved and reused in a later coverage-reporting job. It does not change the actual Lightning protocol code, wallet logic, or any code that end users run. There is no indication this introduces a security vulnerability.

This commit is purely a documentation update: it drafts the release notes for rust-lightning version 0.2 and removes the corresponding pending changelog snippets. No source code, logic, or configuration changes are made, so it cannot introduce or fix a security vulnerability on its own.

This commit only adds a missing documentation comment to the splice_channel function. It explains that a FundingTransactionReadyForSigning event will be generated after signatures are exchanged, and that funding_transaction_signed should then be called. There is no code change, bug fix, or security patch.

This commit only updates documentation comments for two existing events in the Lightning Dev Kit Rust library. It adds guidance telling developers that if they store an intercepted onion message when a peer is offline, they should also handle the peer-connected event to forward the stored message. There are no code changes, no behavior changes, and no security fix or vulnerability.

This commit is a routine code cleanup. It replaces unnecessary `vec!` macro calls with plain array literals in test code and internal test modules. There is no functional change, no bug fix, and no security relevance.

This is a small code cleanup change. It removes a manually-written 'default' value for an internal state-machine type and replaces one use of a standard-library helper (core::mem::take) with a slightly more explicit one (core::mem::swap). The behavior is functionally identical: the state machine is still briefly put into a placeholder 'Indeterminate' state while a transition runs. There is no security fix here.

This commit only adds README file references to the packaging metadata for several Rust crates. It is a documentation/packaging improvement with no effect on program behavior or security.

This commit only improves an error message by adding the name of a ChannelMonitor that failed to load. It is a diagnostic/logging improvement, not a security fix.

This commit is a straightforward internal API refactor: it changes how three HTTP webhook headers are packaged in an event from a key-value map (HashMap) to a list of pairs (Vec). The commit message explicitly states the reason is to reduce complexity and improve compatibility with language bindings, not to fix a security bug. There is no security relevance in the diff itself.

This is a minor code cleanup that changes how two objects are passed into an internal helper function. Instead of passing references to references, the function now takes the objects directly. There is no security issue here and no behavior change.

This commit removes a redundant internal constructor method from a Rust struct used for webhook notifications in a Lightning liquidity protocol. It is a routine code cleanup with no security implications.

This commit restores a `lazy` flag on the `remove` methods of LDK's key-value store traits. When `lazy=true`, deletions can be batched or delayed to reduce disk I/O, but they may not survive a crash. The change is framed by the authors as a performance fix, not a security fix. It does not introduce an exploitable vulnerability on its own; it gives callers explicit control over durability versus speed.

This commit only changes documentation comments in a Rust source file. It clarifies that storage removals (including lazy ones) must stay in a consistent order with writes to the same key. There is no code change, so it does not by itself fix a runnable bug or introduce a vulnerability. It is a safety clarification for developers building storage backends.

This commit only adds text to the project's CHANGELOG, summarizing what was already fixed in prior 0.1.x patch releases. It does not change any code. However, the changelog text itself discloses several serious security bugs that were fixed in those earlier releases, including vulnerabilities that could allow loss of funds, denial of service, and forced channel closures. Because the commit is a documentation-only disclosure of already-patched security issues, the code change itself is harmless, but the changelog content is highly security-relevant.

This commit only adds a documentation comment explaining that a new type of Lightning channel (zero-fee commitment channels) needs specific Bitcoin network relay support to work properly during force-closes. No code behavior changed, so there is no security vulnerability in the patch itself.