rust-lightning

This commit fixes a subtraction underflow bug in the code that decides how much of a Lightning payment a blinded intermediate node should forward. With extremely high proportional fees and a small incoming payment amount, the code subtracted a larger fee from a smaller amount, which would crash in debug builds and silently produce a wrong, too-small result in release builds. In release builds that wrong result could have allowed a payment to be relayed that should have been rejected because it could not cover the node's fee. The fix uses Rust's checked subtraction so the function returns 'None' instead of underflowing.

This commit fixes a validation bug in how Lightning Dev Kit checks 'fake' short channel IDs (SCIDs) used for routing tricks like phantom and intercept payments. The old check compared only the lowest byte of the vout field, so an attacker could set the high byte of the vout and still pass validation. The fix now compares the full 16-bit vout value. The project says this is not directly exploitable for stealing funds, but it could cause a spurious internal event and makes the validation more correct.

This commit fixes a bug in the Lightning Dev Kit where, after a peer reconnects, the same cryptographic 'revoke_and_ack' message could be generated and sent twice. The duplicate would contain a secret the peer had already accepted, so the peer would reject it and force-close the payment channel. The fix clears an internal 'monitor-pending' flag when the signer-resume path actually produces the message, preventing the later duplicate.

This commit fixes a Rust unsafe-code bug in the lightning-net-tokio networking module. The previous patch removed an `&mut` reference but left a `*mut` pointer dereference that still created aliasing mutable access to the same memory, which is undefined behavior in Rust. The fix removes the duplicate unsafe dereference and reuses an existing safe helper function instead. The bug was reported by Project Loupe, an external security research group.

This commit fixes a Rust programming contract violation in several Lightning payment identifier types. In Rust, if a type can be 'borrowed' as a byte slice and used as a HashMap key, the borrowed form and the owned form must produce the same hash value. The old code used the type's automatic derived hash (which hashed the whole struct, including wrapper metadata) while borrowing only the inner byte array, so a borrowed key and an owned key could hash differently. That breaks HashMap lookups: you might store a value under one key and then be unable to find it with a borrowed version of the same key. The patch replaces the derived Hash implementation with one that hashes only the borrowed byte slice, restoring consistency. The commit message notes the issue was reported by Project Loupe.

This commit removes an old cryptographic nonce from the data carried inside Lightning "blinded paths" used when sending BOLT 12 offers and refunds. The nonce is no longer needed because a newer "payer metadata" field already carries the same secret. The commit keeps the payment ID in the blinded path and uses it to make sure an incoming invoice really belongs to the payment it claims to belong to. That prevents an attacker who captures one blinded path from delivering a different payment's invoice over it, which could otherwise link two of the user's payments together. The change is mostly a cleanup, but it also tightens the matching logic slightly.

This commit fixes a Rust unsafe-code bug in the networking glue between the Lightning Dev Kit and Tokio. The code was treating a shared sender object as if it had exclusive access, which is undefined behavior in Rust. In practice the called method only reads through an internal reference counter, so the risk of real-world harm is low, but the pattern was incorrect and could theoretically confuse the compiler into generating wrong code.

This commit is a test-only change to the Lightning Dev Kit fuzzing harness. It improves how the fuzzer simulates Bitcoin transaction relay, mempool behavior, block mining, and node restart synchronization. It does not change production code, user-facing APIs, or real network behavior, so it does not introduce a security vulnerability in the shipped library.

This commit adds a new prev_hop field to an existing event type so that applications using the Lightning Dev Kit can see which peer sent an intercepted onion message. It is a feature enhancement that improves policy control; it does not by itself fix a vulnerability or introduce a clear security bug.

This commit adds a new optional feature to LDK's onion message forwarding. Previously, if an onion message's next hop was identified by a short channel ID (SCID) that the node didn't know, the message was silently dropped. Now, if a user explicitly enables 'intercept_for_unknown_scids', the node can hold onto the message and emit an event, allowing external protocols (like LSPS-style services) to resolve the SCID out-of-band and forward the message later. The change also updates how these intercepted events are serialized for backwards compatibility with older LDK versions.

This commit changes how BOLT12 invoices are verified in the Lightning Dev Kit. Previously, some invoices could be verified using a nonce stored in the blinded reply path context. Now, the nonce is always included inside the encrypted payer metadata carried by the invoice request or refund. This makes invoices self-contained and prepares the code for future payment proofs. It is a protocol-correctness and forward-compatibility change, not a fix for an active exploit. Old invoice requests/refunds with blinded paths created before this change will fail verification and must be retried with a new payment id.

This commit is a follow-up ('f') that strengthens a regression test for a filesystem persistence bug in rust-lightning. The bug being tested is a race condition where an older, delayed write could overwrite a newer write after a lock was cleaned up, potentially causing stale data to be stored. The commit itself only changes test code and test-only hooks; it does not change the production fix. It makes the test verify the actual saved file contents rather than just internal version numbers, so the test now covers the user-visible overwrite problem.

