rust-lightning

This commit is a routine internal code cleanup in the Lightning Dev Kit's Rust implementation. It removes a wrapper type called ChannelSignerType that previously distinguished between different kinds of channel signers, because the project now plans to support only one signer type (ECDSA). The change simplifies function signatures and removes now-unnecessary pattern matching, but does not fix a security bug or change cryptographic behavior.

This commit removes an unused experimental Taproot/MuSig2 code path from the rust-lightning project. It deletes the optional `musig2` dependency, removes the `taproot` build flag, and strips out all conditional Taproot-related message fields and serialization logic. There is no indication this fixes a security vulnerability; it is a cleanup change because Taproot support is not currently planned and the external `musig2` crate is now owned by a third party.

This commit removes an unfinished Taproot-specific signer type from the Lightning Dev Kit codebase. The removed code was behind a special compile-time flag ('taproot') and consisted almost entirely of placeholder 'todo!()' stubs that did not actually sign anything. The change is a cleanup/refactoring step toward having one unified channel signer type, not a security fix.

This commit fixes a bug in the Lightning Dev Kit's splicing feature. When a user tries to resize a Lightning channel (a 'splice') and the attempt fails, the software tells the user which bitcoins (UTXOs) are no longer tied up so they can spend them again. The bug was that during a follow-up fee-bump attempt (RBF), the software could incorrectly tell the user that UTXOs from the original splice attempt were free to spend, even though they were still needed. This could lead a user to accidentally double-spend their own funds and lose money. The fix filters out any UTXOs that are still committed to an earlier splice attempt before reporting the failed ones.

This commit fixes a bug in Lightning Dev Kit's splicing/RBF logic. When one party tried to speed up or replace a splice transaction (an RBF), and the other party had not queued a new contribution, the other party's original funds could be silently dropped from the new transaction. The fix remembers each side's last contribution and re-uses it automatically, or rejects the RBF if the new fee rate makes the old contribution impossible. Without the fix, a counterparty could potentially strip the victim's funds out of a splice, causing loss of funds or channel disruption.

This patch fixes a bug in the Lightning Dev Kit's splicing feature. When a user tries to add funds to a channel while another splice negotiation is already ongoing, the code could mistakenly treat coins that are already locked into the earlier splice as 'reclaimable.' That could let a user discard or reclaim UTXOs that should stay reserved, potentially causing inconsistent channel state or loss of funds in edge cases.

This commit fixes how a Lightning node responds when a peer proposes a splice or RBF transaction fee rate that is too high for the node to afford. Previously, the node would silently drop its own contribution and continue, which could let the peer push through an unexpectedly expensive transaction. Now the node explicitly rejects the splice with a warning and disconnects when the fee rate is too high, while still allowing lower or retryable cases to proceed safely.

This commit fixes a bug in Lightning Dev Kit's splicing/RBF (Replace-By-Fee) logic. When both channel partners tried to update a splice at the same time, the loser of a tie-breaker was supposed to contribute its inputs/outputs as the 'acceptor' of the RBF transaction, but the code incorrectly made the acceptor contribute nothing. The patch makes the acceptor include its queued splice contribution in the RBF transaction and report it in the response. It is a protocol-correctness bug that could cause stuck or inconsistent splice states, but it is not a clear theft-of-funds vulnerability.

This commit adds support in the Lightning Dev Kit for handling a specific protocol message (tx_ack_rbf) when a channel participant initiates a fee-bump (RBF) of a pending splice transaction. Previously, receiving this message caused an error. The change also fixes a related bug where resetting splice state could incorrectly discard a completed signing session from an earlier round, which could trigger a debug assertion. The commit is primarily a feature implementation with a defensive bugfix, not a disclosed security vulnerability.

This commit fixes a logic bug in the Lightning Dev Kit's splicing protocol. Previously, if a node tried to RBF (bump the fee of) a pending splice, it would incorrectly send a new splice_init message instead of tx_init_rbf, which could cause the peer to disconnect or the protocol to fail. The change makes the node detect when a splice is already pending and send the correct RBF message instead. It is a protocol correctness fix rather than a critical security vulnerability.

This commit adds a new public API called rbf_channel to the Lightning Dev Kit's rust-lightning library. It lets a user bump the transaction fee (via replace-by-fee, or RBF) on a pending splice funding transaction before it is locked on-chain. The change is a feature addition, not a bug fix, and includes several safety checks such as requiring a pending splice, no active funding negotiation, and a minimum 25/24 feerate increase over the previous attempt. There is no direct evidence in the commit that this fixes a security vulnerability.

