rust-lightning

This commit fixes a validation bug in rust-lightning's BOLT12 offer handling. An offer that says 'buy up to N items' was accidentally accepting requests to buy 0 items, which is meaningless and could let someone request an invoice for nothing. The fix now rejects zero-quantity requests for bounded-quantity offers, matching the intended behavior.

This commit changes how Lightning payment routes pick the identifier used for the first hop of an outbound payment. Previously the real channel ID was preferred; now a stable alias is preferred. The goal is to keep routes valid when a channel is 'spliced' (its on-chain funding transaction changes), because the real ID changes after a splice while the alias stays the same. The change is framed as a robustness improvement, not a security fix, though it can prevent payment failures and related error-handling edge cases.

This commit fixes a copy/paste typo in a deserialization routine. The code was preallocating a HashMap using the wrong length variable, which could cause either excessive memory allocation or insufficient preallocation when loading on-chain transaction data. The actual loop that reads entries still uses the correct length, so the functional behavior is mostly unchanged, but the preallocation amount could be manipulated by an attacker crafting input data.

This commit changes how LDK creates hidden ("blinded") messaging paths for BOLT 12 offers. Previously, LDK tried to pick a well-connected peer as an "introduction node" to receive messages on your behalf, which improved privacy. Because lnd nodes will soon refuse to forward such messages from peers without a channel, LDK now always uses the offer creator itself as the introduction node (if publicly announced). This avoids broken offers but reduces privacy. It is a compatibility/reliability fix, not a patch for an active exploit.

This commit fixes a small bookkeeping bug in the Lightning Dev Kit. When a user abandoned an in-flight payment but the payment still succeeded later, the reported fee field was incorrectly left blank (None), even though the documentation promised it would always be filled in for newer versions. The patch preserves the fee amount when a payment is abandoned so it can still be reported correctly if an HTLC later succeeds. There is no direct security vulnerability here—no funds are stolen, lost, or incorrectly routed—but it removes a contradiction between documented behavior and actual behavior that downstream software might rely on.

This commit fixes a bug in the Lightning Dev Kit where restarting a node during a certain type of funding negotiation (RBF splice) could accidentally throw away already-agreed splice candidates. Previously, the code avoided saving incomplete negotiations on reload, but with RBF support that also dropped earlier negotiated splice states that the channel monitor was still tracking. The fix separates the live negotiation state from the negotiated candidates during serialization, so reload cancels only the in-flight negotiation while preserving the prior candidate. The bug is a state-consistency/data-loss issue rather than a direct theft vector, but it could disrupt channel operation or funds availability after a restart.

This commit adds new async (non-blocking) versions of existing filesystem data migration helpers for two versions of the Lightning Dev Kit persistence store. It mostly moves existing synchronous key-listing code into a shared helper and wraps it in an async task when the tokio feature is enabled. There is no obvious security bug introduced; it is a feature/refactoring change with added test coverage.

This commit adds a new async-capable API for migrating key-value store data in the Lightning Dev Kit Rust library. It is a feature addition that lets asynchronous storage backends copy their data without falling back to synchronous calls. There is no indication in the commit that this fixes a security bug or introduces a vulnerability.

This commit is a simple rename of a Rust programming interface (trait) from MigratableKVStore to MigratableKVStoreSync. It only changes names to make room for a future asynchronous version. No behavior, logic, or security properties of the code are changed.

This commit adds a symbolic link named AGENTS.md that points to an existing file called CLAUDE.md. It is purely a repository documentation/AI-agent guidance change and does not modify any code, configuration, or security-sensitive files.

This commit is a code cleanup and performance improvement. It introduces a new Rust macro that automatically generates both the 'write' and 'serialized_length' functions for certain data structures from a single field list. Previously, these two functions were written separately, which made it easier for them to become inconsistent. The change applies this new macro to hot-path channel funding and commitment transaction serialization, but leaves the corresponding read/deserialization code untouched. There is no indication of a security bug being fixed.

This commit adds faster, direct ways to calculate how many bytes certain data wrappers will take up when serialized. Previously, these lengths were sometimes computed by actually writing the data to a temporary in-memory buffer and measuring the result. The change avoids that extra work for common wrapper types like references, boxed values, optional values, and length-prefixed collections. It is a performance and code-quality improvement, not a fix for a known security vulnerability.

