rust-lightning

This commit adds internal bookkeeping to LDK's channel monitor so it can tell whether a channel uses 'manual' funding-transaction broadcasts and whether that funding transaction has actually appeared on-chain yet. The goal is to stop the node from broadcasting its own commitment transaction (a recovery/closing transaction) before the funding transaction exists on-chain, which would be pointless and could leak information or waste fees. It is a defensive correctness fix, not a patch for an active exploit.

This commit fixes a bookkeeping flag in the Lightning channel monitor. The flag `funding_seen_onchain` was not being set when the funding transaction was observed on the blockchain, even though the code already detected it. Setting the flag correctly helps the monitor know the channel is real on-chain and may affect later safety decisions, such as whether to accept certain updates or how to handle edge cases during channel closure.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `broadcast_latest_holder_commitment_txn` function. There is no change to program logic, behavior, or security.

This commit adjusts a CI test script to pin an older version of a Rust testing library called proptest, because the newly released version requires a newer Rust compiler than the project supports. It is a build/test infrastructure change with no security relevance.

This commit updates a test-only dependency version and removes a workaround pin for another dependency. It does not change production code, user-facing behavior, or any security-sensitive logic. There is no indication this is a security fix.

This commit only fixes documentation comments and a typo in a test-only assertion message. It does not change any executable code, cryptographic logic, or network behavior. There is no security issue here.

This commit fixes a race condition in how the Lightning networking code pauses and resumes reading from a peer's connection. Previously, the code could tell a caller to pause reading, but by the time the caller acted on it, the reason to pause had already gone away. This could leave a peer connection stuck: no new messages would be read, and because nothing was being sent either, there was no later signal to resume reading. The fix moves the pause/resume signal into the same path used to send data, so the two cannot get out of sync. The commit also notes a small new risk: a very fast message flood could briefly bloat memory before the next processing cycle pauses reads.

This commit tightens the rules for how Lightning Dev Kit hands groups of Bitcoin transactions to external broadcasting code. Previously, a broadcaster might have received several unrelated transactions or multiple 'child' transactions in one batch, and the documentation only said they 'may or may not' depend on each other. The change guarantees that any batch with more than one transaction is exactly one child transaction plus the parent transactions it depends on. It also updates LDK's own test broadcaster to verify this shape and fixes a test so its fake anchor transaction actually spends the commitment transaction, matching the new guarantee. The main risk is that real broadcaster implementations which relied on the old, looser behavior could have submitted invalid packages to Bitcoin Core's submitpackage RPC, causing broadcasts to fail rather than enabling theft of funds directly.

This commit fixes a bug in how the Lightning Dev Kit (LDK) handles key rotation when splicing a channel. Splicing is a way to resize a Lightning channel on-chain. The protocol only allows changing the 'funding key' during a splice, but LDK was accidentally asking the signer for a whole new set of keys. This could cause signature mismatches and break splicing. The fix adds a dedicated method to rotate only the funding key and keeps all other keys unchanged.

This commit only changes a test helper used during development. It adds an internal guard so that a mock signer in the test suite panics if its public keys are fetched more than once. It does not change production code, network behavior, or wallet security. There is no indication this fixes a real vulnerability.

This commit fixes a bug in how the Lightning node removes outdated short channel identifiers (legacy SCIDs). Previously, when every historical SCID was old enough to be removed, the code mistakenly removed none of them. This could leave stale routing identifiers in place longer than intended, potentially causing routing confusion or failed payments.

This commit adds a regression test for a splicing bug in the Lightning Dev Kit. The bug could leave a forwarded payment (HTLC) in a dangling state if a channel was spliced while the payment was still queued for forwarding. The test verifies that after upgrading from LDK 0.1, such HTLCs are correctly failed or claimed. The commit also exposes some internal test helpers so the new cross-version test can use them. It does not itself change production logic, so it is primarily a test/verification patch rather than a fix.

This patch fixes a bug where money-routing instructions (HTLCs) started in an older version of LDK could get lost if the channel was later upgraded via a process called 'splicing.' The old channel identifier was being deleted too soon, so when the software tried to fail the payment back to the sender, it couldn't find the channel anymore. The fix keeps those old identifiers around for about two months longer, giving the software time to properly return stuck payments.

This commit adds a new test case for the Lightning Dev Kit library. It checks that payment forwarding and failure handling still work correctly when a channel splice (a way to resize a Lightning channel) completes while a payment is still in flight. The commit does not change production logic; it only makes one internal constant visible to tests and adds test helper code. There is no indication of a security fix or vulnerability patch.

A single boolean argument in a function call was corrected during a process called 'splicing' (a way to resize a Lightning channel). The argument tells the code whether the local side is the one creating the commitment transaction. The commit message says this doesn't actually change the resulting transaction during splicing, because no pending payment updates are happening, but it is still correct to pass the right value. There is no clear security vulnerability here.

This commit is a minor code cleanup in the DNS resolver module. It changes several string-predicate calls from using multi-character string literals (like "." or "?") to single-character literals (like '.'). In Rust, using a char for single-character matching is slightly more efficient and idiomatic, but it does not change program behavior or fix any security issue. There is no security relevance in this change.

This commit fixes a bug where a specially crafted network message could cause the Lightning Dev Kit software to crash. The crash happens while reading a time duration from the message. The fix rejects obviously invalid duration values before they can trigger the crash. The bug was discovered by an automated fuzz tester, not a reported real-world attack.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's Rust implementation. It converts a chunk of logic that was previously duplicated through a macro into a regular Rust function. The behavior is intended to remain identical; the change only reduces code size and improves maintainability. There is no indication of a security fix or vulnerability being addressed.

This commit simply moves a block of code earlier in the same file. It is a pure code reorganization with no functional changes, no bug fixes, and no security relevance.

This commit is a small internal cleanup in the code that tracks pending Lightning channel monitor updates. It removes some unnecessary macro arguments and moves the logic for removing completed updates inside a shared helper macro. There is no indication this fixes a security bug or changes security-relevant behavior; it appears to be a refactoring/simplification.

This commit is a pure code cleanup: it renames an internal Rust macro to a longer, more descriptive name. No behavior, logic, or security properties change. It is not a security fix.

This commit tightens validation for BIP 353 Human Readable Names in rust-lightning. It now enforces that each dot-separated piece (label) of the user or domain is between 1 and 63 bytes, matching DNS label limits. Previously only the total length and non-emptiness of the whole user/domain were checked, so a name could contain an oversized label that other DNS software would reject. The change is defensive hardening rather than a clear exploit fix, but it prevents possible interoperability failures or parsing mismatches with downstream DNS components.

This commit removes a small helper trait called AddSigned and replaces its use with equivalent built-in Rust methods (checked_add_signed and saturating_add_signed on u64). The behavior of the code is unchanged; it is a cleanup made possible by raising the minimum supported Rust version. There is no security issue here.

This commit only adds a minimum supported Rust compiler version (1.75) to the package metadata for every crate in the project. It does not change any executable code, fix a bug, or alter runtime behavior. It is a build/tooling metadata change with no direct security relevance.

This commit removes unused data fields from test-only helper code in the rust-lightning project. It does not change any production code, network behavior, or cryptographic logic. There is no security relevance.