rust-lightning

This patch fixes a potential integer overflow when calculating Lightning channel fees. If a malicious or misconfigured peer set an extremely high transaction fee rate, the software could overflow a 32-bit integer while applying a safety buffer multiplier. In release builds this would silently wrap around and ignore the safety buffer; in debug builds it would crash. The fix uses saturating multiplication so the result stays at the maximum safe value instead of overflowing. The commit notes this is not practically exploitable for theft because a peer already has easier ways to disrupt a channel, but it removes a remotely reachable debug crash.

This commit fixes a bug in how Lightning Dev Kit checks expiry times for payments sent through 'blinded paths' (a privacy feature that hides the final recipient). The code was accidentally checking the outgoing expiry time instead of the incoming one. Because of this, a payment could travel deeper into the blinded path than intended before being rejected, slightly weakening the privacy/cost protection that blinded-path expiry is meant to provide. The commit explicitly states this does not risk loss of funds.

This commit fixes a race condition in Lightning Dev Kit's async payments feature. When a user wants to receive a payment while offline, their LSP (Lightning Service Provider) holds the payment until they come back online. The bug occurred when a 'release this payment' message arrived *before* the held payment had been fully registered in the LSP's internal state. Previously, the release message would be ignored, causing the payment to get stuck. The fix makes the LSP remember the release request and apply it once the payment is registered.

This change fixes a timing issue in how the Lightning node hands off payment packets (HTLCs) between two internal components. Previously, an HTLC could be in an in-between state where one part of the code thought it had been forwarded while another part had not yet processed it, potentially leading to inconsistent bookkeeping. The fix moves the handoff so it happens while the same lock is held, making the transition atomic.

This commit is a routine API cleanup, not a security fix. It removes an unnecessary wallet/coin-selection argument from the splice_out function because splicing funds out of a Lightning channel only spends from the channel balance and never needs to select wallet inputs. The change refactors shared validation into a helper and makes the function synchronous, but it does not patch any vulnerability and the commit message does not claim it does.

This commit adds a simple helper that converts a full channel handshake configuration into a partial update object, mirroring an existing helper for another config type. It is a routine code utility with no security relevance visible in the diff or commit message.

This commit only adds a new fuzz test target. Fuzz tests are automated tools that feed random or crafted inputs to code to try to make it crash. The commit does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. It is a testing/infrastructure addition.

This commit only adds a two-line comment explaining why a particular helper function is not used in the offers flow code. It does not change any code behavior, fix a bug, or alter security logic.

This commit only reformats existing Rust code using 'cargo fmt'. It changes whitespace and line breaks in two files but does not alter any logic, values, or behavior. There is no security relevance.

This small patch changes how a Lightning node decides which channel monitors need to be re-synchronized with the blockchain after a restart. Previously, if the node's best-known block height was missing, the code treated that as height 0 and still computed a partition key, which could cause the wrong subset of monitors to sync. Now, if no best height is known, the partition key is treated as absent and the monitor is skipped unless it has pending claims. The fix is more about correctness and avoiding unnecessary/misdirected sync work than a direct theft-of-funds vulnerability, but in a Lightning context monitor-sync bugs can affect safety.

This commit fixes a bug where a piece of data called `best_block` was not being updated when new blocks arrived. This data is used when creating private, one-time Lightning payment routes. If it goes stale for more than two weeks, the software could build payment routes that other nodes consider expired or invalid, causing payments to fail. The fix simply updates `best_block` whenever a new block is seen.

This commit removes leftover, unused code that handled DNS-based human-readable name resolution inside the BOLT12 offers message flow. The project had already switched to an external crate for this job, and this change simply cleans up the stale internal pieces that were accidentally left behind. It is a maintenance/cleanup change, not a security fix for an active vulnerability.

This commit only fixes a comment describing a Lightning Network routing parameter. It changes no actual code logic, so it cannot affect security or behavior.