This commit adds the ability for one side of a Lightning channel (the 'acceptor') to accept a fee-bump request for a pending splice transaction. Previously, such requests were rejected outright. The change is a partial feature implementation: only the acceptor side is implemented, and the code includes several safety checks to prevent misuse. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be a protocol feature enhancement.

This change fixes a logic bug in how Bitcoin Lightning channels handle 'splicing' (a way to resize a channel's on-chain funds). Previously, the code blocked all new funding entries while any splice was still pending, which accidentally prevented valid 'Replace-By-Fee' (RBF) attempts—multiple competing versions of the same splice meant to speed up confirmation. The patch relaxes the rule so only splices that spend from a *different* parent funding transaction are rejected. This is a correctness/functional fix rather than a clear-cut security vulnerability, but the overly strict check could have caused operational failures around unconfirmed splices.

This commit is purely a code-formatting cleanup. It removes a directive that told rustfmt to skip the file and then reformats the test code to match the project's style rules. No program logic, security behavior, or functionality was changed.

This commit changes a GitHub Actions workflow so that an AI code-review bot receives an explicit GitHub access token. The stated goal is to fix a CI failure, but passing the default repository token to a third-party action can broaden what that action is able to do inside the repository. There is no evidence in the commit that this was done for malicious reasons or that the action misuses the token.

This commit fixes a bug in the Lightning Dev Kit's splicing code. When two Lightning nodes tried to update ('splice') a channel together and the negotiation failed, only the node that started the splice got a notification to reclaim its locked-up bitcoins. The other node (the 'acceptor') was silently left without any event, so its wallet software wouldn't know it needed to reclaim its contributed coins. The patch now emits the proper failure event for the acceptor too, but only when the acceptor actually contributed something.

This commit adds a new GitHub Actions workflow that uses an Anthropic Claude AI assistant to automatically review pull requests. It is a CI/automation change, not a code change to the Lightning library itself. There is no direct security vulnerability in the diff, though any automated tool granted pull-request write permissions introduces a future supply-chain and permissions-management consideration.

This commit only adds a non-code guideline to a project documentation file (CLAUDE.md), instructing an AI coding assistant to avoid repeating code. It makes no changes to actual software, so it has no security effect on users of the project.

This commit is a routine cleanup of a CI shell script. It removes redundant test and documentation steps and updates stale log messages. There is no security relevance.

This commit tightens validation of BOLT 12 Lightning offers so that an offer cannot specify a payment amount of zero. Previously, zero-amount offers could be built or parsed successfully, which the BOLT 12 specification now forbids. The change prevents users or automated systems from accidentally creating or accepting offers that request no payment, which could be used to confuse wallets, trigger unexpected behavior, or probe nodes.

This patch fixes a restart-related bug in how the Lightning node resumes claiming forwarded trampoline payments. Previously, after a restart, trampoline payments that needed to be claimed on-chain might not have been processed correctly because the code only looked at single-hop previous channels and ignored trampoline forwards that bundle multiple incoming hops. The fix reuses existing replay logic so those bundled incoming hops are also claimed. A user-visible effect could be that funds from a trampoline forward were temporarily stuck or not recovered automatically after a crash/restart.

This commit removes a fallback code path in LDK that previously tried to replay old Lightning payment claims even when the software didn't know which peer (counterparty) the claim was for. That missing information could cause crashes or unreliable behavior. Now, if the required peer ID is absent, LDK refuses to load the channel state and logs an error, forcing users to resolve those old forwards before upgrading. It is a hardening/cleanup change rather than a fix for an active exploit.

This commit fills in a previously unimplemented 'todo!' placeholder in the Lightning Dev Kit's channel recovery logic. When a node restarts and rebuilds its state from channel monitors, it now properly handles HTLCs (pending payments) that arrived as Trampoline forwards. Before this change, such forwards would have caused a panic during recovery, potentially preventing the node from restarting cleanly and possibly leaving forwarded payments stuck or lost.

This commit is a straightforward code cleanup: it moves existing HTLC recovery logic into a new helper function without changing what the logic actually does. There is no visible security fix or behavior change.

This commit fills in a previously unimplemented 'todo!' placeholder for handling failed trampoline-routed payments. When a trampoline forward fails, the node now properly reports the failure back through each incoming payment hop using a standard temporary trampoline failure message, instead of crashing. This is a robustness improvement that prevents a panic path and ensures correct Lightning protocol behavior for an in-development feature.