rust-lightning

This commit changes how Lightning Dev Kit (LDK) deserializes (reloads from disk) important chain-following objects like ChannelMonitor and ChannelManager. Previously, deserialization returned just a single latest block hash paired with the object. Now it returns a BestBlock structure that includes the latest block hash plus a short history of recent block hashes. This is a defensive, API-shaping change intended to make downstream developers handle initial chain sync more safely after a restart, especially if the Bitcoin chain source has lost blocks from a reorganization while the node was offline. It is not a patch for an active exploit; it is a hardening/refactoring change that improves resilience against reorgs during startup.

This commit is a follow-up code cleanup in rust-lightning's block synchronization module. It changes how the code handles blockchain reorganizations (when the chain temporarily forks and then switches to a different branch). Previously, the code tracked and notified about each individual block that was disconnected; now it only passes the fork point, matching an earlier change made to the main listener interface. The commit removes an internal list of disconnected blocks and updates the cache API accordingly. There is no direct evidence in the commit that this fixes a security vulnerability.

This commit replaces an unbounded memory cache of Bitcoin block headers with a bounded one, limiting it to about one week's worth of headers. The change prevents the cache from growing without limit during long-running operation, which could otherwise consume increasing amounts of memory. It also renames the cache from UnboundedCache to HeaderCache and slightly adjusts how old headers are removed during chain reorganizations.

This commit is a routine internal code cleanup in the rust-lightning block synchronization crate. It removes an unused internal Rust trait called `Cache` and replaces its indirection with direct use of a concrete `HeaderCache` struct. There is no change to how data is validated, stored, or exposed to users, and no security-relevant behavior is altered.

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 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 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 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.

This is a minor Rust code cleanup change. It adds explicit lifetime labels to two function return types in the no-std synchronization code to silence compiler warnings. There is no functional change, no security fix, and no behavior change.

This commit is a routine API cleanup, not a security fix. It removes a public `Cache` trait from the `lightning-block-sync` crate and forces all users to use the built-in `UnboundedCache`. The change simplifies the code and ensures that block headers collected during initial synchronization are reliably passed forward, avoiding a situation where a user-provided cache could lose headers needed to handle blockchain forks correctly.

This commit changes how LDK (a Bitcoin Lightning Network library) remembers recent Bitcoin block hashes. Previously, it only remembered the single latest block. After this change, it keeps a small history of the last 12 block hashes. This helps the node recover correctly if the chain reorganizes (a 'reorg') and the block source it was syncing from has changed or resynced. Without this history, the node could get stuck after a restart because it couldn't find the point where the old chain and new chain split. The change is a robustness improvement, not a fix for an active exploit.

This commit only changes a test file to make a flaky test more reliable. It replaces hard-coded Google IP addresses with dynamically resolved addresses, so the test does not break when Google's IP addresses change. There is no change to production code and no security issue.

This commit is a performance optimization for a test-only fuzzing logger. It skips formatting log messages when the output is a special 'DevNull' sink that discards everything anyway. There is no security relevance: no bug is fixed, no memory safety issue is addressed, and no attacker-controlled behavior is changed.

This commit is a cleanup of a fuzz-testing helper. It removes a wrapper that scanned every log line for a specific error message that no longer exists in the codebase. Because the searched message was already gone, the wrapper served no purpose and only wasted CPU. There is no change to production Lightning code, no user-facing behavior change, and no security fix.

This commit fixes a fuzzing coverage report script. It changes which Rust library crates are included when measuring how thoroughly the fuzz tests exercise the code. There is no change to the actual Lightning protocol code, wallet logic, or network behavior, and no security vulnerability is being patched.

This commit fixes a missing 'clear' function for the zero-confirmation channel feature flag in the Lightning Dev Kit. Feature flags are used to negotiate capabilities between Lightning nodes. Without a way to clear this flag, code that needs to remove or reset the zero-confirmation feature could fail to compile or behave unexpectedly, potentially causing misnegotiation of channel types. The fix is small and only adds the missing function.

This commit changes the feature bit used to advertise a new Lightning protocol capability called 'zero-fee commitment anchors' from an experimental/staging number (141) to the official production number (41). Feature bits are how Lightning nodes tell each other which protocol extensions they support during connection setup. The change itself is a protocol compatibility update, not a fix for a vulnerability. However, because it swaps a staging feature for a production one, nodes running older code that only understood the staging bit may fail to recognize the capability in peers running the new code, which could cause interoperability problems or prevent opening of certain channel types.

This commit is a pure code-style cleanup. It changes how some error and log messages are written in Rust so that variables are inserted directly into the format string (e.g., `{var}`) instead of being passed as separate arguments. The wording and behavior of the messages are unchanged, and no security-sensitive logic was modified.

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 is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations and lets rustfmt re-wrap long function signatures, error messages, and calls in several Lightning channel setup functions. No logic, checks, or behavior were changed.

This commit adds an internal-only option for V2 Lightning channels to disable the usual channel reserve requirement. It is marked by the authors as not matching the official protocol specification, using a temporary experimental message field. Because it is internal and not exposed to end users, the immediate security risk is limited, but it introduces assumptions about how peers will behave when reserves are skipped.

This commit renames and expands a special Lightning channel-acceptance API. Previously, users could manually accept an inbound channel from a trusted peer and treat it as confirmed immediately (zero-conf). Now the same API also allows setting the counterparty's required channel reserve to zero. A zero reserve means the peer can spend their entire balance and force-close the channel at no cost to themselves, which removes a key financial deterrent against cheating. The change is explicitly documented as dangerous and only appropriate for trusted peers, but it introduces a new risky option that did not exist before.

This commit changes how the Lightning node handles incoming payment requests (HTLCs) that would push the node's own balance below the 'channel reserve' amount chosen by the other party. Previously, the node would reject such HTLCs and close the channel, treating it as a violation. The new behavior accepts these HTLCs, because the developers consider it the counterparty's problem, not theirs. A related safety assertion is now only checked in tests, not in production code. This is a protocol-behavior change rather than a traditional memory-safety or cryptography bug, but it removes a defensive check that previously prevented the local balance from dropping below a reserve threshold on inbound HTLCs.

This commit adds a new, clearly labeled API for opening Lightning channels to a trusted peer where the counterparty is allowed to keep zero reserve funds. The reserve normally prevents a peer from spending their entire balance, which protects against a specific cheap attack. The new method removes that protection intentionally, so it is only safe with a trusted counterparty. The commit itself documents this risk and does not appear to be a hidden vulnerability.

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.