rust-lightning

This commit makes a piece of routing data called route_params mandatory in the Lightning Dev Kit library. Previously it was optional, and the code would silently invent a dummy value if it was missing. Now it must always be provided, and old serialized routes written before version 0.0.117 will fail to load. This is a deliberate backwards-compatibility break, not a security fix, and it reduces the risk of inconsistent or missing routing information rather than introducing a vulnerability.

This commit fixes a replay-protection bypass in LSPS5 webhook signature handling. The system uses zbase32-encoded signatures, which treat uppercase and lowercase letters as the same value. The replay cache, however, stored the raw signature string, so an attacker could resubmit the exact same webhook with only the letter case changed and bypass the replay check. The fix converts the signature to lowercase before checking or storing it in the cache, and a new test confirms the bypass is closed.

This commit fixes a validation bug in how Lightning Dev Kit checks 'fake' short channel IDs (SCIDs) used for routing tricks like phantom and intercept payments. The old check compared only the lowest byte of the vout field, so an attacker could set the high byte of the vout and still pass validation. The fix now compares the full 16-bit vout value. The project says this is not directly exploitable for stealing funds, but it could cause a spurious internal event and makes the validation more correct.

This commit removes an old cryptographic nonce from the data carried inside Lightning "blinded paths" used when sending BOLT 12 offers and refunds. The nonce is no longer needed because a newer "payer metadata" field already carries the same secret. The commit keeps the payment ID in the blinded path and uses it to make sure an incoming invoice really belongs to the payment it claims to belong to. That prevents an attacker who captures one blinded path from delivering a different payment's invoice over it, which could otherwise link two of the user's payments together. The change is mostly a cleanup, but it also tightens the matching logic slightly.

This commit changes how BOLT12 invoices are verified in the Lightning Dev Kit. Previously, some invoices could be verified using a nonce stored in the blinded reply path context. Now, the nonce is always included inside the encrypted payer metadata carried by the invoice request or refund. This makes invoices self-contained and prepares the code for future payment proofs. It is a protocol-correctness and forward-compatibility change, not a fix for an active exploit. Old invoice requests/refunds with blinded paths created before this change will fail verification and must be retried with a new payment id.

This commit fixes a bug in how Lightning Dev Kit describes anchor outputs when preparing transactions for external wallets to sign. Previously, for a type of anchor tied to a specific channel key, the code returned the raw 'witness script' (the spending conditions) instead of the proper P2WSH address/script pubkey. Wallets use this data to identify and validate the coin being spent. Providing the wrong descriptor could cause wallets to reject the PSBT or, in worst cases, misidentify the output, potentially leading to invalid transactions or unsafe signing behavior. The fix converts the redeemscript to its P2WSH script pubkey, and adds a regression test.

This commit changes a fuzz test (a randomized testing harness) so it no longer crashes when a simulated splice-funding signing event becomes stale. The change only affects test code, not the production Lightning library, and it ignores an expected error rather than fixing a runtime security bug.

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 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 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 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 patch fixes a logic gap in Lightning Dev Kit's interactive splicing handshake. During a channel reconnection, the code could re-send a commitment signature for a new funding transaction before the user had actually approved and provided their own transaction signatures. The fix gates that retransmission so it only happens after the user calls funding_transaction_signed, preserving the intended 'cancel up to the last moment' behavior.

This patch fixes a crash bug in the Lightning routing code. When a user disabled the normal cap on routing fees, a malicious or specially crafted payment invoice containing route hints with extremely high proportional fees could cause an internal arithmetic overflow. Previously this overflow made the program panic; now the code detects the overflow and treats that route as unusable, so routing fails cleanly instead of crashing.

This commit fixes an internal accounting issue that only appears when running the code under a special fuzz-testing build of the secp256k1 cryptography library. In that test-only mode, dummy signatures can be one byte larger than normal, so the code now adds a small buffer to transaction weight estimates. This prevents debug-only assertions from failing and keeps batch-size calculations from being slightly too optimistic during fuzz testing. It does not change behavior in normal production builds and does not introduce a real-world security vulnerability.

This commit fixes a fuzz-testing configuration issue. The project has a feature called 'grind_signatures' that makes cryptographic signatures slightly smaller on average, but it is meant only for real network use because it changes transaction weights. The fuzz tests were accidentally inheriting this feature, which could make fuzzing miss bugs that appear with the normal signature size. The patch disables the feature in fuzz builds and adds a compile-time guard to prevent accidentally enabling it in fuzzing mode. It also updates a hard-coded test seed to match the new (slightly larger) transaction weight.

This commit only adds a comment explaining existing behavior in a Bitcoin Lightning funding function. It does not change any code logic. The behavior being documented—filtering duplicate outputs based only on their script address—could theoretically let a malicious or buggy participant hide funds in some edge cases, but the commit itself is a documentation-only change and does not introduce or fix a vulnerability.

This commit is purely a code-formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets Rust's automatic formatter re-indent a function. No logic, behavior, or security properties of the code change.

This commit adds support for asynchronous signing of the shared input in a Lightning channel splice. Previously, the signature for the 2-of-2 multisig input had to be produced immediately when requested, which could block users whose signing hardware or policy requires delays. The change allows the signer to return an error and retry later, and it reworks the internal state machine so the splice negotiation waits cleanly until that signature is available. It is a feature/robustness improvement rather than a fix for an active exploit.

This commit tightens how Lightning Dev Kit calculates the channel reserve for older-style (v1) channels. The reserve is a portion of channel funds that must stay untouched to guarantee both parties can pay penalties if someone cheats. Previously, a misconfigured or malicious proportion could make the calculated reserve exceed the entire channel value, or a tiny channel/dust limit could produce a nonsensical reserve. Now the code rejects those cases outright and also caps the proportional reserve at 100%. The change is defensive: it prevents opening channels with impossible reserve settings rather than silently accepting them.

This commit renames and flips the meaning of a flag used during Lightning channel splice negotiations. It changes when the software decides to keep or discard an in-progress splice after a disconnect or abort. The change appears intended to support a new 'user manually cancels' case, but the logic is subtle: several call sites now pass the opposite boolean, and the function's internal cases were reordered. There is no direct evidence this fixes an exploitable vulnerability, but the change touches safety-critical state cleanup during channel funding/splicing, where mistakes can lead to stuck funds or inconsistent channel state.

This commit fixes a security gap in LDK's string sanitizer, PrintableString, which is used to display untrusted text like node names and invoice descriptions in logs and user interfaces. Previously it only stripped traditional control characters (like newlines and tabs) but left behind Unicode 'format' characters, including invisible bidirectional override characters and zero-width spaces. These can trick a human reader into seeing a different string than what the software processes—an attack family known as 'Trojan Source.' The patch now replaces those format characters with the standard replacement symbol (), so spoofed strings render safely.

This is a small code cleanup in the Lightning payment channel code that handles failed or aborted splice-in transactions. The change removes an unnecessary check when undoing a splice contribution, replacing it with an unconditional pop plus a debug-only sanity check. The commit message argues the old check could never trigger, so behavior should be unchanged. There is no direct evidence of a security bug, but any change to state-rollback logic in financial software warrants careful review because mistakes can leave funds in an inconsistent state.

This commit removes the project's own implementations of the ChaCha20 stream cipher, Poly1305 message-authentication code, and the ChaCha20-Poly1305 combined encryption mode. It is described as the final step of migrating to the external 'rust-bitcoin chacha20-poly1305' crate. The change itself is a pure deletion of local code and module declarations; it does not add the replacement crate or change any call sites in this diff. There is no direct evidence in the commit that this fixes a security vulnerability.