rust-lightning

This commit is a new regression test, not a fix. It verifies that a forwarding Lightning node can still claim two parts of a multi-path payment backwards after restarting, even if the node's temporary 'holding cell' state was lost during the crash. The test infrastructure was updated so the test can observe messages released from the holding cell during protocol exchanges. There is no production code change here.

This commit fixes a bug where a forwarding Lightning node, after restarting mid-payment, could emit a 'PaymentForwarded' event that was missing the identifier (next_user_channel_id) of the next channel the payment went through. The fix ensures the identifier is correctly looked up from the still-open channel state during startup. It is a data-correctness bug, not a direct loss-of-funds vulnerability, but it could break downstream accounting or automation that relies on this field.

This commit is purely a code-formatting cleanup. It removes a manual 'do not format' marker from one function and lets the Rustfmt tool reformat the code. No logic, behavior, or security properties of the software were changed.

This commit prepares the Lightning Dev Kit (LDK) to support a new 'phantom node' feature for BOLT 12 offers. It changes how encrypted control data in blinded payment paths and onion messages is authenticated: instead of checking one extra node-specific key, it now checks two keys (the existing node-specific key and a new shared phantom-node key). The commit itself does not enable the actual phantom-node building logic yet, but it adds the cryptographic plumbing so that future versions can authenticate blinded paths from any participant in a phantom-node setup while still keeping normal onion messages tied to a specific node.

This commit adds a seventh cryptographic key to an existing key-expansion routine. The new key is intended for a future feature where multiple nodes can share a 'phantom' blinded payment path. The change itself only extends the HKDF output and stores the extra key; it does not introduce a vulnerability or fix one.

This is a minor code cleanup change inside test helper macros. It replaces short internal names like `_reload_node` with fully qualified paths such as `$crate::ln::functional_test_utils::_reload_node`. This only affects how test macros resolve symbols when reused in other test crates; it does not change runtime behavior, user-facing APIs, or any security-sensitive logic.

This commit is a minor cleanup of an internal test file. It replaces a small block of test code with an existing helper function when testing the non-zero-conf path. There is no change to production code, no security fix, and no user-facing behavior change.

This is a small documentation and test cleanup commit. It removes leftover references to a 'manually_accept_inbound_channels' configuration option from two test files and a pending changelog entry. There is no code behavior change and no security fix or vulnerability present in the diff.

This commit is a small, internal refactoring of a Rust serialization macro used in the Lightning Dev Kit. It adds an optional read-time callback to the 'legacy' type-length-value (TLV) field variant so future code can validate or reject decoded legacy values. All existing usage sites pass a no-op callback that always succeeds, so the change does not alter current behavior. It is a defensive/extensibility improvement, not a fix for an active security bug.

This is a fix inside a single test function. The test had a tight loop that repeatedly checked for events without ever pausing, which could monopolize a lock and prevent another thread in the same test from making progress. The change adds a brief yield so the other thread can run. It only affects test code, not production code, and has no security impact on real users.

This commit is a straightforward observability and metadata improvement: it adds the channel counterparty's node ID to every variant of the TransactionType enum used when LDK broadcasts on-chain transactions. It does not change transaction logic, signatures, fee calculations, or who can broadcast what. Downstream users (such as custom transaction broadcasters or monitoring tools) now get extra context about which peer is involved in each transaction. The change includes a backward-compatibility shim that fills in a dummy counterparty ID when loading older serialized data and then overwrites it once the real value is read.

This commit is a routine API and data-model enhancement. It adds an optional 'counterparty_node_id' field to the internal record that tracks spendable Lightning outputs, and threads that value through the sweeper methods. The field is optional and backward-compatible, so older stored records still load. There is no indication this fixes a security bug or introduces a vulnerability.

This commit is a simple code cleanup in the project's test utilities. It moves a small helper function that reads the latest monitor update ID from one test file into a shared test helper struct, so other tests can call it more cleanly. There is no change to production code, no security fix, and no behavior change.

