rust-lightning

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 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 only reformats code in test/fuzz files using rustfmt. It reorders import statements and wraps a constructor call across more lines. No program behavior, logic, or security properties are changed.

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 adds a GitHub Actions automation that opens or comments on an issue when the project's main branch CI build fails. It does not change any wallet, networking, or cryptographic code. There is no direct security vulnerability in the change itself.

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.

This commit is purely a code-formatting cleanup. It removes a #[rustfmt::skip] directive and lets the Rust formatter rewrap the internal_splice_init function and its call sites. No logic, behavior, or security checks were changed.

This commit is purely a formatting cleanup. It removes a #[rustfmt::skip] annotation and lets the Rust formatter reformat the internal_tx_abort function. No code behavior, logic, or security properties were changed.

This commit is purely a code-formatting cleanup. It removes a #[rustfmt::skip] annotation and lets Rustfmt reformat the internal_splice_ack function in the Lightning channel manager. No logic, behavior, or security properties of the code were changed.

This commit is purely a code formatting cleanup. It removes a #[rustfmt::skip] annotation and lets the Rustfmt tool reformat the internal_tx_complete function in the Lightning channel manager. No logic, behavior, or security properties of the code were changed.

This commit is a minor cleanup of an internal test file. It replaces a small block of test code with an existing helper function when testing the non-zero-conf path. There is no change to production code, no security fix, and no user-facing behavior change.

This is a small documentation and test cleanup commit. It removes leftover references to a 'manually_accept_inbound_channels' configuration option from two test files and a pending changelog entry. There is no code behavior change and no security fix or vulnerability present in the diff.

This commit removes the proptest testing library from the lightning-liquidity Rust crate because one of proptest's indirect dependencies bumped its own minimum Rust version, breaking the project's MSRV (Minimum Supported Rust Version) policy. While removing the tests, the author also fixed a subtle rounding bug in the fee calculation helper: it now uses Rust's built-in div_ceil instead of the old add-999999-then-divide-by-1000000 trick. The commit also deletes a large block of URL parsing tests. There is no direct evidence this is a security fix, but the fee rounding change is a correctness improvement and the commit message explicitly notes that the previous tests were broken on most inputs.

This commit fixes a subtle file-listing bug in the Lightning payment channel data storage code. When listing saved data, the program used to ask the filesystem for fresh details about each file, which on common Linux filesystems can briefly make a file appear missing if it is being changed at the same time. The change uses cached information already returned by the directory scan, avoiding that extra check and the race condition. It is a reliability fix rather than a direct exploit, but in the worst case it could cause the node to fail to load channel data it expected to find.

This commit is a straightforward observability and metadata improvement: it adds the channel counterparty's node ID to every variant of the TransactionType enum used when LDK broadcasts on-chain transactions. It does not change transaction logic, signatures, fee calculations, or who can broadcast what. Downstream users (such as custom transaction broadcasters or monitoring tools) now get extra context about which peer is involved in each transaction. The change includes a backward-compatibility shim that fills in a dummy counterparty ID when loading older serialized data and then overwrites it once the real value is read.

This commit adds an optional extra piece of information—the counterparty's node ID—to an existing event that tells users when they have spendable on-chain outputs. It is a backward-compatible API enhancement using an odd TLV type, so older versions ignore the new field. There is no security fix or vulnerability here.

This commit is purely a code-formatting cleanup. It removes a `#[rustfmt::skip]` directive and lets Rustfmt reformat a single function in the Lightning channel manager. No behavior, logic, or security properties of the code change.

This commit changes which 'feature bit' the Lightning Dev Kit uses to advertise experimental channel splicing support. Previously it used bit 155, the same bit an older Eclair implementation used for a different, incompatible splicing design. That mismatch could cause Eclair nodes to try to splice with LDK using the wrong protocol, leading to failed message parsing and repeated reconnects. The fix moves LDK's prototype splicing flag to bit 63, avoiding the collision. It is a protocol-compatibility fix, not a cryptographic vulnerability, but it does prevent a real interoperability failure.

This commit only changes version numbers in package configuration files (Cargo.toml). It bumps crate versions from 0.2.x to 0.3.x to keep them aligned with semantic versioning rules after the underlying `lightning` crate changed its public types. There is no code change, no bug fix, and no security patch.

This commit adds a new helper function to create a UTXO descriptor for modern Taproot (P2TR) single-key spending. It is purely additive API surface with no changes to existing behavior, no bug fixes, and no security-sensitive logic beyond correctly estimating transaction weight for fee calculations.

This commit simply removes two unused import statements from Rust source files. It does not change any program logic, data handling, or security behavior. There is no security relevance.

This commit is a straightforward API refactor: it adds a TransactionType label (Funding, Close, Claim, Sweep, etc.) to every place in the Lightning Dev Kit that broadcasts a Bitcoin transaction. The actual transactions being broadcast do not change; only the metadata passed alongside them changes. There is no security vulnerability being fixed or introduced here.

This commit is a pure code refactoring: it moves an existing block of logic from one place inside a function into a newly created helper function, without changing what the logic actually does. There is no security-relevant behavior change visible in the diff.

This commit is a small internal cleanup in the Lightning Dev Kit's channel manager. It moves the handling of two optional hash-map fields from a later processing stage into the deserialization stage, so the fields are always plain hash maps after loading. The change makes the code's invariants clearer and removes a potential source of inconsistency, but it does not appear to fix an active security bug on its own.