rust-lightning

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

This commit relaxes Rust type-system requirements (Send + Sync bounds) for the library's 'no-std' build mode and generalizes an internal future type alias. It is a portability and API cleanup change. There is no direct evidence in the commit that it fixes an exploitable security vulnerability; it is more likely a correctness/compatibility improvement for embedded or single-threaded environments.

This commit only adds Rust Debug formatting implementations to internal data structures so developers can print them during tests. It does not change any logic, network behavior, cryptography, or access controls, and therefore has no security relevance.

This commit changes a single Rust function signature from requiring a mutable (writable) reference to the channel monitor to only requiring a shared (read-only) reference. The function only reads watched outputs to filter transactions, so the mutable reference was unnecessary. This is a code-quality/API cleanup with no security-relevant behavior change.

This patch fixes a follow-up bug in the Lightning Dev Kit's channel monitor. For channels where the user manually broadcasts the funding transaction, the software could incorrectly try to broadcast a force-closing transaction before the funding transaction had actually appeared on-chain—specifically when HTLC payments timed out. This could lead to wasted transaction fees, failed broadcasts, or unnecessary on-chain activity. The fix applies the same safety gate already used for normal commitment broadcasts to the HTLC-timeout force-close path.

This commit only rewrites and expands an existing automated test. It adds more test cases for manually-funded Lightning channels (including zero-confirmation opens and timeout-based closes) and refactors test helper functions to support those scenarios. There is no change to production code, no bug fix, and no security patch.

This commit simply deletes two automated test cases from the codebase because they were made redundant by a prior test expansion. No production code, user-facing behavior, or security-sensitive logic was changed. It is a routine test-maintenance cleanup.

This is a small internal cleanup in the code that handles Lightning channel closure broadcasts. It moves an early-exit check earlier in a function so that, in a special 'manual broadcast' mode, the code skips unnecessary setup work when it already knows it will not actually broadcast anything yet. The change does not alter the final return values or the conditions under which broadcasting happens; it only avoids doing some now-pointless work. There is no direct security fix here, but it reduces the chance of future logic mistakes by making the intent clearer.

This commit fixes a design limitation in Lightning Dev Kit's handling of zero-fee commitment (0FC) channels. In those channels, on-chain transactions must follow Bitcoin's version-3 (TRUC) rules, which impose strict size limits: a parent commitment transaction can be at most 10,000 vB, and its child anchor/HTLC transactions can be at most 1,000 vB. Previously, LDK could try to claim too many HTLCs in a single transaction or select too many wallet inputs for an anchor transaction, producing a transaction that the network would reject. The patch splits large HTLC claims into multiple smaller transactions and teaches the coin-selection algorithm to respect a maximum transaction weight. It also updates the public API for wallet coin selection to accept a new max_tx_weight parameter. This is a correctness/robustness improvement rather than a remote-exploitable vulnerability.

This commit fixes a regression in the Lightning Dev Kit's channel monitor. A previous change accidentally made it impossible to manually force-broadcast a closing transaction for certain channels before the funding transaction was seen on-chain. The fix restores the intended behavior: when a user explicitly asks to broadcast the latest commitment transaction, the monitor will do so immediately, while other automatic paths still wait for the funding transaction to appear on-chain to avoid creating invalid or premature transactions.

This commit fixes a logic bug in how Lightning Dev Kit tells the network layer to pause or resume reading data from a peer. Previously, after a partial buffer flush, the code could fail to tell the socket driver to pause reads even though it was busy validating gossip messages. The fix ensures at least one 'send_data' call is made whenever the desired read-pause state does not match the last state we told the driver about. This is a robustness fix in backpressure handling, not a clear-cut remote exploit.

This commit simply renames an internal method from `peer_should_read` to `should_read_from` to make its purpose clearer. No behavior, logic, or security properties of the code are changed.

This commit only adds new tests and a test helper for the 'manual broadcast' funding flow in a Lightning network library. It does not change production behavior, fix a bug, or alter security-critical code. The tiny code change in channelmonitor.rs is just adding a trailing comma in a test module. There is no security issue here.

This patch fixes a logic bug in rust-lightning's channel monitor for manually-broadcast funding transactions. Previously, the monitor could try to claim outputs and watch for spending transactions before the funding transaction had actually appeared on the blockchain, which could lead to wasted work, incorrect state, or spurious errors. The fix defers all claimable-output tracking until the funding transaction is confirmed on-chain, and avoids generating duplicate claims when a block is processed.

This patch fixes a logic gap in Lightning Dev Kit's channel monitoring. When a user manually chooses not to broadcast their side of a new channel immediately, the code was supposed to queue that broadcast for once the funding transaction is seen on the blockchain. Before this fix, the queueing did not happen, so the holder's commitment transaction might never be broadcast automatically. That could leave funds at risk if the counterparty misbehaved after the channel opened.

This change fixes a logic bug in Lightning Dev Kit's channel monitor. When a user manually broadcasts their own funding transaction (rather than letting LDK do it automatically), the software could previously try to broadcast a commitment transaction before the funding transaction had actually appeared on the blockchain. Because commitment transactions spend the funding output, broadcasting them too early would fail mempool validation and could generate unnecessary fee-bumping notifications for transactions that cannot yet confirm. The patch suppresses automatic commitment broadcasts until the funding transaction is observed on-chain, while still allowing an explicit override via a public API method.