This commit is a pure test-code refactoring. It renames the default test channel configuration because anchor channels became the production default, and updates many tests to explicitly use a new 'legacy' configuration where they previously relied on the old default. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit removes the automatic acceptance of incoming Lightning channels in the LDK library. Previously, users could set a flag to automatically accept inbound channel requests. Now, every inbound channel request must be explicitly approved by the user through an OpenChannelRequest event. This is a deliberate design change to ensure users verify they have enough on-chain funds to cover fees, especially with upcoming anchor channel defaults. It is not a fix for an active vulnerability, but it prevents accidental or unsafe channel acceptance.

This commit adds support for asynchronous (delayed) signing when opening or splicing Lightning channels that use the newer interactive-funding protocol. Previously, if a hardware or remote signer was not ready to produce the initial commitment signature, the code either did not support the delay or could accidentally send transaction signatures before the commitment signature was ready. The change holds back the transaction-signature message until the commitment signature is available, and adds a regression test for splicing. It is a protocol-correctness and robustness improvement rather than a fix for an active exploit.

This commit fixes a bug in a fuzzing-only (test-only) fake version of the ChaCha20 encryption code. The fake encryptor accidentally left the output as all zeros instead of copying the input, which caused simulated Lightning payments to fail during testing. The fix makes the test fake copy input to output unchanged. This is not a real cryptographic vulnerability and does not affect production code.

This commit fixes a potential integer overflow bug in the Lightning Dev Kit's channel splicing code. The bug occurs when converting a negative Bitcoin amount to its absolute value in debug builds, which could crash the program. The fix uses a safer method that cannot overflow. The practical security impact is limited because the overflow only happens in debug mode and the affected values are normally constrained by protocol rules.

This commit only changes version numbers in package configuration files (Cargo.toml). It bumps crate versions from 0.2.x to 0.3.x to keep them aligned with semantic versioning rules after the underlying `lightning` crate changed its public types. There is no code change, no bug fix, and no security patch.

This commit is a documentation-only update to the 0.2 release CHANGELOG. It adds a note warning users that if they upgrade to LDK 0.2, create BOLT 12 offers, and then downgrade to an older LDK version, those offers will not be accepted. This is a compatibility/operational issue, not a security vulnerability, and no code behavior is changed.

This commit is a pure internal refactoring in the Lightning Dev Kit Rust library. It introduces a new helper trait called AChainMonitor that wraps the existing ChainMonitor type, and updates background-processor functions to use that trait instead of listing many generic type parameters directly. There is no change to user-visible behavior, no bug fix, and no security-sensitive logic change.

This commit adds a new helper function to create a UTXO descriptor for modern Taproot (P2TR) single-key spending. It is purely additive API surface with no changes to existing behavior, no bug fixes, and no security-sensitive logic beyond correctly estimating transaction weight for fee calculations.

This commit only adds and improves test code. It gives the project's test mock broadcaster the ability to remember what 'type' each broadcast transaction was (for example, a splice transaction), and updates tests to check that splice transactions are labeled correctly. There is no change to production code that handles real money or network messages, so it does not introduce or fix a security vulnerability on its own.

This commit is a straightforward API refactor: it adds a TransactionType label (Funding, Close, Claim, Sweep, etc.) to every place in the Lightning Dev Kit that broadcasts a Bitcoin transaction. The actual transactions being broadcast do not change; only the metadata passed alongside them changes. There is no security vulnerability being fixed or introduced here.

This commit is a straightforward code cleanup in a Rust Lightning library. It stops hiding an internal module behind re-exports and exposes it directly in the public API. The change fixes an earlier accidental break in the public API where a type (CustomTlvs) was used in a public struct but not re-exported, making it hard for downstream developers to use. There is no runtime security issue, no bug fix in payment logic, and no exploit.