rust-lightning

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

This commit adds internal bookkeeping to LDK's channel monitor so it can tell whether a channel uses 'manual' funding-transaction broadcasts and whether that funding transaction has actually appeared on-chain yet. The goal is to stop the node from broadcasting its own commitment transaction (a recovery/closing transaction) before the funding transaction exists on-chain, which would be pointless and could leak information or waste fees. It is a defensive correctness fix, not a patch for an active exploit.

This commit fixes a bookkeeping flag in the Lightning channel monitor. The flag `funding_seen_onchain` was not being set when the funding transaction was observed on the blockchain, even though the code already detected it. Setting the flag correctly helps the monitor know the channel is real on-chain and may affect later safety decisions, such as whether to accept certain updates or how to handle edge cases during channel closure.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `broadcast_latest_holder_commitment_txn` function. There is no change to program logic, behavior, or security.

This commit adjusts a CI test script to pin an older version of a Rust testing library called proptest, because the newly released version requires a newer Rust compiler than the project supports. It is a build/test infrastructure change with no security relevance.

This commit updates a test-only dependency version and removes a workaround pin for another dependency. It does not change production code, user-facing behavior, or any security-sensitive logic. There is no indication this is a security fix.

This commit only fixes documentation comments and a typo in a test-only assertion message. It does not change any executable code, cryptographic logic, or network behavior. There is no security issue here.

This commit fixes a race condition in how the Lightning networking code pauses and resumes reading from a peer's connection. Previously, the code could tell a caller to pause reading, but by the time the caller acted on it, the reason to pause had already gone away. This could leave a peer connection stuck: no new messages would be read, and because nothing was being sent either, there was no later signal to resume reading. The fix moves the pause/resume signal into the same path used to send data, so the two cannot get out of sync. The commit also notes a small new risk: a very fast message flood could briefly bloat memory before the next processing cycle pauses reads.

This commit tightens the rules for how Lightning Dev Kit hands groups of Bitcoin transactions to external broadcasting code. Previously, a broadcaster might have received several unrelated transactions or multiple 'child' transactions in one batch, and the documentation only said they 'may or may not' depend on each other. The change guarantees that any batch with more than one transaction is exactly one child transaction plus the parent transactions it depends on. It also updates LDK's own test broadcaster to verify this shape and fixes a test so its fake anchor transaction actually spends the commitment transaction, matching the new guarantee. The main risk is that real broadcaster implementations which relied on the old, looser behavior could have submitted invalid packages to Bitcoin Core's submitpackage RPC, causing broadcasts to fail rather than enabling theft of funds directly.