rust-lightning

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 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 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 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 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 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 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.

This commit is a pure code cleanup: it extracts existing HTLC failure-handling logic into a new helper function and a small closure, with no functional changes. There is no security fix or behavior change visible in the diff.

This commit finishes a previously unimplemented code path for 'trampoline routing' in the Lightning Dev Kit. Before this change, if a payment arrived via a trampoline forward, the software had a placeholder 'todo!()' where it should claim the funds. The commit adds the actual claiming logic, including safety checks that prevent the next channel step from proceeding until the incoming payment proof is durably saved. It is a feature-completion patch with defensive safety logic, not a fix for a known active vulnerability.

This commit is a code cleanup (refactor) inside the Lightning Dev Kit's channel manager. It moves the creation of a 'PaymentForwarded' event out of an internal helper function and into the caller by passing a closure. The actual logic for normal forwards is preserved unchanged; the change is preparing the code for future 'trampoline' forwarding support. There is no indication this fixes a security bug or introduces a vulnerability.

This commit is a pure code reorganization (refactor) in the Lightning Dev Kit's channel manager. It extracts existing HTLC forwarding claim logic into a new helper function so the same code can be reused for an upcoming 'trampoline forwarding' feature. No behavior changes, bug fixes, or security-sensitive modifications are present in the diff.

This commit is a small internal cleanup in a Lightning Network library. It adds a helper method so the code can pick the correct failure classification (regular forward vs. trampoline forward) based on where an HTLC came from, instead of always assuming a regular forward. The commit message explicitly says the wrong value for the node’s own outbound payments was already not used, so this is mostly preparatory/refactoring work rather than a fix for an active security bug.

This commit adds a new internal bookkeeping variant called TrampolineForward to LDK's HTLCSource enum, which tracks Lightning payments being forwarded through a trampoline routing node. It also adds placeholder 'todo!()' stubs in several code paths that are not yet implemented for this new variant. The commit is part of ongoing trampoline-payment feature work and does not by itself fix a known security bug. The unimplemented stubs could, in theory, cause a panic if a trampoline forward reaches those code paths, but the commit message and diff treat this as expected incomplete functionality rather than a disclosed vulnerability.

This commit adds a new internal identifier type for tracking forwarded Lightning payments that use Trampoline routing. It is a small, structural code change that does not appear to fix or introduce a security vulnerability on its own. It simply lets the software distinguish Trampoline forwards from other kinds of payment routes when recording which HTLCs were sent.