rust-lightning

This commit fixes a bug in how rust-lightning's Electrum transaction sync checks for a known Bitcoin Merkle-tree weakness. The old code rejected transactions whose total byte size was exactly 64, but an attacker could pad a transaction with extra witness data to push the total size above 64 while keeping the non-witness (base) size at 64. Because Bitcoin txids and Merkle leaves are computed from the non-witness data, the bypass could let a malicious 64-byte-base transaction be treated as a valid Merkle leaf, potentially allowing fake transaction confirmations. The fix checks the base (non-witness) size instead of total size and applies the check in more code paths.

This commit only updates a documentation comment in the source code. It warns developers that a field called route_params on the Route struct will become mandatory in a future release. There are no code changes, no bug fixes, and no security changes.

This commit undoes a previous safety change in the file-based storage component of the Lightning Dev Kit. The original change tried to prevent an old, slow write from overwriting a newer write after internal cleanup of unused locks. The revert argues the storage API never promised ordering during a write anyway, so the fix was unnecessary and added complexity. The revert removes a test that demonstrated the original problem, but does not itself introduce a clearly exploitable bug.

This change fixes a cleanup problem in the Lightning Dev Kit's file-saving code. When two saves for the same file happen at nearly the same time, an earlier, out-of-date save could leave behind a temporary file containing plain data. The patch now deletes those leftover temporary files so sensitive information isn't left sitting on disk longer than necessary. It is a defensive hardening fix rather than a direct remote exploit.

This commit fixes a replay-protection bypass in LSPS5 webhook signature handling. The system uses zbase32-encoded signatures, which treat uppercase and lowercase letters as the same value. The replay cache, however, stored the raw signature string, so an attacker could resubmit the exact same webhook with only the letter case changed and bypass the replay check. The fix converts the signature to lowercase before checking or storing it in the cache, and a new test confirms the bypass is closed.

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.