rust-lightning

This commit fixes a potential denial-of-service (DoS) issue in the Lightning Dev Kit's transaction sync module. Previously, if the Bitcoin blockchain kept changing during a sync attempt, the code could loop forever trying to catch up. The patch limits this to 10 attempts before giving up and trying again later, preventing the node from getting stuck or wasting excessive resources.

This commit is a code-cleanup refactor that moves the calculation of a 'spiked feerate' (a safety buffer against sudden Bitcoin fee increases) from one part of the code to another. It does not change the actual multiplier value or the security policy; it only changes where the multiplication happens. The commit message explicitly says this is preparation for a future change, not a fix itself. There is no direct evidence in the commit that it repairs a vulnerability.

This commit fixes a bug in how Lightning Dev Kit calculates whether a channel funder can afford a sudden spike in Bitcoin transaction fees. Previously, the code assumed HTLCs (small conditional payments) that would become uneconomical at a doubled feerate were already trimmed away when checking the funder's buffer. This made the check too optimistic: it only verified the funder could survive an exact 2x fee jump, not any jump between normal and 2x. The fix counts HTLCs at the current feerate instead of the spiked one, ensuring the reserve covers the full range of possible fee increases. The commit is framed by its author as a correctness fix for fee-spike buffer accounting.

This commit fixes a bug in how the Lightning node calculates the reserve funds it must keep available to pay for a future emergency fee increase. Previously, the node counted how many small HTLC payments would be dropped from the transaction if fees spiked, and used that smaller number to estimate the required reserve. That could lead to an underestimate, because a fee spike could also trim additional HTLCs. The fix now counts non-dust HTLCs at the current feerate and reserves enough for any fee increase between 1x and 2x, not just exactly 2x. The risk is that a node might think it has more spendable balance than it actually can safely afford, potentially leading to a force-close or inability to cover fees during congestion.

This commit only updates test-only development dependencies and adjusts the corresponding test import paths. It does not change any production code, network behavior, or cryptographic logic, so it has no security relevance for users of the library.

This commit simply updates a dependency version number in a configuration file, bumping the electrum-client library from version 0.24.0 to 0.25. There is no code change, no disclosed security fix, and no indication of any vulnerability. It appears to be a routine maintenance update.

This commit fixes a bug in Lightning Dev Kit's splicing logic for zero-fee-commitment (0FC) channels. Previously, when calculating the required channel reserve after a splice, the code would cap the reserve at the total channel value. In a special case where the splice acceptor had no balance and no HTLCs existed, this cap allowed the splice initiator to withdraw more than they should—effectively reducing their balance below the required reserve. The only thing stopping a full drain was a separate dust-limit check. The fix makes the reserve calculation return an error if the computed reserve would exceed the post-splice channel value, and it uses each side's actual dust limit instead of a global constant when validating splice contributions.

This commit is a simple rename of two public event types in the Lightning Dev Kit Rust library. `Event::SplicePending` is renamed to `Event::SpliceNegotiated`, and `Event::SpliceFailed` is renamed to `Event::SpliceNegotiationFailed`. The change is purely cosmetic and intended to make the event names better match their meaning (a single negotiation round outcome, not the overall splice lifecycle). No logic, serialization format, or security behavior is changed.

This commit is a user-facing diagnostic improvement, not a security fix. It adds a 'reason' field to the SpliceFailed event so Lightning node operators can tell why a splice negotiation failed (for example, peer disconnected, feerate too low, or counterparty aborted). It changes no cryptographic checks, access controls, or network behavior. The only code-level risk is a minor serialization compatibility change: old stored events without the new field default to 'Unknown', and the persistence reload path defaults to 'PeerDisconnected'.

This commit is a routine API improvement for the Lightning Dev Kit. It changes the information reported when a splice (or future dual-funded) transaction is broadcast so that downstream wallet software can see all negotiated versions of the transaction and each party's contribution. There is no indication of a security bug being fixed; it is a feature/refactoring change to expose richer data to consumers of the library.

This commit fixes a bug in how Electrum server transaction history is checked. The code was casting a signed (possibly negative) confirmation height into an unsigned number before checking whether it was valid. That meant unconfirmed or invalid entries could be misread as very large heights instead of being skipped, potentially leading to incorrect transaction confirmation data being used by the Lightning wallet.

