rust-lightning

This commit is a routine code cleanup in the Lightning Dev Kit Rust library. It takes advantage of a newer Rust language feature (available since Rust 1.75) to remove unnecessary 'Box' heap allocations around futures returned from certain trait methods. There is no indication this change fixes a security bug or introduces a vulnerability; it is a refactoring to simplify the code and reduce allocations.

This is a one-line change that adds a Rust compiler feature gate to silence a warning. It does not change program behavior or fix any security issue.

This commit only changes internal test helper code in the Lightning Dev Kit repository. It extends a test macro and a test reconnection helper so that automated tests can optionally capture and forward a `tx_abort` message during channel re-establishment scenarios. No production code is modified, and there is no indication this fixes or introduces a security issue.

This commit only copies documentation comments from asynchronous Rust traits and structs to their synchronous counterparts. It fixes broken documentation links and adds notes reminding developers to keep both versions in sync. No code behavior changes.

This commit only adds a documentation comment to a Rust trait method. It does not change any code behavior, logic, or security properties. The added text explains that the method returns a script pubkey usable as a change destination and references another function.

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

This commit only changes a test helper used during development. It adds an internal guard so that a mock signer in the test suite panics if its public keys are fetched more than once. It does not change production code, network behavior, or wallet security. There is no indication this fixes a real vulnerability.

This commit removes a small helper trait called AddSigned and replaces its use with equivalent built-in Rust methods (checked_add_signed and saturating_add_signed on u64). The behavior of the code is unchanged; it is a cleanup made possible by raising the minimum supported Rust version. There is no security issue here.

This commit only adds a minimum supported Rust compiler version (1.75) to the package metadata for every crate in the project. It does not change any executable code, fix a bug, or alter runtime behavior. It is a build/tooling metadata change with no direct security relevance.

This commit removes unused data fields from test-only helper code in the rust-lightning project. It does not change any production code, network behavior, or cryptographic logic. There is no security relevance.

This commit raises the Minimum Supported Rust Version (MSRV) from 1.63.0 to 1.75.0 for the rust-lightning project. It updates CI configuration, documentation, linting rules, and dependency pinning scripts. It also replaces older Rust idioms with newer, cleaner equivalents (such as using div_ceil and is_some_and methods) that require the newer compiler version. There is no security fix or vulnerability being patched here.

This commit only changes test code. It updates a test helper macro and related reconnection tests to capture and optionally handle 'stfu' messages sent when Lightning channels reconnect. There is no change to production code, so it does not introduce or fix a security vulnerability on its own.

This commit is a routine documentation build fix. It swaps one Rust compiler feature flag used only when building documentation on docs.rs (`doc_auto_cfg`) for another (`doc_cfg`) because the old one was removed/merged in the Rust toolchain. It does not change any runtime code, network behavior, or security logic.

This commit adds a new public helper method that lets users of the Lightning Dev Kit wallet generate a list of Bitcoin addresses (script_pubkeys) where their funds could end up if a channel counterparty force-closes a channel. It is a recovery/scanning feature, not a bug fix or vulnerability. The change also adds a test-only assertion to make sure the generated list actually contains the expected address when signing a counterparty payment.

This commit is a simple rename of an internal function from get_counterparty_payment_script to get_countersigner_payment_script, plus an update to its documentation. The old name was misleading because the function actually returns the payment script for the non-broadcaster in a commitment transaction, which can be either party. No behavior of the code changes, and there is no security fix or vulnerability here.

This commit only adds new test code for the Lightning channel re-establishment flow during a splice. It does not change production logic, so it introduces no direct security vulnerability. The tests verify that nodes correctly retransmit messages after a disconnect while splicing a channel.