rust-lightning

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.

This commit adds a new event variant so the software can report when it fails to forward a special kind of Lightning payment called a 'trampoline' payment. It is purely an observability/logging change and does not alter how payments are handled, accepted, or rejected. There is no indication it fixes a security bug.

This commit is a straightforward internal API and data-format change in the Lightning Dev Kit. It changes one field in an event from holding a single channel identifier to holding a list of channel identifiers, so that future trampoline-routing failures can report all related channels at once. It also adds backward-compatible serialization logic so older versions can still read the new event format. There is no indication this fixes an active security bug; it is preparatory refactoring.

This commit is a simple rename of an internal code label from FreeOtherChannelImmediately to FreeDuplicateClaimImmediately, plus matching comment updates. It does not change program behavior, fix a bug, or alter any security logic.

This commit tightens an internal data structure in the Lightning Dev Kit so that a channel identifier is always required when releasing a blocked channel after a monitor update. Previously the channel field was optional, which could have allowed creating an action that neither emitted an event nor freed a channel—an empty no-op. The change removes that possibility and updates serialization to treat the field as required, reflecting that older versions without it are no longer supported for direct upgrades.

This commit is a simple code cleanup: it renames an internal enum variant from EmitEventAndFreeOtherChannel to EmitEventOptionAndFreeOtherChannel to better reflect that the event field is optional. No behavior changes, no security fixes, and no bug fixes are present.

This commit changes how Lightning Dev Kit stores an internal event record when a payment is forwarded, specifically for an upcoming feature called trampoline payments. It makes one field optional so that future code can avoid emitting duplicate events when multiple incoming payments are part of the same trampoline forward. The change is forward-compatible but not backward-compatible: older versions of LDK will expect the field to always be present, so downgrading while trampoline forwards are in progress is not supported. There is no direct security vulnerability in this patch; it is a data-format change to enable a future feature.

This commit is a routine API refactor in the Lightning Dev Kit. It changes how a 'payment forwarded' event reports the incoming and outgoing payment channels, grouping them into lists so that future 'trampoline' routing can report multiple parts. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a feature/structural improvement.

This commit only edits a project documentation file (CLAUDE.md) that gives coding guidelines for AI assistants. It changes wording about when to run code formatting and adds a guideline about writing self-contained comments. No program code, build scripts, tests, or security-relevant configuration were modified.

This commit fixes a harmless but incorrect internal sanity check (a debug-only assertion) in the Lightning Dev Kit's code that handles duplicate routing announcements. The assertion could fire in a legitimate race condition even though nothing was wrong. The fix replaces the overly broad assertion with a more precise one that only complains if the program state is genuinely inconsistent. It is not a security vulnerability and cannot be exploited by an attacker.

This commit is a test-only refactor. It rewrites a helper function in the splicing test suite to use a cleaner match statement and adds assertions that expected test inputs/outputs were actually sent. It does not change production code, cryptographic logic, network handling, or any behavior that could affect real users' funds or node security.

This commit changes how the Lightning Dev Kit handles a rare situation where both sides of a channel try to splice funds at the same time. Previously, the node that lost the tie-breaker would sit out and start a second splice later. Now, the loser contributes its funds to the winner's splice as an 'acceptor,' combining both into one transaction. The change also adjusts fees and change outputs when the winner's chosen fee rate differs from what the loser expected. This is a protocol optimization, not a clear security fix, but it touches fee accounting and transaction construction, which are sensitive areas.

This commit fixes a fee-calculation bug in Lightning splicing. Previously, when both sides tried to splice at the same time, the loser of a tie-break (the 'acceptor') built their contribution as if they were going to pay for the whole shared transaction. That made them overpay fees, and a high fee rate chosen by the other side could drain more from their wallet than intended or even make the transaction invalid. The patch adds logic to re-estimate fees from the acceptor's perspective and lets users set a maximum fee rate they are willing to accept.

This commit fixes a fee-estimation bug in rust-lightning's channel funding and splicing code. When building a transaction that creates a change output, the code previously forgot to include the change output's size/weight when estimating the required transaction fee. That made the fee estimate slightly too low. The patch adds the missing weight and adds a test showing that a contribution with barely enough money would now be correctly rejected, whereas before it might have been accepted and later failed to broadcast or confirm reliably.

This commit refactors how an internal transaction-construction object is created in the Lightning Dev Kit. It splits one constructor into two separate ones for the party that starts the process versus the party that responds. The main practical effect is that callers no longer have to handle an error right after they have already committed to starting a splice, which avoids a tricky cleanup situation where they might otherwise have to emit a failure event after consuming internal state. It is a defensive code-quality change rather than a fix for a known active exploit.

This commit removes old, no-longer-used code paths for splicing (a way to resize a Lightning channel). It stops saving a 'quiescent action' to disk because the only remaining variant cannot be serialized, and it drops legacy change-output calculation logic. On loading old data, the stored action is read and then discarded, and the 'awaiting quiescence' flag is cleared so the node does not get stuck waiting for something it can no longer act upon. The change is mostly cleanup and hardening against stale persisted state.

This commit fixes a consistency bug in a file-based storage component used by Lightning Dev Kit. A paginated listing function was including temporary files and stray directories as if they were real data keys, which could confuse callers, leak internal filenames, or cause errors when reading back data. The fix makes the paginated listing skip the same non-key entries that the non-paginated listing already skipped.

This commit only updates documentation comments and tightens an internal consistency check for a special routing feature (Trampoline payments). It does not change any security-sensitive behavior or fix a vulnerability. The change makes the code's internal assertion stricter (requiring exact equality rather than 'not greater than') when trampoline hops are present, but this is a correctness/clarity improvement, not a security fix.

This is a tiny internal code cleanup: it replaces a manual loop that adds up CLTV expiry deltas with a new helper method that does the same thing. There is no functional change and no security relevance visible in the commit.

This commit fixes a balance-checking gap in the Lightning Dev Kit's channel splicing logic. When a channel is spliced, the code now verifies that the funder still has enough funds set aside to cover a sudden fee increase, mirroring a check already performed when adding HTLCs. Without this check, a funder could splice out too much money, leaving the channel unable to pay higher fees later and potentially making it unusable or forcing a closure. The change only affects channels that do not use zero-fee HTLC transactions.

This is a minor code cleanup that removes an unnecessary clone of string keys when building a paginated list response. It changes the order of operations so the same data is moved rather than duplicated, with no functional change to behavior or outputs.

This change fixes a bug in the file storage component where errors from checking a file's metadata (such as permission denied or disk I/O problems) were silently ignored. Now, most unexpected errors are reported up the chain instead of being swallowed, so the software can react appropriately rather than silently losing information about file modification times.