rust-lightning

This commit updates a fuzz test (a randomized testing harness) to accept one additional warning message when the test framework expects a peer disconnection. The new message, 'contribution no longer valid at quiescence,' is treated as a normal, non-fatal outcome of the splicing/RBF protocol when channel balances settle before the splice proceeds. It is a test-only change and does not alter production code behavior.

This patch fixes a bug in Lightning Dev Kit's splicing feature where a channel participant (the 'acceptor') could fail to receive a notification when a splice negotiation they contributed to fell through. Without that notification, the user's wallet software would not know it could safely unlock and reuse the funds it had set aside for the splice. The fix ensures both sides always get a SpliceNegotiationFailed event when a splice they contributed to fails, even if their exact same inputs/outputs were reused from a previous round.

This commit changes when users of the Lightning Dev Kit library are notified about a 'splice'—a way to resize a Lightning channel's on-chain funding. Previously both sides got an event when a splice was negotiated. Now only the side that actually added or removed money (a 'local contribution') gets the event. The other side still learns about the locked splice later through a different event. This is a user-interface cleanup, not a security fix, and does not change how funds are protected.

This commit adds a new internal bookkeeping map for a not-yet-enabled feature called trampoline routing. The commit itself is defensive: it documents that the new map is intentionally not saved to disk and warns that using it in production could cause a channel force-close after a restart. Because the feature is currently rejected earlier in the code path, the commit says the risky state cannot be reached today. It is best read as a work-in-progress foundation rather than an active vulnerability.

This change fixes how trampoline-style Lightning payments decide how much money and when (time lock) to forward to the next hop. Previously the code used values from the inner trampoline onion, which could differ from what the forwarding node actually received in the outer onion. Now it uses the outer onion values, so a forwarding node cannot silently pay the next hop less than it should while still satisfying the inner trampoline instructions. This prevents a potential fee/amount mismatch in multi-hop trampoline routing.

This commit changes how Lightning trampoline payments are tracked internally. It stores the amount and expiry time that the next trampoline hop expects, so the node remembers them when forwarding a payment. The change looks like a correctness fix for trampoline routing rather than a typical security bug, but without the surrounding code it is hard to tell whether the missing fields previously caused fee or expiry mismatches that could be exploited.

This commit fixes a bug in how trampoline routing nodes validate incoming Lightning payments. Previously, the node used values from the inner (trampoline) onion, which included the fee budget, to check whether it received the correct amount. A malicious or buggy upstream node could forward less money than intended, and as long as the shortfall stayed within the fee budget, the trampoline node would not detect it. The patch makes the node use the outer onion's stated amount instead, so it can verify it actually received what it was supposed to before forwarding.

This commit is a small code change that stores extra multi-path payment (MPP) information when a trampoline forward is received. It appears to be a preparatory step for validating incoming payment parts before forwarding them onward. There is no direct evidence in the commit that this fixes an active security vulnerability; it reads more like internal plumbing for an unfinished feature.

This commit fixes a bug in how the Lightning Dev Kit calculates the amount to forward when acting as a trampoline node for blinded multi-path payments. Previously, the code used the amount from a single incoming payment packet, which could be too small when several partial payments are meant to combine. The fix uses the intended total payment amount instead, preventing the node from rejecting or misrouting trampoline forwards that arrive in multiple pieces.

This commit removes a redundant 32-byte shared secret field from an internal data structure used when forwarding trampoline payments in the Lightning Dev Kit. The developers realized the secret was already stored inside each previous hop's data, so keeping a single copy at the top level was unnecessary. The change also updates serialization so older saved state cannot be cleanly loaded, but the code currently refuses to decode trampoline forwards anyway, so that downgrade risk is intentional and noted.

This is a small code cleanup that replaces two computed expressions with variables already available in scope. It does not change behavior, fix a bug, or address any security issue.

This commit simply corrects a username in an automated reviewer assignment workflow. It changes one reviewer handle from 'joost_spiral' to 'joostjager' so the right person stays in the rotation. There is no security issue here.

This commit changes the project's automated reviewer-assignment workflow to stop using a long-lived secret token and instead request a short-lived authentication token from the Forgejo CI service. This is a security-hardening improvement: it reduces the risk that a stolen or leaked long-lived token could be misused. There is no indication of an active vulnerability being fixed, and the change itself does not introduce obvious new weaknesses.

This commit only updates the CHANGELOG.md file to add release notes for versions 0.2.4, 0.1.11, 0.2.3, and 0.1.10. It does not change any source code, build scripts, tests, or configuration. The changelog text describes security fixes that were already made in earlier commits, but this documentation-only commit itself does not introduce or fix any vulnerability.

This commit shortens a rate-limiting cooldown in the LSPS5 webhook notification system from 10 seconds down to 100 milliseconds, and fixes a time-calculation bug that previously dropped sub-second precision. The change is described by the authors as a tuning fix to avoid multi-second delays for legitimate wake-up notifications while still throttling rapid reconnect churn. There is no direct evidence in the commit that this is a security vulnerability fix, but the affected code is a denial-of-service/amplification throttle, so any weakening of it has defensive-security relevance.

This commit only changes a fuzzing test harness (chanmon_consistency.rs). It adds new test operations that simulate local force-closing of channels and tracks which channels are expected to close so the harness can reject unexpected channel losses. There is no change to production code, user-facing behavior, or real wallet/channel logic, so it does not introduce or fix a security vulnerability in the software itself.

This commit is a minor internal refactoring of a fuzz test file. It moves a small helper function's contents directly into the place where it was called, changing a loop over three hard-coded nodes into a generic loop. There is no change to production code, no change to security behavior, and no fix for a vulnerability.

This commit is a simple code cleanup inside a fuzz testing harness. It moves an existing loop that relays and mines transactions into a new helper function, then calls that helper from the existing 'finish' method. No behavior changes are visible in the diff, and the code is not part of the production Lightning library that real users would run.

This commit only adds new fuzz-testing commands to an existing test harness. It lets the fuzzer temporarily block and then re-enable the local node's own signing operations during simulated channel failures. There is no change to production code, user-facing behavior, or real wallet security.

This commit is a cosmetic cleanup of CI workflow files. It replaces environment variables like TOOLCHAIN with the literal Rust version names (e.g., 'stable', 'beta', '1.75') in step titles and commands so that Forgejo's CI logs display meaningful names. No code behavior changes, no security fix or vulnerability introduced.

This commit adds a template file that controls the default message shown when merging pull requests on a Forgejo code hosting instance. It only changes the formatting of merge commit messages and has no security relevance.

This commit is a routine packaging fix. It updates the minimum required version of the rust-bitcoin library for the lightning-invoice crate from 0.32.4 to 0.32.7 because the code no longer compiles against older 0.32.x releases. It does not change any application logic, cryptographic operations, or network behavior, and there is no indication it fixes a security vulnerability.

This commit simply turns off Windows and macOS automated build tests in the project's CI configuration because the necessary test machines ('runners') are not currently available. It does not change any actual Lightning code, cryptography, networking, or user-facing behavior.

This commit hardens the project's automated build and test scripts by replacing loose version tags like 'actions/checkout@v4' with exact commit hashes served from a specific domain. This prevents a compromised or renamed third-party action from silently injecting malicious code into the project's CI runs. It is a defensive security improvement, not a fix for an active bug or breach.

This commit is a routine cleanup of the project's automated build scripts. It replaces the practice of downloading and running the Rust installer from the internet with using the Rust toolchain manager (rustup) that is already installed on the build machines. There is no security vulnerability here; it is a maintenance and reliability improvement.