rust-lightning

This commit adds an early safety check in the code that builds Bitcoin funding transactions for Lightning channels. It now rejects duplicate inputs and duplicate outputs right when the transaction is being constructed, rather than waiting until later negotiation. Duplicate inputs could let someone try to spend the same coin twice in one transaction, and duplicate outputs could create bookkeeping confusion. The commit message says this was already blocked later in the process, so this is a fail-early hardening change.

This commit tightens a safety check in Lightning Dev Kit's splicing code. When a user tries to splice funds out of a channel, the library now records how much balance is actually spliceable right at the start and rejects requests that would overdraw it earlier in the process. Previously, that check happened later, so a user could construct a splice request that looked valid locally but would only be rejected when sent to the peer. The change also removes an internal helper type and carries the spliceable balance directly in the funding template. It is a defensive hardening change, not an obvious exploitable bug fix, but it prevents a class of invalid splice-out attempts from proceeding further.

This commit adds a new way to fund or top up a Lightning channel by letting the user explicitly pick which Bitcoin inputs (UTXOs) to use, with each input's full value going into the channel. It is a feature addition, not a fix for a known vulnerability. The change introduces careful checks to prevent mixing this manual-input mode with automatic coin selection, and it updates fee and balance accounting to handle full-input consumption safely. There is no evidence in the commit or supplied references that this resolves a security incident or was reported by an outside researcher.

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 fixes a bug in the Lightning Dev Kit's filesystem storage module. Previously, leftover temporary and 'trash' files from crashes or interrupted operations were mistakenly treated as real data folders during listing and migration. The patch makes the code skip these stale artifacts, preventing potential confusion or errors during data migration. It is a defensive hardening fix rather than a directly exploitable vulnerability.

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 only adds documentation comments to a public Rust enum field. It explains that when a splice negotiation fails, the returned contribution may still include inputs and outputs that are also part of an earlier, not-yet-locked splice transaction, and that those overlapping items are deliberately left out of a previous DiscardFunding event. There is no code behavior change, no bug fix, and no security patch.

This commit is a code-quality and correctness fix in a Lightning network library. It removes a risky pattern where an error reason was left as a placeholder ('Unknown') and only filled in later by callers. Some callers forgot to fill it in, so users could see a confusing 'Unknown' reason when a splice negotiation actually failed for a known reason. The change makes the reason mandatory at the moment the error is created, and removes a helper that made it easy to forget. It is not a direct exploit fix, but it prevents a class of state-reporting bugs that could hide what went wrong during channel operations.

This commit fixes a consistency gap in the Lightning Dev Kit: a setting that normally blocks very small inbound channels when they are first opened was not being checked after a 'splice' that shrinks the channel. A splice lets both parties add or remove funds from an existing channel without closing it. The change now applies the same minimum-channel-size rule to inbound splices where the other side is taking money out, preventing the channel from becoming smaller than the node operator allowed. The patch is defensive and adds tests, but it is narrowly scoped to one configuration check.

This commit fixes a potential denial-of-service (DoS) issue in the Lightning Dev Kit's transaction sync module. Previously, if the Bitcoin blockchain kept changing during a sync attempt, the code could loop forever trying to catch up. The patch limits this to 10 attempts before giving up and trying again later, preventing the node from getting stuck or wasting excessive resources.

This commit disables a feature that was temporarily storing extra routing data (onion packets) for every incoming payment in Lightning channels. The developers decided not to keep writing that data in production yet because they may not need it after all, and writing it on every save would be a large, uncertain commitment. It is a design rollback, not a fix for an active security bug.

This commit adds an optional `payment_metadata` field to BOLT 12 blinded payment contexts in the Lightning Dev Kit. It lets payment recipients attach small pieces of custom data (like an order ID) to a payment path, which are then returned to them when the payment arrives. The change is a feature addition, not a fix for a known vulnerability, and the metadata is explicitly treated as opaque data that LDK does not interpret.

