rust-lightning

This change only modifies a fuzzing test harness, not the production Lightning Dev Kit code. It adds a filter so that simulated multi-hop payments skip test scenarios where the harness's view of a closed channel is temporarily out of sync with a node's own channel list. This prevents the fuzzer from generating misleading test cases where a payment appears to stall because the test state is inconsistent. It does not fix a vulnerability in real LDK software and cannot be exploited by users or attackers.

This commit changes only a fuzzing test harness (a tool that randomly exercises code to find bugs). It teaches the test harness to accept a specific warning message as expected when a test delivers an outdated 'STFU' message after a channel is already closed. It does not change the actual Lightning protocol handling code, so it cannot directly affect real users or funds.

This commit is a feature addition, not a vulnerability fix. It extends rust-lightning's BOLT 12 payment support so that when a wallet pays a BOLT 12 invoice, the paid invoice is saved through retries and restarts and is later exposed in the PaymentSent event as a PaidBolt12Invoice. The wallet can then use that object to build a cryptographic 'payer proof' that selectively discloses invoice fields to prove to a third party that it paid. The payer signing key is re-derived from data already in the invoice, so no extra secret key storage is needed. There is no indication in the commit that this fixes a security bug; it is new functionality with tests.

This commit only adds a new fuzz test target. Fuzz tests are automated tools that throw random or crafted input at a piece of code to look for crashes or bugs. The commit does not change any production code, protocol behavior, or user-facing functionality, so it does not introduce or fix a security issue by itself.

This commit is a code cleanup (refactor) in the Lightning Dev Kit library. It moves existing payer key-derivation logic into shared helper functions so that future 'payer proof' features can reuse the same code. The change does not appear to fix a security bug; it reorganizes existing logic and adds a new public method to re-derive a payer's signing keys from invoice data. No vulnerability or exploit is described in the commit itself.

This commit adds new code to support BOLT 12 "selective disclosure" payer proofs in the Lightning Dev Kit. It lets someone prove they have a valid signed invoice without revealing every field. The change is a feature addition, not a fix for a known bug, and the commit message and diff do not describe any security vulnerability. However, cryptographic merkle-tree code like this is security-critical because any mistake in how hashes are combined or how omitted fields are reconstructed could let an attacker forge a proof or hide data. The patch includes tests and validation, but because it is brand-new, complex code, it deserves careful review.

This commit adds a new feature to rust-lightning called BOLT 12 payer proofs. It lets someone who paid a BOLT 12 invoice cryptographically prove they paid it, while optionally hiding some invoice details. The change is a large new module plus small supporting changes in invoice, offer, nonce, and serialization code. There is no indication this is a security patch or fixes a vulnerability; it is a new protocol feature implementation with extensive tests and spec test vectors.

This commit changes a CI workflow for the rust-lightning project. It stops trying to push new fuzz test inputs directly to a corpus repository from automated test runs, and instead uploads them as a temporary artifact that a separate scheduled job later collects. This is a workflow reliability and credential-handling improvement, not a security fix or vulnerability.

This commit only adds a new regression test. It does not change any production code. The test verifies that modern LDK can still read and write very old (pre-0.1) channel monitor update records that used a special sentinel value (u64::MAX) for updates after a channel was closed. There is no vulnerability being fixed here; it is defensive test coverage for an already-handled legacy data format.

This is a routine update to the project's automated reviewer-assignment workflow. It prevents the bot from accidentally adding a second random reviewer when one is already assigned, and adds a manual trigger so maintainers can request an additional reviewer on demand. There is no security-relevant change here.

This is a one-line fix to a Forgejo workflow that assigns reviewers. The workflow requests a temporary identity token from the CI system so it can call another service. The change adds an explicit audience parameter to that token request, ensuring the token is only valid for the intended recipient. Without this, the token might be accepted by a broader set of services or rejected by the intended one, depending on how the CI and target service are configured. It is a hardening/configuration fix rather than a user-facing vulnerability in the Lightning library itself.

This is a minor code cleanup inside a fuzzing test harness. It extracts a small loop that collects broadcast transactions from all simulated nodes into a new helper function, then calls that helper from an existing cleanup loop. The actual behavior is unchanged; only duplicated code is removed.

