rust-lightning

This commit is purely a code formatting and documentation cleanup of one internal function in the Lightning Dev Kit. It adds explanatory comments and rewraps long lines to match the project's style guide. No logic, calculations, or security behavior were changed.

This commit is a pure internal code reorganization. It creates a new ChannelConstraints container and copies existing channel parameters into it so a future change can pass them more easily. The values used in balance calculations are identical to before; nothing about user funds, network behavior, or security rules changes.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's transaction-building code. It replaces a few methods that always built full lists of contributed inputs and outputs with new iterator methods that let callers decide when to build those lists. There is no change to security logic, no bug fix, and no externally visible behavior change.

This commit is a routine cleanup of the project's fuzz-testing infrastructure. It changes how fuzz tests are compiled and run, adds a new way to feed test input via standard input, and removes an unused dynamic-library build mode. There is no indication it fixes or introduces a security vulnerability in the actual Lightning library code.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's Rust implementation. It removes a helper method called subtract_non_htlc_outputs from a trait and replaces its uses with direct calls to a similar helper function. The commit message explicitly states there is no functional change, and the diff shows the new helper behaves identically to the removed method. There is no indication this fixes or introduces a security issue.

This commit is a code cleanup in the Lightning Dev Kit's rust-lightning project. It removes a helper method called `commit_tx_fee_sat` from a transaction-building trait and moves the fee-checking logic into a more central place when opening channels. The goal is to keep the same behavior while simplifying the code. There is no direct evidence in the commit that this fixes a security vulnerability.

This commit is a straightforward internal code reorganization in the Lightning Dev Kit's transaction-building code. It renames and restructures a method so that a new wrapper, `get_channel_stats`, returns the same underlying commitment statistics inside a new container struct. The commit message explicitly states there are no functional changes beyond the API rename, and the diff shows only mechanical renames and field-access adjustments (e.g., `stats.nondust_htlc_count` becomes `stats.commitment_stats.nondust_htlc_count`). There is no indication of a security fix, vulnerability, or behavior change.

This commit is a preparatory refactor in LDK's payment-sending code. It adds a new `total_mpp_amount_msat` field to `RecipientOnionFields` so that, in future commits, a payer can send an HTLC that is only one part of a larger multi-part payment. For now the new field is always required and is asserted to match the existing payment amount, so behavior is unchanged. The commit also fixes a small related bug where probe payments were not including a payment preimage as intended. There is no immediate security vulnerability here; it is a feature-building change with a minor bug fix.

This commit adds safety checks inside the Lightning payment code to make sure the route finder (the 'Router') actually follows the rules it was given. Before sending a payment, the code now verifies that the chosen route does not exceed the user-set maximum fee, does not contain useless empty paths, and does not include unnecessary multi-path payment (MPP) parts. If the router misbehaves, the payment is abandoned instead of being sent. It is a defensive hardening change rather than a fix for a known active attack.

This commit is a straightforward code cleanup in the project's test suite. It replaces a Rust macro used only in tests with an equivalent regular function. There is no change to the actual Lightning node logic that runs in production, and no security-relevant behavior is altered.

This commit is a straightforward code cleanup in the project's test suite. It removes a helper macro used only in tests and replaces it with direct calls to an existing function. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix.

This commit is a straightforward code cleanup in the project's test suite. It replaces a Rust macro called `check_closed_broadcast!` with direct calls to an equivalent function. Macros are a shorthand in Rust; replacing them with normal function calls makes the test code easier to read and maintain but does not change what the tests actually do. There is no change to the live Lightning node software that users run, so this cannot affect real funds or network security.

This commit changes how a Lightning payment library runs its internal fuzz tests. It makes the test harness call the normal periodic timer function instead of a special stripped-down version, so incomplete multi-part payments time out properly during testing. The production code is mostly unchanged, but a few internal test-only helpers are now available under a new test-utilities feature flag. There is no direct evidence this fixes a real-world security bug; it appears to be a test-harness cleanup that makes fuzzing more realistic.