This commit adds a new optional field called payment_metadata to BOLT 12 invoice request contexts in the Lightning Dev Kit. It lets payment recipients attach small pieces of custom data to an offer, which are then copied into the invoice and returned to them when a payment arrives. The change is a feature addition, not a bug fix, and the commit message and code comments explicitly warn that the metadata must stay small or payments could fail to route. There is no indication in the commit that this resolves a security 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 is a code-cleanup refactor that moves the calculation of a 'spiked feerate' (a safety buffer against sudden Bitcoin fee increases) from one part of the code to another. It does not change the actual multiplier value or the security policy; it only changes where the multiplication happens. The commit message explicitly says this is preparation for a future change, not a fix itself. There is no direct evidence in the commit that it repairs a vulnerability.

This commit fixes a bug in how Lightning Dev Kit calculates whether a channel funder can afford a sudden spike in Bitcoin transaction fees. Previously, the code assumed HTLCs (small conditional payments) that would become uneconomical at a doubled feerate were already trimmed away when checking the funder's buffer. This made the check too optimistic: it only verified the funder could survive an exact 2x fee jump, not any jump between normal and 2x. The fix counts HTLCs at the current feerate instead of the spiked one, ensuring the reserve covers the full range of possible fee increases. The commit is framed by its author as a correctness fix for fee-spike buffer accounting.

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 only adds a new regression test to the Lightning Dev Kit codebase. It does not change any production logic, fix a bug, or introduce a vulnerability. The test exercises a complex multi-path payment scenario across a node restart with partially persisted monitor state, verifying that HTLC fulfill messages are not left stuck after reload. It is defensive test coverage, not a security issue.

This commit fixes a bug in how the Lightning node calculates the reserve funds it must keep available to pay for a future emergency fee increase. Previously, the node counted how many small HTLC payments would be dropped from the transaction if fees spiked, and used that smaller number to estimate the required reserve. That could lead to an underestimate, because a fee spike could also trim additional HTLCs. The fix now counts non-dust HTLCs at the current feerate and reserves enough for any fee increase between 1x and 2x, not just exactly 2x. The risk is that a node might think it has more spendable balance than it actually can safely afford, potentially leading to a force-close or inability to cover fees during congestion.

This change cryptographically ties a piece of invoice data called payment_metadata to the payment secret. Before, a sender could alter that metadata in flight and the receiver would still accept the payment. Now, if the metadata is changed, the payment will be rejected. The change is a security improvement, but it breaks compatibility for existing invoices that already include payment_metadata when nodes upgrade or downgrade.

This commit changes how Lightning invoices are built in the LDK library. Previously, payment metadata was optional by default, and developers had to explicitly call a method to require it. Now, payment metadata is required by default, with an opt-out method for legacy compatibility. This is a defensive change to align invoice behavior with LDK's internal payment handling, reducing the risk of payment failures or ambiguity when metadata is omitted.

This commit is a simple renaming of internal variables, constants, and comments from 'metadata' to 'info' in one file. It does not change any program logic, cryptography, or behavior. The change was made to avoid confusion with a separate Lightning concept also called 'payment metadata'. There is no security issue here.

This commit replaces a hand-maintained list of suspicious Unicode characters with an automatically generated list based on official Unicode data. It also starts blocking unassigned Unicode code points. The change is a hardening improvement for the PrintableString sanitizer, which is used to safely display untrusted strings and prevent visual spoofing attacks like 'Trojan Source'. It is not a fix for a known active vulnerability in the current code.

This commit is a small internal cleanup in the Lightning Dev Kit's code for handling failed channel-funding negotiations (splicing). It moves the 'reason the negotiation failed' into the same error object that already carries other failure details, instead of passing it separately through several function calls. The change itself does not fix a vulnerability; it makes the code easier to maintain and ensures the correct reason is reported when a splice is canceled locally. There is no evidence in the commit of a security bug or exploit.