This commit fixes a bug in LDK's internal fuzz testing harness (not production code). When the test reloaded saved channel data, it incorrectly synchronized all channel monitors from the oldest monitor's block height. Monitors that were already ahead got blocks replayed, which they interpreted as a blockchain reorganization. That fake reorg could discard already-registered force-close transactions, leaving a closed channel with nothing to broadcast. The fix makes each monitor catch up from its own saved height, matching how LDK expects real callers to do startup sync.

This commit changes only a fuzzing test harness (chanmon_consistency.rs). It improves how simulated force-closed channels are settled on the fake blockchain during fuzz tests, so the test can catch stuck cleanup states. There is no change to production code, no user-facing behavior change, and no indication of a real-world security vulnerability being fixed.

This commit only adds new unit tests for an existing trampoline forwarding feature in a Lightning network implementation. It does not change production behavior, fix a bug, or alter security logic. The tests exercise validation rules that already exist in the code, such as checking fees, timeouts, and payment secrets for multi-part trampoline payments.

This commit only adds new test code for multi-path trampoline payments in the Lightning Dev Kit. It does not change any production logic, so it cannot introduce a security vulnerability on its own.

This commit is a test-only refactor. It changes a helper function used in Lightning Dev Kit's internal tests so that it returns both a blinded payment tail and the full blinded payment path. This lets tests register the path in payment parameters, matching a recent requirement in the codebase. There is no change to production code, user-facing behavior, or security-sensitive logic.

This commit changes how the Lightning node handles a special kind of forwarded payment called a 'trampoline' payment. Previously, trampoline forwards were always rejected. Now, in test builds only, the code allows them through after checking basic fee and timeout (CLTV) rules. The commit also removes one test that expected trampoline forwards to be rejected. This is a development/testing change, not a fix for an active security flaw, and production behavior still rejects these forwards.

This commit fixes a code path in the Lightning Dev Kit where a specific kind of local payment failure (called a 'TrampolineForward' failure) was not being handled. Previously, the code only expected failures from regular outbound routes and would panic with 'unreachable!' if a trampoline forward failure occurred. The change adds handling for that case, returning a decoded failure with no specific short channel ID. It is described by the author as a minimal fix for testing, with fuller error handling planned later.

This commit adds missing encryption wrapping for error messages in the Lightning Dev Kit when acting as a 'trampoline' forwarding node. Previously, if a downstream node returned an error that the trampoline could not fully decrypt, the error would not be properly re-wrapped for the original sender. The change ensures the error is encrypted with both the trampoline's own shared secret and the incoming shared secret, so it can travel back to the payer correctly. The commit message explicitly says this is the 'bare minimum' and that proper error handling will follow later.

This commit adds partial support in the Lightning Dev Kit node software for receiving and temporarily holding multi-part trampoline payments, then deliberately rejects them once all parts arrive because full outbound forwarding is not yet implemented. It is a development/testing step for the trampoline routing feature, not a finished payment path. The code includes safety checks and debug assertions to catch inconsistent payment data, and it explicitly fails unsupported forwards rather than silently mishandling them.

This commit is a small internal cleanup in the Lightning Dev Kit code. It removes an unnecessary 'Option' wrapper from a data field called `contribution` inside `SpliceFundingFailed`, because that field is always created from a real value. The public `Event::SpliceNegotiationFailed::contribution` field remains optional for backward compatibility with older stored data. There is no security fix here.

This commit adds a safety check in the Lightning Dev Kit's code that handles a message called tx_init_rbf, which is used to propose bumping the fee on a channel's on-chain transaction. Before this change, the code did not verify that the channel was still 'live' (active and not shutting down). The fix rejects RBF requests once a channel has requested shutdown, matching an existing safeguard already in place for splice_init messages. The change prevents a counterparty from initiating fee-bump negotiations after shutdown has begun, which could otherwise lead to protocol confusion or inconsistent channel state.

This commit changes how the Lightning Dev Kit node responds to mistakes or disagreements during splicing (a way to resize a payment channel). Instead of immediately disconnecting from the peer in many cases, it now sends a 'tx_abort' message. This keeps the connection alive, avoids endless reconnect-and-fail loops, and makes the process more robust. It is a protocol-robustness improvement rather than a fix for a critical vulnerability.

This change makes a Lightning node send a 'tx_abort' message instead of disconnecting from a peer when an RBF (fee-bump) request cannot be honored during a splice. The goal is to avoid unnecessary reconnections and keep the channel usable. It is a protocol-robustness improvement rather than a fix for a critical vulnerability.