rust-lightning

Include to_self_delay size in DelayedPaymentOutput weight calculation

SpendableOutputDescriptor::create_spendable_outputs_psbt estimated the
witness weight of a to_local (DelayedPaymentOutput) input using
MAX_WITNESS_LENGTH, which assumes the maximum 4-byte OP_CSV push of
to_self_delay in the redeemscript. The real push can be as small as 1
byte for small to_self_delays, causing the estimate to overshoot by up
to 3 WU. If this overshoot occurred in addition to a short signature,
the max-overshoot debug_assert in KeysManager::spend_spendable_outputs
would fail.

Add DelayedPaymentOutput::max_witness_length, which computes the witness
length from the descriptor's actual to_self_delay, and use it in place
of the MAX_WITNESS_LENGTH constant. This produces a more accurate
weight estimate so that the debug_assert in spend_spendable_outputs
never fails.

This bug was discovered using Smite.

Correct docs on `ChannelSigner::get_per_commitment_point`

This was apparently missed in 1f7b24900d16c841d55fc83e0e2057e241d5e

ln: add ForwardToTrampoline tail and blinding in new_trampoline_entry

When we are forwarding as a trampoline within a blinded path, we need
to be able to set a blinding point in the outer onion so that
the next blinded trampoline can use it to decrypt its inner onion.

This is only used for relaying nodes in the blinded path, because the
introduction node's inner onion is encrypted using its node_id
(unblinded) pubkey so it can retrieve the path key from inside its
trampoline onion. Relaying nodes node_id is unknown to the original
sender, so their inner onion is encrypted with their blinded identity.
Relaying trampoline nodes therefore have to include the path key in the
outer payload so that the inner onion can be decrypted, which in turn
contains their blinded data for forwarding.

This isn't used for the case where we're the sending node, because all
we have to do is include the blinding point for the introduction node.
For relaying nodes, we just put their encrypted data inside of their
trampoline payload, relying on nodes in the blinded path to pass the
blinding point along.

When performing a trampoline forward we do not have a blinded tail,
because we've been given the next node's ID and have performed regular
pathfinding, so the final amount sits in the last hop's fee_msat and
there is no final value to set here. This is different to when we're
the original sender to a trampoline, because we have a blinded tail in
that case so only the fee is contained in the final hop.

ln/refactor: rename TrampolineEntry to SendToTrampoline

We construct our path differently for trampoline sends and forwards,
so we explicitly split this out.

ln/refactor: remove BlindedTrampolineEntrypoint

ln/refactor: rename DirectEntry to Blinded

ln/refactor: rename BlindedTailDetails to TailDetails

ln/refactor: remove unnecessary iterator trait param

Co-authored-by: Valentine Wallace <vwallace@protonmail.com>

ln/refactor: rename trampoline relaying path key to outer_onion_path_key

When dealing with blinded trampoline, we receive our relaying path key
from the outer onion (not the update_add_htlc).

ln/refactor: rename intro_node_blinding_point to outer_onion_path_key

The meaning of this key depends on the context it appears in:
- No trampoline onion: it is the introduction node's path key
- Trampoline onion: it is a blinded relaying trampoline

ln: disallow trampoline payloads inside of blinded paths

Co-authored-by: Valentine Wallace <vwallace@protonmail.com>

fuzz: allow empty-channel force close with in-flight payments

The chanmon harness can now force-close a target channel as long
as that channel itself has no pending HTLCs, even when another
channel still carries an in-flight payment. When an explicit close
succeeds, mark pending payments that routed over the closed channel
as allowed to fail.

This is the narrowest extension beyond globally HTLC-free closes. It
covers a payment that crossed one hop before its next, still-empty
channel is closed, without yet modeling force closes of channels that
themselves contain HTLCs. Route-aware failure tracking limits the
allowance to affected payments.

fuzz: require expected payment failures

Start pending payments at MustSucceed and require every tracked
PaymentFailed to follow an observed failure source. Cover receiver
rejection, corruption, local send failure, local inbound forwarding
failures, and the receive-side CLTV buffer.

Local inbound failures are classified when forwarding leaves an
inbound HTLC waiting for its removal revoke, before the failure can
reach the payer. For relayed failures, use
OutboundHTLCDetails::source to retain exact inbound channel and HTLC
IDs with the payment hash. This prevents same-hash MPP parts from
being mistaken for a local failure root.

