rust-lightning

This commit fixes a crash bug in the Lightning Dev Kit's on-chain transaction handler. During a deep blockchain reorganization, a previously settled HTLC claim could be 'resurrected' at a block height where it could no longer be combined with a surviving claim. The old code used an assertion that assumed merging would always succeed, so the node would panic and shut down. The fix checks whether merging is possible first; if not, it preserves the resurrected claim so it can be broadcast independently. A regression test reproduces the exact reorg scenario.

This commit simply updates the 'repository' web links in 15 package metadata files from GitHub to a self-hosted Forgejo instance. It does not change any program code, build logic, dependencies, or security behavior. There is no security issue here.

This commit fixes a small but real accounting bug in how rust-lightning checks whether a previous transaction (prevtx) attached to a funding input will make the resulting Lightning wire message too large. The code previously compared the message body length against the 65,535-byte wire limit, but forgot to add the 2-byte message type prefix. That meant a prevtx could be accepted even though the final on-the-wire message would exceed the protocol's maximum size, which would likely cause the peer to reject or fail to parse the message. The fix adds those 2 bytes to the calculation and updates the test to hit the real boundary.

This commit fixes a bug in the Lightning Dev Kit where, after a disconnection, a node could fail to retransmit a 'splice_locked' message to a peer that was still waiting for transaction signatures. Without this retransmission, the two peers could get stuck and not agree on the new channel funding, potentially leaving the channel unusable or in an inconsistent state. The fix ensures the required message is resent so both nodes converge correctly.

This commit adds a new API, pay_for_bolt12_invoice, that lets users pay a BOLT 12 invoice even if LDK did not originally request it. It is intended for advanced use cases like multi-sender payments and replaces an older, more restrictive API. The change itself is a feature addition with deprecation of old methods, not a fix for an active vulnerability. The main security consideration is that the new API places more responsibility on the caller to verify invoices and avoid duplicate payments; misuse could lead to paying an attacker’s invoice or double-paying, but the commit documents these risks clearly and adds validation for amounts and features.

This commit fixes a small accounting bug in how the Lightning wallet estimates the size (and therefore transaction fee) of a special Bitcoin transaction that sweeps funds back to the user after a channel closes. The old code always assumed the largest possible 4-byte encoding of a delay value, even when the real value used only 1 byte. That could make the fee estimate slightly too high and, in rare cases with a short digital signature, trigger an internal debug-only assertion failure. The fix computes the exact size based on the actual delay value and adds a regression test. It is not a remote exploit and does not risk loss of funds.

This commit only updates documentation comments for a Rust function called get_per_commitment_point. It removes an outdated warning that the method was non-asynchronous and that returning an error could cause a crash, and replaces it with guidance that errors can signal a temporarily unavailable signer and how to retry. No actual code logic was changed, so there is no direct security vulnerability introduced or fixed by this patch itself.

This commit is a small internal code cleanup in the Lightning Dev Kit's Trampoline routing code. It removes a separate 'BlindedTrampolineEntrypoint' payload variant and folds an optional blinding point into the existing 'Forward' variant. The change simplifies the code but does not appear to fix a security bug or change wire behavior in a way that introduces vulnerability. It is a refactor, not a security patch.

This commit changes a fuzz-testing harness, not the production Lightning node code. It loosens a test rule so the fuzzer can simulate force-closing a channel that has no pending payments of its own, even if other channels in the test still have in-flight payments. When that happens, the test now marks any payment that routed through the closed channel as allowed to fail. This is a testing-infrastructure improvement and does not change how real users' funds or channels are handled.

This commit is a fuzz-test hardening change, not a fix for a live security bug. It makes an internal test harness stricter about when a simulated Lightning payment is allowed to fail, so the fuzzer can catch unexpected failure paths. It does not change production code that handles real funds.

This is a small internal cleanup in a fuzz-testing file. It renames a helper function and routes a few bookkeeping calls through a single new helper. There is no change to production code, no change to user-facing behavior, and no security fix.

This commit changes internal fuzz-testing code only. It adds extra bookkeeping so that simulated payment paths remember both a short channel ID and a channel ID. The commit message explicitly says the new fields are not used yet and that this is mechanical preparation for future work. There is no change to production code, no user-facing behavior change, and no security fix or vulnerability introduced in the diff itself.