This commit is a pure code cleanup: it renames internal Rust macros from impl_writeable_tlv_based* to impl_ser_tlv_based* across many files. The generated serialization and deserialization code is unchanged, so there is no functional or security impact.

This commit tightens a safety check in a new version of Lightning Dev Kit's file-based storage. The new store (v2) organizes data into folders-within-folders. Previously, it only rejected old v1 data if a stray file sat directly in the root folder, but it missed cases where an old-style file sat one folder deeper. That could let an incompatible v1 data file hide inside what looked like a valid v2 namespace folder, potentially causing confusion or data corruption when the v2 store later tries to use that folder as a namespace. The fix now scans one level deeper and refuses to open the store if it finds such files.

This commit fixes a bug in the Lightning Dev Kit where a proposed channel splice could be incorrectly rejected when there were still unconfirmed updates (like HTLC fulfillments) pending in the channel. The fix skips an internal consistency check in that specific situation, because the check would compare numbers that are temporarily out of sync but will match once the pending updates clear. The bug was found by the developers' own fuzzing, not by an external security researcher.

This change is a developer convenience tweak for the project's internal fuzz-testing programs. It adds an environment variable switch (LDK_FUZZ_SUPPRESS_LOGS) that lets automated fuzzing runs stay quiet, while keeping normal manual runs verbose. It does not touch any production Lightning node code, wallet logic, or network handling, and it does not fix or introduce any security vulnerability.

This commit only fixes compiler warnings that appear when building the project's fuzzing test harness. It removes one unused import, narrows three conditional compilation flags so they don't conflict during fuzz builds, and reduces the visibility of one internal encryption helper from public to crate-internal. None of these changes affect runtime behavior or fix any security vulnerability.

This commit re-enables an existing fuzz test for a feature called 'splicing' and adds test coverage for one more signer operation. It only changes test/fuzzing code, not the production Lightning protocol code that real users run. There is no indication it fixes a security bug or changes runtime behavior.

This commit changes only a fuzzing test harness (chanmon_consistency.rs). It updates how the test handles peer-disconnect errors so that, when a disconnect happens during a quiescent (splice-related) state, the test manually clears that quiescent state on both sides. This is a test-only fix to prevent fuzzing false-positives; it does not change production code or fix a real-world security vulnerability.

This commit changes how Lightning Dev Kit handles optional extra data attached to incoming payments (called payment_metadata). Previously, LDK expected downstream applications to encrypt that data themselves before handing it to LDK. Now LDK encrypts and decrypts it internally, reusing random values already generated for payment secrets. The goal is to avoid making invoices larger by adding separate encryption overhead. For payments where the user supplies their own payment hash, a fresh random value is appended to the encrypted metadata, with a documented warning that reusing the same payment hash with different metadata is unsafe. The change is a privacy/usability improvement, not a fix for an active vulnerability, and it includes new tests covering the three ways metadata can be created.

This commit is a code cleanup: it moves repeated ChaCha20 encryption calls into a single helper function without changing the underlying math or behavior. There is no indication it fixes a security bug or introduces a new vulnerability.

This commit changes an internal fuzz-testing harness (a tool used to automatically find bugs during development), not the production Lightning node code that users run. It adds bookkeeping so the test harness can track which simulated payments were created before or after a saved snapshot of node state. When the harness reloads an older snapshot, it now discards payments that were born after that snapshot, keeping the test's internal tracking consistent. There is no direct security fix to real user funds here.

This is a code cleanup change inside a fuzz-testing file. It moves some bookkeeping helper methods from one struct to another without changing what the code actually does. There is no user-facing or security-relevant change.

This change is an internal performance optimization for the Lightning Dev Kit (LDK). It reduces unnecessary disk writes by skipping ChannelManager persistence when a monitor completion event only produces messages and does not change any important channel state. The commit does not fix a vulnerability and does not change protocol behavior; it only changes when the software decides to save data to disk.

This commit is a small internal code cleanup in the Lightning Dev Kit (LDK) Rust library. It changes a helper function so it returns a richer status code instead of a simple true/false, letting callers decide more precisely whether to save state and whether to keep processing events. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a correctness and maintainability improvement.