This commit is a tiny documentation fix. It updates the comment above the `pay_for_offer` function to tell developers to use a related function, `pay_for_offer_from_hrn`, when handling human-readable payment names. No code behavior changed.

This commit removes an old, already-deprecated feature from the Lightning Dev Kit's core ChannelManager: the ability to pay a BOLT 12 offer by resolving a human-readable BIP 353 name (like an email-style address) through DNS-over-onion-message inside the library. The project now expects users to use a separate, dedicated `bitcoin-payment-instructions` crate for that name resolution instead. The change is a routine API cleanup, not a security fix, and does not introduce any vulnerability.

This commit only updates three stale documentation comments in the chain monitor code. The comments previously referred to old function parameters named `funding_txo` (a transaction output identifier) but the actual code now uses `channel_id`. There are no code behavior changes, no bug fixes, and no security implications.

This commit is a feature change, not a security bug fix. It splits one setting into two: the maximum share of a channel's value that can be tied up in incoming payments (HTLCs). Announced channels now default to 25% and unannounced (private) channels default to 100%. The change also updates many tests to keep their old behavior by explicitly setting the previous 10% default. There is no direct vulnerability in the diff, but the higher defaults slightly increase funds-at-risk if a node goes offline while many HTLCs are pending.

This patch fixes a bug in the Lightning Dev Kit's channel manager where empty entries in a tracking map were not being removed. In a rare sequence of events—when an HTLC is claimed both off-chain and then on-chain—the leftover empty entry could trigger a debug assertion failure (a crash in debug builds) due to what appears to the code as a 'double-claim.' The fix simply deletes the empty map entry after cleaning it up. It was found through fuzzing, not a real-world exploit, and affects only debug builds because it relies on a debug_assert.

This commit changes how the Lightning Dev Kit code behaves when running under fuzz testing. Normally, the code uses the real wall-clock time and random hashing. Under fuzzing, it now uses fixed fallback values and deterministic hashing so that fuzz tests produce the same results every run. This is a testing-harness improvement, not a fix for an exploitable security bug in production. It does not change behavior for normal users.

This commit only adds documentation comments warning that callbacks registered on a Future object must not re-enter the same Future or its Notifier. It does not change any code behavior, fix a bug, or add safeguards. The change suggests a pre-existing reentrancy hazard exists, but it is left unfixed because the authors considered it hard to address and not worth the effort.

This commit only changes a code comment to accurately describe why a particular data structure is populated. No program logic, data flow, or behavior was altered. It is purely a documentation fix.

This commit fixes how Lightning Dev Kit calculates the minimum fee rate when a user tries to speed up (RBF) a channel funding or splicing transaction. Previously, the code only required the new fee to be 25/24 of the old fee. At very low fee rates that percentage bump is too small to meet Bitcoin's BIP125 network-relay rule, so the replacement transaction could be rejected by the network and never confirm. The fix now uses the larger of (old fee + 25 sat/kwu) and (25/24 of old fee) for transactions this node creates, while still accepting the bare 25/24 rule from peers. This is a protocol-compliance/robustness fix, not a direct theft or remote-exploitation vulnerability.

This commit adds a new helper macro called default_value_vec to LDK's serialization toolkit. It lets downstream developers store a list (Vec) of items with a fallback default value, without hitting Rust's 'orphan rule' that normally blocks adding serialization traits to standard types like Vec. The change is purely additive and includes unit tests. There is no indication it fixes a security bug or introduces a vulnerability.

This patch fixes a bug in rust-lightning's initial blockchain synchronization where the header cache returned to callers was often nearly empty. The cache is meant to keep recent block headers so the node can handle chain reorganizations after startup. Because the cache was being incorrectly cleared during synchronization, a node could start normal operation without the recent headers it needs to safely detect and respond to reorgs. This is a correctness/reliability fix in chain-sync logic, not a direct remote-exploitable vulnerability.

This commit adds a symlink to an existing internal utility file and makes minor build configuration changes. It is purely a code-organization/refactoring step with no security-relevant behavior change visible in the diff.