fuzz: centralize payment send tracking

Rename the send-state query and local variables to describe whether LDK
still has pending work. Route the existing pending-payment registration
through one helper without changing which sends are tracked.

Later payment invariants must apply consistently to direct, forwarded,
and MPP sends. Centralizing this lifecycle decision keeps tracking
changes from diverging between send helpers.

fuzz: retain channel ids in payment paths

Keep each hop ChannelId beside its SCID and retain the complete set
of paths while a payment is pending. This is mechanical preparation;
the new fields are intentionally not interpreted yet.

SCIDs remain the route-building input, while explicit closes identify
channels by ChannelId. Carrying both representations in one path model
lets a later force-close allowance match affected payments without
reconstructing routes or maintaining parallel bookkeeping.

fuzz: derive routes from payment paths

Build direct, forwarded, and MPP routes from a shared per-path hop
description. Derive route fees and node metadata from that description,
and increase the CLTV delta by 100 for each successive hop.

Later failure tracking needs to describe the exact route that was sent.
Keeping route construction and bookkeeping on one representation
prevents them from drifting and prepares the tracker to retain more
per-hop failure context.

fuzz: prepare payment failure tracking

Carry each send's minimum final CLTV expiry into payment
registration. Thread PaymentTracker through HTLC message delivery and
separate PaymentFailed from ProbeFailed dispatch.

A later invariant commit uses this context to classify failure roots.
Keeping the plumbing separate reduces its behavioral review even though
the minimum expiry remains temporarily unread.

fuzz: track payment send resolutions

Register every send as pending, then move immediate outcomes through
one strict pending-to-resolved transition. Reuse that transition for
terminal events and manager rollback, while handling repeated terminal
events only after confirming the payment was already resolved.

Keep abandoned payments pending while they still have outbound HTLC
state, including holding-cell HTLCs. Later success checks need complete
tracker state and must reject terminal events for payments the harness
never recorded.

blinded_path: only compact introduction nodes via channels enabled both ways

When selecting a channel to reference a compact (DirectedShortChannelId)
introduction node, only consider channels that are enabled in both
directions. Disabled channels cannot be used to reach the introduction
node, and such channels may linger in the local network graph long after
being disabled or even closed (e.g., when sourcing gossip from rapid
gossip sync, which never removes closed channels). Previously, the
oldest channel of the introduction node was selected unconditionally,
which could produce blinded paths that senders cannot resolve or route
to, silently breaking long-lived paths such as those embedded in BOLT 12
offers.

If no enabled channel is found, the NodeId encoding is kept.

Fixes #4826.

Require manual reviewer assignment

Stop assigning reviewers when pull requests are opened. Keep the manual
workflow trigger available for Forgejo's "Assign random reviewer"
button. Only members of the reviewer pool may request an additional
reviewer.

Document that contributors should address the initial AI review before
requesting human review. Clarify that one human reviewer is the default,
with a second requested when the primary reviewer considers it
necessary.

Expose DNS query failure on invalid proofs or bad BIP 353 records

In the previous commit we started handling the new `DNSSECError`
onion messages and using them to expose when a BIP 353 resolution
over onion messages should be considered failed due to all of our
queries having filed. However, queries can also fail if all of our
queries either errored or returned bogus proofs, or if we received
a valid proof which proved there is no BIP 353 record or `Offer`.

Here we consider such failures and expose them as well.

Generate `DNSSECError` messages when DNSSEC resolution fails

https://github.com/lightning/blips/pull/71 updated the DNSSEC
resolution bLIP to include an explicit error message when DNS(SEC)
resolution was attempted but failed, allowing for faster fallback
to LN-Address (for clients that do) and faster payment failure.

Here we add service-side support for generating the error messages,
informing requesters that their resolutions have failed.

Largely written by an LLM

Correct DNSSEC proof validity time gap applied to header time

We intended to apply DNSSEC proof validity tests to constrain them
to within two hours of the latest block header time, but the code
landed with a two minute gap instead.

Given DNSSEC proof validity is usually many hours and grace periods
are used to ensure records close to expiry aren't used, this is
somewhat unlikely to have bitten anyone.

Rename `OMNameResolver::resolve_name` to `initiate_resolution`

This better captures what the method actually does.

f note that only one resolution will fail at a time