This is a small follow-up patch (marked with 'f -') that reorders code and adds a comment in a filesystem persistence module. The change moves version allocation to happen while a lock-map mutex is still held, preventing a theoretical race where a cleanup routine could remove a lock entry after a version number is reserved but before the lock reference is copied. The commit message frames this as preventing 'stale fs-store writes.' The actual code behavior change is minimal and the patch is conservative.

This commit adds optional fee fields to LDK's recent-payment tracking structures so users can see routing fees for pending and completed payments. It is a straightforward feature/data exposure change with no security-relevant behavior visible in the diff.

This patch fixes a subtle race condition in rust-lightning's file-system persistence layer. Previously, the code could reserve a new write version number before it had safely grabbed the corresponding per-file lock. A background cleanup task could then delete the lock entry in between, leaving the version number associated with a lock that no longer exists. The fix grabs the lock map first, then reserves the version while still holding that map lock, and adds a regression test to prove the ordering is correct.

This commit fixes a bug in the Lightning Dev Kit's LSPS2 (JIT channel) service. When a just-in-time (JIT) channel opening failed, intercepted HTLCs (pending payments held for that channel) were not being released back through the intercept API. They could sit until their expiry timeout, tying up funds and potentially causing payment failures or liquidity problems. The fix releases those held payments immediately when the channel open fails, and also handles the case where an intercept was already released by resetting the LSPS2 state anyway.

This commit fixes a bug where a Lightning node's timer would keep refreshing and re-sending the same static invoice over and over, instead of waiting for the proper refresh interval. The root cause was using the older (minimum) invoice creation time rather than the newest (maximum) one when deciding if an offer looked stale. This could waste bandwidth, create unnecessary network messages, and potentially cause the node to look unreliable or spammy to peers.

This commit fixes a calculation in how Lightning Dev Kit estimates whether leftover on-chain funds (UTXOs) are enough to support opening additional 'anchor' channels. Previously, the code only subtracted the fee for the cryptographic proof needed to spend a UTXO, but forgot to also subtract the fixed base size every transaction input adds. As a result, a UTXO worth just slightly less than the advertised reserve could be wrongly counted as sufficient, potentially leading the node to believe it could open more anchor channels than it actually could afford to fund later. The fix adds that base input weight to the fee estimate, and a new test confirms a borderline UTXO is now rejected.

This commit fixes a bug in how Lightning Dev Kit describes anchor outputs when preparing transactions for external wallets to sign. Previously, for a type of anchor tied to a specific channel key, the code returned the raw 'witness script' (the spending conditions) instead of the proper P2WSH address/script pubkey. Wallets use this data to identify and validate the coin being spent. Providing the wrong descriptor could cause wallets to reject the PSBT or, in worst cases, misidentify the output, potentially leading to invalid transactions or unsafe signing behavior. The fix converts the redeemscript to its P2WSH script pubkey, and adds a regression test.

This patch fixes a denial-of-service/amplification weakness in the LSPS5 webhook service of rust-lightning. Previously, every time a peer connected or disconnected, the LSP would immediately clear the one-minute 'cooldown' that prevents repeated webhook notifications. A malicious or misbehaving peer could repeatedly connect and disconnect to force the LSP to send many webhook requests to registered URLs, effectively using the LSP as an amplifier against third-party servers. The patch now allows only one cooldown reset every 10 seconds per peer. It also fixes a related time-calculation bug so that a clock moving backward does not incorrectly make future timestamps look expired.

This patch fixes a bug in the Lightning Dev Kit where a node could accidentally resend old cryptographic messages to a peer after restarting. When a stale saved channel state was reloaded, the node might think it still owed the peer a 'revoke_and_ack' or 'commitment_signed' message that had already been sent. During channel reestablishment, the peer's commitment numbers now authoritatively clear these stale flags, preventing duplicate messages that could confuse or disrupt the channel.

This commit fixes the order in which a Lightning node resends messages after reconnecting to a peer during a channel splice. Previously, if the node had both a pending 'splice_locked' message and pending commitment updates to retransmit, it could send the commitment updates first. Because those updates assume the splice has already been locked in, sending them before 'splice_locked' could confuse the peer and disrupt channel state synchronization. The fix moves 'splice_locked' ahead of commitment retransmission, and adds tests to verify the correct ordering.

This commit only changes an internal fuzz-testing harness (a tool used to find bugs during development, not production code). It raises the maximum number of loop iterations allowed while waiting for simulated channel state to settle, and fixes a typo in a panic message. There is no change to the actual Lightning protocol logic or any user-facing software.

This commit changes a fuzz test (a randomized testing harness) so it no longer crashes when a simulated splice-funding signing event becomes stale. The change only affects test code, not the production Lightning library, and it ignores an expected error rather than fixing a runtime security bug.

This commit fixes a protocol edge case in Lightning splicing. If a splice transaction confirmed at just the wrong moment—after one peer sent a channel-reestablish message but before it received the other peer's—the node could promote the new splice funding state internally but forget to send the required follow-up 'splice_locked' message. Without that message, the counterparty would not know the splice was active on this side, potentially leaving the channel in an inconsistent or stuck state. The fix adds a fallback that sends splice_locked in that reconnect scenario, plus a regression test.