rust-lightning

This commit adds safety checks inside the Lightning payment code to make sure the route finder (the 'Router') actually follows the rules it was given. Before sending a payment, the code now verifies that the chosen route does not exceed the user-set maximum fee, does not contain useless empty paths, and does not include unnecessary multi-path payment (MPP) parts. If the router misbehaves, the payment is abandoned instead of being sent. It is a defensive hardening change rather than a fix for a known active attack.

This commit adds a new version of a file-based storage backend (FilesystemStoreV2) for the Lightning Dev Kit. It is a feature addition, not a security patch. The code introduces pagination support and a consistent directory layout using a special marker directory named '[empty]'. There is no direct evidence in the commit of a vulnerability being fixed, but the new code touches filesystem paths and page-token parsing, which are typical places where bugs can hide. The changes appear defensive and well-tested.

This commit adds new Rust programming interfaces (traits) for listing stored data in pages rather than all at once. It does not change any existing behavior, fix a bug, or alter how data is stored or protected. It is a feature addition to support more efficient key listing in future code.

This commit is a pure code reorganization (refactor) with no security-relevant behavior change. It splits the existing FilesystemStore implementation into a shared common module and a v1 module, in preparation for a future FilesystemStoreV2. All call sites are updated to use the new module path, but the actual file-reading, writing, locking, and listing logic is moved unchanged.

This commit is a code-quality refactor in the Lightning Dev Kit's block-sync module. It replaces the use of Rust's generic input/output error type with more specific string-based error messages when parsing HTTP and RPC responses. It does not appear to fix a security vulnerability, change network behavior, or introduce a new attack path. The main risk is that some error classifications may have shifted slightly (for example, parse errors are now consistently treated as persistent rather than transient), which could affect retry behavior but is not directly exploitable.

This commit is a straightforward code cleanup in the project's test suite. It replaces a Rust macro used only in tests with an equivalent regular function. There is no change to the actual Lightning node logic that runs in production, and no security-relevant behavior is altered.

This commit is a straightforward code cleanup in the project's test suite. It removes a helper macro used only in tests and replaces it with direct calls to an existing function. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix.

This commit is a straightforward code cleanup in the project's test suite. It replaces a Rust macro called `check_closed_broadcast!` with direct calls to an equivalent function. Macros are a shorthand in Rust; replacing them with normal function calls makes the test code easier to read and maintain but does not change what the tests actually do. There is no change to the live Lightning node software that users run, so this cannot affect real funds or network security.

This commit replaces the project's custom-built HTTP client code with an external library called bitreq. It is a large refactoring of how the software talks to Bitcoin nodes over REST and RPC. The change itself is described as a maintenance improvement, not a security fix. It removes a lot of hand-written HTTP parsing and replaces it with a dependency, which could introduce new bugs or behavior differences, but the diff does not show a known vulnerability being patched.

This change fixes a minor protocol behavior bug in the Lightning Dev Kit's splicing feature. Previously, the code would try to send a 'stfu' (stop, let's become quiescent) message to start a new splice even when another splice was already pending. Since starting a second splice isn't allowed while one is pending, sending the message was pointless and could cause confusion or unnecessary protocol churn. The patch now skips sending 'stfu' in that situation and adds tests covering reconnection scenarios.

This commit changes internal bookkeeping checks that only run in debug builds. The old checks could incorrectly fire and crash a developer/test build when a Lightning channel was spliced (resized) in a way that left one party temporarily below the required reserve balance. The new checks relax that rule for splicing by only requiring balances move upward when below reserve, rather than always staying above reserve. It is a robustness fix for an assertion, not a fix for a live-network security vulnerability.

This commit fixes an internal debug-only accounting bug that occurs when a Lightning channel is spliced (its funding amount is changed) while payments are still in flight. The bug made a non-release debug assertion incorrectly fire, but it did not change normal runtime behavior or allow funds to be stolen.

This is a small Rust code cleanup in the Lightning Dev Kit's channel manager. It changes how the result of a commitment_signed call is handled so the result is first bound to a local variable before being passed to an error-handling macro. The change itself does not alter the visible behavior of the code, but it may fix a subtle Rust borrow-checker or drop-order issue that could affect correctness during channel state updates. There is no direct evidence in the commit that this fixes a security vulnerability.

This commit is a code cleanup, not a security fix. It moves a debug-only assertion (a check that only runs in test builds) from many call sites into a single helper function and renames that helper to make its purpose clearer. The runtime behavior is unchanged, and the assertion is still not active in production builds.

This change adjusts when LDK saves its channel state to disk while processing certain transaction-sharing messages during channel setup. Previously, an error in handling these messages would trigger a disk save even though the error only affected temporary in-memory state. Now the code skips that unnecessary save, while still saving when something important actually happens (like completing a signing session). The commit message frames this as a cleanup/optimization, not a security fix.

This commit is a straightforward code cleanup in a fuzz test file. It moves repeated splice-in and splice-out test operations into shared helper functions and updates the test cases to use them. There is no change to production code, no security fix, and no behavior change intended.

This commit fixes a formatting issue in fuzz testing logs by adding a missing newline at the end of each log entry. It only affects test output readability and has no security relevance.

This commit changes how a Lightning payment library runs its internal fuzz tests. It makes the test harness call the normal periodic timer function instead of a special stripped-down version, so incomplete multi-part payments time out properly during testing. The production code is mostly unchanged, but a few internal test-only helpers are now available under a new test-utilities feature flag. There is no direct evidence this fixes a real-world security bug; it appears to be a test-harness cleanup that makes fuzzing more realistic.

This commit fixes a fuzz testing harness so it correctly tracks payments that the fuzzer accidentally generates as probe-like payments. It is a test-only change and does not affect real Lightning node behavior or user funds.

This commit updates an internal fuzz-testing harness (a tool that automatically throws random inputs at the code to find bugs) to use a more stable channel identifier when building test payments. It does not change the production Lightning node code that real users run, and there is no indication it fixes a security vulnerability. The change is purely about making the fuzzer work correctly now that the codebase supports 'splicing,' a feature that can change a channel's short identifier.

This commit updates a fuzzing test harness (chanmon_consistency) in the Lightning Dev Kit project. It adds the ability to simulate confirming splice transactions on a fake blockchain and fixes a serial ID collision in the test's random number generator. The changes are confined to test/fuzzing code and do not alter production Lightning logic.

This commit only changes test and fuzzing code. It adds new test controls that let developers temporarily disable or enable individual signer operations during fuzz testing, and it removes one unused signer-operation flag. There is no change to production Lightning code, so it does not create a real-world security vulnerability or fix one.

This commit is purely a refactoring of the project's continuous integration (CI) setup. It splits one large test script into six smaller, focused scripts that can run in parallel on GitHub Actions. There are no changes to the actual Lightning protocol code, cryptography, networking, or any code that end users or nodes run. It does not fix or introduce any security-relevant behavior.

This commit adds new configuration options that let a Lightning node operator choose to intercept (pause and manually handle) forwarded payments based on whether the payment arrived over a publicly announced channel or a private one. It is a feature addition, not a fix for an existing security flaw. The code does not bypass fee or time-lock requirements, so it cannot be used to steal funds or force free routing on its own. The main risk is operational: a node operator who enables these new flags and then mishandles intercepted payments could cause payment delays or failures.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It changes how pending HTLC (Hashed Time-Locked Contract) forwarding information is passed between functions: instead of converting data into tuples and then back into a structured object, the structured object is passed directly. The commit message and diff show no intent to fix a security issue, and the behavior appears functionally equivalent.