rust-lightning

This commit tightens error handling during Bitcoin Lightning channel splicing. Previously, if the software could not compute the user's current channel balance, it would silently skip a fee-rate optimization and re-run coin selection. Now it treats that balance-computation failure as a hard error and refuses to splice. This prevents the code from proceeding with potentially incorrect fee calculations when the channel is in an unexpected state, but it is a defensive hardening change rather than a fix for a known exploitable bug.

This commit fixes a tiny but real arithmetic bug in how Lightning splicing/RBF transactions decide the minimum acceptable fee rate. The code was using ceiling division (rounding up) when the Lightning specification says to round down. That made the minimum fee 1 satoshi per kiloweight-unit too high in some cases, which could cause a node to wrongly reject a counterparty's valid fee-bump attempt. The fix changes one division operation from 'round up' to 'round down' and updates the related tests.

This commit tightens the rules a Lightning node uses when a peer tries to speed up or replace a funding transaction (an RBF attempt). Previously, the node accepted any feerate that was at least 25/24 of the previous one, even if that increase was tiny in absolute terms. The new code also requires the new feerate to be at least 25 sat/kwu higher than the previous one, matching what the protocol spec now says. This prevents a peer from getting a transaction stuck or delayed by bumping the fee by only a fraction when the absolute bump is too small to be relayed by the Bitcoin network.

This commit only exposes an existing internal calculation as a new public field in channel information structures. It does not change any security logic, limits, or behavior; it merely makes the current 'dust exposure' value readable by users of the library. There is no indication of a vulnerability being fixed.

This commit simply adds two public getter methods that expose internal scoring objects for reading. It does not change any logic, permissions, or behavior. There is no security issue visible in the diff.

This commit is a test-only refactor. It moves a helper function that builds synthetic blinded payment paths for trampoline routing tests into a shared test utilities file and generalizes it so it can be reused for both forwarding and single-hop receiving test scenarios. There is no change to production code, no bug fix, and no security relevance.

This commit adds a new internal test-only helper function to create a special kind of private payment path (called a 'trampoline blinded path') in the Lightning Dev Kit library. It does not change any existing behavior, fix a bug, or expose new public functionality to users. There is no indication this is a security patch.

This commit is a routine internal code cleanup in the rust-lightning library. It makes the construction of blinded payment paths generic so the same helper functions can be used for both regular Lightning paths and newer 'trampoline' paths. It does not change any security behavior, fix a bug, or alter how data is validated. The change is purely about organizing the code more cleanly.

This commit is a code refactor that prepares for future 'trampoline' Lightning payments. It changes an internal CLTV (timelock) check so the caller can specify a minimum time delta, instead of always using a hardcoded minimum. The commit itself does not enable trampoline payments or change live behavior; it only adds flexibility for a future feature. There is no direct evidence this fixes an active security bug.

This is a straightforward internal code cleanup (refactor) in the Lightning payment handling code. It introduces a small generic trait so that the same multi-part payment logic can be reused for a future feature (trampoline payments). No user-facing behavior changes are visible in the diff, and no security bug is being fixed.

This commit is a code cleanup that moves existing payment-receiving checks into a new helper method. It does not change the security behavior of the program; it only reorganizes the code so the same logic can be reused later for trampoline payments. No vulnerability is introduced or fixed.

This commit is a pure internal code cleanup in the Lightning payment handling logic. It moves some data preparation earlier in the code and simplifies a helper macro so that a later commit can take ownership of an HTLC (a payment packet) before the macro is called. There is no functional change to how payments are accepted or rejected, and no security bug is fixed or introduced here.

This commit is a simple internal code cleanup. It moves an existing check that decides when an in-flight payment has waited too long on the blockchain into a reusable helper method. No behavior changes; it just prepares the code for future reuse with trampoline multi-part payments.

This is a code cleanup (refactor) that moves the multi-part payment (MPP) timeout logic into a reusable helper function. The commit message notes a tiny behavior change in when timeout ticks are counted, but explicitly states this makes no practical difference because fully received payments are never timed out anyway. There is no indication of a security fix or vulnerability.

This commit is a straightforward internal code reorganization in the Lightning Dev Kit's channel manager. It groups fields that describe individual parts of a multi-path payment (MPP) into a new struct called MppPart, which is then embedded inside the existing ClaimableHTLC struct. The change does not alter behavior, fix a bug, or introduce a security boundary; it only moves data around to make future trampoline-forwarding work easier.

This is a small internal code cleanup in the Lightning Dev Kit library. It renames a field from 'incoming_shared_secret' to 'trampoline_shared_secret' and makes sure the shared secret is also stored in a related data structure. There is no indication this fixes a security bug or changes behavior in a way that protects users.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It extracts a small, repeated pattern for reading previous-hop routing data into a shared helper method. There is no change to behavior, no fix for a bug, and no security relevance visible in the diff or commit message.

This commit is a build-system and fuzz-test maintenance change. It makes sure that certain experimental 'splicing' test commands in the fuzzing harness are only compiled and run when the 'splicing' feature flag is enabled. When the flag is off, those commands now do nothing instead of trying to call splicing code that isn't compiled in. There is no user-facing security fix here.

This commit fixes a fuzz-testing harness so it no longer crashes when it encounters a specific kind of routine network message (BroadcastChannelUpdate). The change only affects test code, not the real Lightning node software that users run. It does not fix a vulnerability in production code.

This commit fixes a bug in the Lightning Dev Kit where multi-part keysend payments (a way to send Bitcoin over the Lightning Network without an invoice) did not use the normal timeout safety check. Normally, if only some parts of a multi-part payment arrive, the node waits a short time and then fails the partial payments to free up resources. For keysend payments, this timeout was skipped, so partial payments could sit around for hours or days, tying up funds and network slots until the payment's final deadline. The fix applies the same completeness and timeout check to all multi-part receives, including keysend, and adds a test to prevent the bug from returning.

This commit simply deletes a GitHub Actions workflow file that ran integration tests against another project (ldk-node). It is a CI/testing maintenance change and does not alter any production code, cryptographic logic, network handling, or user-facing behavior. There is no security-relevant change.

This is a routine CI maintenance commit. It pins an older version of a dependency (hyper-rustls) so that automated builds using an older Rust compiler (1.75) continue to work. It does not change application code, fix a vulnerability, or alter how the software behaves in production.

This commit fixes a validation gap in the Lightning Dev Kit's LSPS5 (liquidity service) URL handling. When receiving a URL over the wire protocol, the code previously accepted any URL scheme, including insecure ones like http:// or ftp://. Now it enforces HTTPS-only URLs during deserialization, matching the validation already done for JSON input. It also adds a length check for webhook URLs.

This commit only adds a documentation comment warning developers who build LSPS5 services that webhook URLs come from untrusted clients and could point to internal/private resources. It does not change any code behavior, so there is no direct vulnerability being fixed in the library itself. The risk is that a service built with this library might blindly call attacker-supplied URLs, leading to server-side request forgery (SSRF) or internal network probing. The commit is a safety reminder rather than a patch.

This commit fixes a bug where a deliberately empty payment route could cause the software to try to reserve an enormous amount of memory. The fix makes the onion-packet builder reject empty routes immediately, preventing a potential denial-of-service or crash from an oversized memory allocation.