This commit fixes a bug in the Lightning Dev Kit where very small channels could be created or spliced down to below 1000 satoshis when zero-reserve channels were used. Normally, a reserve requirement prevents channels from being too tiny, but that safeguard was skipped for zero-reserve channels. The patch adds a direct 1000-satoshi minimum channel value check for opening and splicing channels, including during splicing of normal reserve-enabled channels. This prevents the creation or modification of channels so small that they could be economically unviable or cause protocol edge cases.

This commit adds a new test case for the Lightning Dev Kit library. It does not change any production code; it only adds test code that checks how splicing (a way to resize a Lightning channel) behaves when one side has a zero reserve balance. The change makes an existing internal test helper function visible to the new test file. There is no indication this commit fixes or introduces a security issue.

This commit adds a new read-only field called next_splice_out_maximum_sat to the public ChannelDetails struct. It exposes how much bitcoin can be spliced out of a channel in the next splice operation. There is no change to logic, permissions, or cryptographic checks; it is purely an API/data exposure addition. No security issue is evident from the diff.

This commit fixes how rust-lightning calculates the maximum amount a user can splice out of a Lightning channel. Previously the calculation ignored channel reserve rules and a requirement to keep at least one output, which could have allowed a user to request an invalid splice-out that the protocol or counterparty would reject. The new field properly accounts for both constraints, making splice-out operations safer and more likely to succeed.

This commit only exposes an existing internal calculation as a new public field in channel information structures. It does not change any security logic, limits, or behavior; it merely makes the current 'dust exposure' value readable by users of the library. There is no indication of a vulnerability being fixed.

This commit simply adds two public getter methods that expose internal scoring objects for reading. It does not change any logic, permissions, or behavior. There is no security issue visible in the diff.

This commit fixes a validation gap in the Lightning Dev Kit's LSPS5 (liquidity service) URL handling. When receiving a URL over the wire protocol, the code previously accepted any URL scheme, including insecure ones like http:// or ftp://. Now it enforces HTTPS-only URLs during deserialization, matching the validation already done for JSON input. It also adds a length check for webhook URLs.

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 commit is a performance optimization for the initial block synchronization step in rust-lightning. It fetches blocks in parallel batches of up to 36 instead of one at a time, reducing sync time. There is no indication this change fixes a security vulnerability; it is purely about speed.

This commit is a straightforward internal code cleanup: it moves two helper marker traits (MaybeSend and MaybeSync) from one Rust module (async_poll) to another (native_async) and updates all import paths accordingly. There is no change to what the code does, no bug fix, and no security-related behavior change.

This commit changes how a Bitcoin Lightning node (LDK) recovers after a restart when the blockchain has split/reorganized. Previously, the node only remembered its last known block hash. If that block was no longer available from the block source after a reorg, the node could get stuck ('bricked'). The fix makes the node keep a short history of recent block hashes inside its stored 'BestBlock' state, so it can find the fork point and replay the chain without relying on an extra cache object. This is a robustness improvement, not a typical exploitable vulnerability.

This commit is a straightforward internal code cleanup in the transaction-building module. It replaces several repetitive helper functions with more general ones and removes duplicated logic, reducing line count and indentation. There is no indication it fixes a security bug or changes behavior in a security-relevant way.

This commit adds a large set of unit tests for a new 'zero reserve' channel feature in the Lightning Dev Kit. Zero-reserve channels let one peer spend almost all of its channel balance, which is normally disallowed because it can leave a channel with no money left to pay on-chain fees during a dispute. The tests exercise the new APIs, check that balances and fee buffers are computed correctly, and verify that dangerous edge cases (such as a commitment transaction with no outputs at all) are rejected or handled safely. The commit itself only contains test code, so it does not introduce a live vulnerability, but it documents behavior that could be risky if the production logic has bugs.

This commit is a routine API refactor in a Lightning network library. It merges two user-facing methods, `splice_channel` and `rbf_channel`, into one, and adds a way to reuse a previous funding contribution when bumping transaction fees (RBF). The changes are mostly code cleanup and convenience; they do not appear to fix an active security bug. There is one small defensive improvement: a helper now filters out inputs/outputs that are still committed to an earlier splice round when reporting a failed splice, which reduces the chance of accidentally double-spending a contribution. No independent security advisory, CVE, or researcher attribution is present in the materials.