rust-lightning

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 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 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 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 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 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 fixes a bug in how the Lightning Dev Kit (LDK) handles key rotation when splicing a channel. Splicing is a way to resize a Lightning channel on-chain. The protocol only allows changing the 'funding key' during a splice, but LDK was accidentally asking the signer for a whole new set of keys. This could cause signature mismatches and break splicing. The fix adds a dedicated method to rotate only the funding key and keeps all other keys unchanged.

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.

A single boolean argument in a function call was corrected during a process called 'splicing' (a way to resize a Lightning channel). The argument tells the code whether the local side is the one creating the commitment transaction. The commit message says this doesn't actually change the resulting transaction during splicing, because no pending payment updates are happening, but it is still correct to pass the right value. There is no clear security vulnerability here.

This commit fixes a bug where a specially crafted network message could cause the Lightning Dev Kit software to crash. The crash happens while reading a time duration from the message. The fix rejects obviously invalid duration values before they can trigger the crash. The bug was discovered by an automated fuzz tester, not a reported real-world attack.

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 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 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 fixes a protocol-handling gap for zero-confirmation channel splices in the Lightning Dev Kit. When two peers agree to a splice that does not require waiting for blockchain confirmations, the node now immediately sends a 'splice_locked' message right after exchanging transaction signatures. Previously, this message was only sent after blocks were mined, which could leave a 0-conf splice stuck and unusable. The change is a correctness fix in the Lightning state machine rather than a patch for a remote exploit.

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 fixes a bug in the Lightning Dev Kit where a wallet reload could silently drop an in-progress channel splice. Previously, if the program restarted while a splice was in an early negotiation state, the user would never receive a 'SpliceFailed' event, so their funds could appear stuck or the failure could go unnoticed. The fix temporarily saves a failure event during persistence so it can be emitted after the reload, then removes it from storage. It is a reliability/notification fix, not a direct theft or remote-exploitation vulnerability.

This change fixes a bookkeeping bug in the Lightning Dev Kit's splicing feature. When a peer disconnects while a splice is being negotiated (but before signatures are exchanged), the software now emits a SpliceFailed event so the user's wallet knows the splice attempt is dead and can unlock any reserved funds. Previously, the internal splice state was reset on disconnect but no event was emitted, which could leave a wallet waiting indefinitely for a splice that would never complete.

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 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 adds a new notification event called SpliceFailed to the Lightning Dev Kit library. It tells users when a channel splice (a way to resize a Lightning channel) failed before any funding transaction was signed, and lists which bitcoin inputs and outputs can be reused. There is no direct security fix here; it is a user-facing bookkeeping improvement.