This commit is a refactoring of internal fuzz-test code only. It changes how fake Lightning payment routes are built in a test harness so that route construction uses a single shared helper instead of hand-written route structures. There is no change to production code, no user-facing behavior change, and no security fix or vulnerability.

This commit only changes internal fuzz-testing code in rust-lightning. It adds plumbing to track the minimum final CLTV expiry for simulated payments and threads a PaymentTracker through more test helpers. The commit message explicitly says the new value is not yet used and that this is preparation for a later commit. There is no change to production Lightning logic, no fix for a vulnerability, and no security-relevant behavior change.

This commit changes an internal fuzz-testing harness in the rust-lightning project. It tightens how the test tracker records and resolves simulated Lightning payments, and adds assertions so the test harness panics if it sees unexpected payment states. It does not change production Lightning node code, network behavior, or wallet logic, so it is not a security fix that affects real users.

This change fixes a bug in how Lightning blinded paths choose a compact reference to the introduction node. Previously, the code could pick an old channel that was disabled or effectively closed, making the resulting BOLT 12 offer or blinded path unusable for senders. The fix only selects channels that are enabled in both directions, and falls back to a full node identifier if none qualify. The main risk is reliability and path reachability, not theft of funds or direct remote exploitation.

This commit changes the project's internal code-review workflow. It stops automatically assigning a human reviewer when a pull request is opened; instead, contributors must manually click a button to request a reviewer after first addressing an AI review. It also limits who can request extra reviewers. There is no change to the actual Lightning node software, cryptography, network protocol, or any user-facing security behavior.

This commit changes how a Lightning node handles DNS proof responses for human-readable names (like BIP 353 addresses). Previously, if a DNS proof was invalid, expired, or didn't contain a usable Bitcoin offer, the code silently returned nothing, leaving pending payment requests stuck. Now the code explicitly marks those pending requests as failed and returns the failure to the caller. This is a reliability and minor security improvement: it prevents resolution attempts from hanging indefinitely and lets callers react to bad DNS data rather than waiting forever.

This commit adds a new error-reporting path in a Lightning DNS resolver. Previously, if a DNSSEC proof lookup failed, the resolver simply stayed silent. Now it sends back an explicit 'DNSSECError' message so the requester knows the lookup failed and can fall back or fail the payment faster. The change is a feature addition with a small, well-scoped security benefit: it removes a silent-failure mode that could cause payment delays or user confusion. There is no evidence of a vulnerability being fixed, and no attacker-controlled behavior is introduced.

This commit fixes a typo-like bug in how DNSSEC proofs are checked against the latest known block time. The code was meant to allow a two-hour time window but accidentally used a two-minute window. This could cause valid DNSSEC proofs to be rejected too aggressively, especially on systems without the standard library or during fuzz testing. The commit message says this is unlikely to have affected real users because DNSSEC proofs are normally valid for many hours and safety margins are already applied.

This commit is a simple rename of a Rust method from `resolve_name` to `initiate_resolution`, plus matching updates to comments and test code. It does not change what the code does, only how it is named and described. There is no security issue here.

This commit only adds two explanatory comments to the code. It does not change any program behavior, fix any bug, or alter any logic. The comments clarify that although the code is written to handle multiple failed DNS resolutions at once, in practice only one can fail at a time because each resolution uses a unique random identifier.

This is a tiny code cleanup inside a test file. It renames a local variable from `pending` to `pending_resolves` and introduces a helper variable `pending_queries_for_name` to avoid repeating the same lookup expression. There is no change to production code, no security fix, and no behavior change.

This commit fixes two related issues in rust-lightning's payment scorer. First, two public accessor methods that report estimated payment success probabilities could trigger a debug-only assertion (a crash in debug builds) when asked about an amount equal to or larger than a channel's maximum liquidity. Second, the methods now return the same probability values actually used internally for routing decisions, including a 1% minimum probability floor. The practical effect is that callers get consistent, non-crashing estimates instead of raw values that could be zero or trigger internal checks.

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations and lets rustfmt reformat several functions in the routing/scoring module. No logic, behavior, or security properties of the code are changed.