rust-lightning

This commit only updates version numbers in package configuration files after a software release. It changes references from version 0.2.0 to 0.3.0 across several related crates and bumps the main crate's version label from 0.2.0+git to 0.3.0+git. There are no code changes, no security fixes, and no behavior changes.

This commit only updates the project's CHANGELOG.md file. It adds the release date for version 0.2, adds a note that Bitcoin Knots blocks certain transactions by default, clarifies documentation about a socket method's behavior, adds release statistics and contributor names, and adds a new section for version 0.1.8 bug fixes. No actual code was changed.

This commit is purely a code-formatting cleanup. It removes a #[rustfmt::skip] annotation and lets Rust's automatic formatter reformat one function in the Lightning channel manager. No logic, behavior, or security properties of the code are changed.

This commit only adds and adjusts log messages to help developers debug channel state. It does not change program logic, permissions, or data handling. There is no security issue here.

This commit simply adds another build-output directory to the project's .gitignore file. It has no effect on running code, user data, or security.

This commit only changes how an internal test helper is exposed. It renames a private test-only function and makes it callable from integration tests, with no effect on normal production code. There is no security issue.

This commit adds three new error-code names to an existing internal lookup table that converts numeric codes into human-readable failure reasons. It is a straightforward code-completion change with no visible security effect.

This commit only changes the text of an error message. It does not alter any logic, checks, or behavior. The old message was misleading because it suggested a validation failure, while the actual failure is an arithmetic underflow when calculating the next hop's amount or timelock. The new message describes the real cause more accurately.

This commit fixes a bug in the Lightning Dev Kit (LDK) where a channel could get stuck waiting on itself after a multi-path payment (MPP) was claimed. Previously, when a monitor update completed but another monitor update was blocked, LDK skipped important follow-up actions, such as emitting the PaymentClaimed event and releasing held HTLCs. The fix ensures these follow-up actions run even when the channel still has blocked monitor updates, preventing channels from hanging.

This commit only updates documentation comments in the source code. It explains that certain channel details stay the same during a splice until the splice is finalized. No code behavior was changed, so there is no security issue.

This commit is a minor logging and API cleanup change. It changes the LiquidityManager persistence methods to return a boolean indicating whether any data was actually written, and only logs a 'Persisted' message when something was actually saved. Previously, the background processor logged 'Persisting LiquidityManager...' on every wakeup even when there was nothing to save, which could produce excessive log output. There is no security issue here.

This commit is purely a code formatting cleanup. It removes manual rustfmt skip annotations and lets rustfmt reformat several match statements and function signatures in the Lightning channel code. There are no logic changes, no security fixes, and no behavior differences.

This commit is a straightforward internal code cleanup: it changes a Rust enum variant from storing two unnamed fields to storing two named fields. It does not alter what data is stored, how payments are validated, or any network-visible behavior. There is no security fix or vulnerability here.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel handling code. It changes how data is packaged inside an internal enum (InboundHTLCRemovalReason) from unnamed tuples to named struct fields, so that future serialization code can handle it more easily. There is no change to security logic, no bug fix, and no externally visible behavior change.

This commit adds safety checks in the Lightning Dev Kit (LDK) to ensure that the inner 'trampoline' payment instructions match the outer onion packet's amounts and deadlines. Without these checks, a malicious or buggy sender could craft a trampoline payment where the outer layer promises one amount or deadline while the inner layer demands a higher one, potentially allowing a node to be tricked into accepting or relaying an inconsistent payment. The patch enforces that the outer onion's amount and CLTV expiry are at least as large as the trampoline onion's, and adds tests for underpayment and deadline mismatch cases.

This commit only adds new test cases to the project's test suite. It does not change any production code. The tests verify that the software correctly handles tiny fractions of Bitcoin (millisatoshis) when building special zero-fee Lightning commitment transactions, including cases where dust amounts add up. There is no indication of a security fix or vulnerability being patched here.

This commit adds the funding redeem script (the cryptographic lock script for a Lightning channel's funding output) to the SplicePending event that LDK emits when a splice is being negotiated. It is an API/data-visibility change, not a logic fix. There is no direct evidence in the commit that this resolves a security vulnerability; it appears to give downstream wallet software the information it needs to recognize and spend the new funding output after a splice.

This commit adds a new piece of public information—the funding redeem script—to two existing data structures that describe Lightning channels. It does not change how funds are secured, how transactions are signed, or how peers communicate. It simply lets downstream wallet software reconstruct the channel's funding transaction output so it can calculate fees more accurately when splicing funds into a channel. There is no indication this fixes a vulnerability or introduces a new attack path.

This commit adds three new error-code labels used when a Lightning payment fails while being forwarded through a special routing feature called Trampoline payments. It is essentially a standards-compliance update that maps new internal reasons to the correct numeric failure codes and serialization IDs. There is no direct evidence this fixes an active security bug or vulnerability.

This commit is purely a code cleanup: it tidies up formatting in a test function and extracts a small helper to reduce repetition. There is no change to production behavior, no bug fix, and no security relevance.

This commit is purely a code-formatting cleanup in a test file. It removes a directive that told the Rust formatter to ignore a particular test function, then re-wraps long lines so the code follows normal style rules. No program behavior, logic, or security-sensitive code is changed.

This commit is a code-style cleanup in a test file. It removes a file-wide directive that told the Rust formatter to ignore the file, and instead marks individual helper functions to skip formatting. The actual test logic and program behavior are unchanged.

This commit improves how the Lightning node handles reconnections after a network interruption. Previously, when re-establishing a channel, the node sometimes had to ask an external signer for a cryptographic proof point and could not proceed until the signer responded. The change keeps the two most recent revoked proof points cached locally so the common case no longer needs to wait for the signer. It only defers to the signer asynchronously in the rare 'stale state' case, where the peer claims our node is behind. That stale case either proves data loss (causing a protective panic) or proves the peer is lying (causing a force-close). The commit is a defensive hardening/feature change, not a fix for an active exploit.

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations from a few functions in the Lightning channel manager and lets rustfmt reformat the code. No logic, behavior, or security properties of the program change.

This commit is a code cleanup change. It removes repeated node IDs and payment hashes from individual log messages because the logging framework now automatically includes those details as structured fields. No security vulnerability is fixed or introduced; it only makes log output less cluttered.