This commit updates a fuzzing test harness (chanmon_consistency) in the Lightning Dev Kit project. It adds the ability to simulate confirming splice transactions on a fake blockchain and fixes a serial ID collision in the test's random number generator. The changes are confined to test/fuzzing code and do not alter production Lightning logic.

This commit only changes test and fuzzing code. It adds new test controls that let developers temporarily disable or enable individual signer operations during fuzz testing, and it removes one unused signer-operation flag. There is no change to production Lightning code, so it does not create a real-world security vulnerability or fix one.

This patch fixes a bug in the Lightning Dev Kit where, after a special quiet period called 'quiescence' used during splicing (modifying a channel's funds), some queued payment updates were not released when the quiet period ended via the 'tx_signatures' message exchange. The fix ensures those queued updates are freed and processed, preventing payment delays or stalls during splice operations.

This commit is a code cleanup in the Lightning Dev Kit's Rust library. It changes how a wallet interface called CoinSelectionSource is used in function signatures. Instead of requiring that a wallet type be a pointer-like wrapper (Deref) around something that implements CoinSelectionSource, the commit makes CoinSelectionSource directly implementable for any pointer-like wrapper. This simplifies the API and removes an internal wrapper struct, but it does not fix a security bug or change runtime behavior in a way that would affect funds or network safety.

This commit is a pure code reorganization: it renames the internal primary type from FundingTxInput to ConfirmedUtxo and makes FundingTxInput a backward-compatible alias. No behavior, logic, or security properties change. It is not a security fix.

This commit is a straightforward code reorganization. It moves synchronous wallet helper code from one module (bump_transaction::sync) into a shared utility module (util::wallet_utils) so it can be reused by channel funding and splicing features. No security-relevant behavior is changed; only import paths and module locations are adjusted.

This commit is a pure code reorganization: it moves wallet-related types and traits (for choosing which coins to spend in Bitcoin transactions) from one internal module to a new dedicated module. There are no functional changes, no bug fixes, and no security patches visible in the diff.

This commit changes how Lightning Dev Kit handles 'change' money during Bitcoin channel splicing. Previously, the user could provide a change address or LDK would generate one itself. Now, the wallet's coin-selection logic decides whether a change output is needed and what it looks like. The commit keeps a fallback for older stored data that may not include a change script. It is a code-quality and consistency improvement rather than a clear security fix, though it reduces the chance of fee or change-output mistakes during splicing.

This commit refactors how Lightning channel 'splicing' is started. Instead of requiring the user to manually pick coins and hand them to the API, it splits the process into two steps: first the library returns a 'funding template', then the user's wallet automatically selects coins through a standard trait and the result is handed back. The change is mostly an API usability improvement and moves fee-estimation/validation code into a dedicated module. There is no direct evidence in the commit that it fixes a security vulnerability; it is a design/API change.

This commit changes how a wallet picks coins to spend when building Bitcoin transactions. Previously, every coin selection had to be tied to a specific 'claim ID' used to avoid accidentally spending the same coin twice across different claims. Now the claim ID is optional so the same code can be reused for a new feature called 'splicing.' When no claim ID is provided, the code is designed to treat the spend as unique and avoid double-spending locked coins. The change includes safety checks to skip the 'force conflicting spend' path when there is no claim ID.

This commit refactors how the Lightning Dev Kit (LDK) selects coins for on-chain Bitcoin transactions. It changes the internal data structure used during coin selection so that each selected coin now carries the full previous transaction that created it, not just the coin's own details. The main stated reason is to prepare for a future feature called 'splicing.' The commit also adds a new wallet method to look up those previous transactions on demand. There is no direct evidence in the commit that this fixes an active security bug, but it does touch code that handles real money (transaction fees and UTXOs) and changes a public wallet interface, so downstream implementers need to update their code.

This commit is a straightforward internal code reorganization in the Lightning Dev Kit's Rust library. It moves the 'sequence' field (a Bitcoin transaction detail that controls things like replace-by-fee) from one internal data structure called FundingTxInput into another called Utxo. The change is preparation for future work on splicing (a way to resize a Lightning channel) and avoids unnecessary lookups of previous transactions. There is no indication this fixes a security vulnerability or introduces a new attack path.