rust-lightning

This commit is a small internal cleanup in a Bitcoin Lightning Network library. It removes an unnecessary 'persistence notification' wrapper from a function called splice_channel because that function now only reads data instead of changing it. There is no indication this fixes a security bug or introduces a vulnerability.

This commit fixes a bug in the Lightning Dev Kit where a channel that had paused normal traffic to negotiate a transaction (called 'quiescence') could fail to resume normal traffic if the negotiation broke due to an invalid message. Payments or other updates that were queued during the pause could get stuck until the channel was closed. The fix makes sure those queued items are released when the negotiation aborts.

This commit removes an unused flag called is_initiator from internal funding/splicing data structures. The code now assumes the creator of a FundingContribution is always the splice initiator when estimating transaction fees, which the commit message says is intentionally conservative (it may overestimate fees rather than underestimate them). There is no direct evidence this fixes an exploitable vulnerability; it appears to be a code-cleanup/refactoring change with a minor behavioral shift in fee estimation.

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 is a minor code cleanup change. It moves logging messages into a single function and simplifies the function's return type by removing an error string. There is no security impact.

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 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 simply reorganizes a GitHub Actions workflow file. It moves a shell script linting check (shellcheck) from the build job to a dedicated linting job. There is no change to the actual Rust Lightning code, no security fix, and no change in what is being checked—only where in the CI pipeline the check runs.

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 changes a single internal version number constant from 5 to 2. It is a cleanup/refactoring change with no security relevance. The constant tracks which serialization format version of a Lightning node manager can reconstruct payment forwarding data from channel data. Lowering the number from 5 to 2 simply reflects that intermediate version bumps turned out not to be needed. There is no bug fix, no vulnerability patch, and no change to cryptographic or network behavior.

This commit is a new regression test, not a fix. It verifies that a forwarding Lightning node can still claim two parts of a multi-path payment backwards after restarting, even if the node's temporary 'holding cell' state was lost during the crash. The test infrastructure was updated so the test can observe messages released from the holding cell during protocol exchanges. There is no production code change here.

This commit fixes a bug where a forwarding Lightning node, after restarting mid-payment, could emit a 'PaymentForwarded' event that was missing the identifier (next_user_channel_id) of the next channel the payment went through. The fix ensures the identifier is correctly looked up from the still-open channel state during startup. It is a data-correctness bug, not a direct loss-of-funds vulnerability, but it could break downstream accounting or automation that relies on this field.

This commit fixes a bug in the Lightning Dev Kit where, after a node restarts, it was using the wrong payment channel's details when reconstructing forwarded payments. Specifically, it used the upstream (incoming) channel's information where it should have used the downstream (outgoing) channel's. This could cause incorrect data in PaymentForwarded events and potentially wrong decisions about whether the downstream channel is closed, but it does not appear to allow theft of funds or direct remote exploitation.

This commit fixes a data-loss bug in the Lightning Dev Kit (LDK) routing/payment-forwarding logic. When LDK forwards a payment through a node and then restarts, it may need to claim the inbound payment (HTLC) even though the outbound side has already been settled. Previously, after restart LDK only remembered the outbound amount, not which outbound channel or peer the payment went to. That meant it could emit an incomplete or incorrect 'PaymentForwarded' event and possibly mishandle the post-restart claim. The patch now persists the full outbound hop details (channel ID, peer, funding outpoint, user channel ID, and amount) inside the stored inbound HTLC state so the event can be reconstructed correctly after restart.

This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It adds a placeholder field called user_channel_id to a list of pending payment claims that get replayed when the node starts up. The commit explicitly says the field is always set to None for now and that a future change will actually populate it. There is no security-relevant behavior change in this patch itself.

This is a purely cosmetic code cleanup. It renames local variables in the ChannelManager deserialization code from 'hop_data' to 'prev_hop' and 'is_channel_closed' to 'is_downstream_closed' to make a future change easier to read. No logic, behavior, or security properties change.

This commit changes how the Lightning node picks which payment channel to advertise when creating compact 'blinded paths' for private routing. Previously it picked the oldest channel; now it picks the channel with the highest local balance. The stated goal is to choose a channel most likely to remain open and usable, improving reliability of incoming payments rather than fixing a security flaw.

This commit removes a default cap on how large an incoming Lightning channel can be. Previously, LDK advertised support for large ('Wumbo') channels but would still reject them unless the user manually raised a hidden limit. The change makes the advertised behavior real: large inbound channels are now accepted by default. It is a behavior change, not a buffer-overflow or key-theft bug, but it could surprise users who relied on the old implicit cap to limit their financial exposure.