rust-lightning

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.

f names in test lookups

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.

f note that only one resolution will fail at a time

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.

Report the used success probabilities in scorer accessor methods

`live_estimated_payment_success_probability` and
`historical_estimated_payment_success_probability` allow clients to
fetch the estimated success probability of a channel directly,
rather than as a score.

Sadly, because they did not check that the amount was strictly
smaller than `max_liquidity_msat`, `success_probability` could hit
a (otherwise-harmless) debug assertion, which is fixed here.

While doing so, we also update them to return the actual
probability estimate used in scoring, applying the 1% lower-bound.

Format changed functions

Correct + update scoring attempts right at the maximum amounts

While sending a payment at exactly a channel's max or the liquidity
upper bound we've calculated is unlikely to work, we shouldn't
consider it impossible. Here we fix a few cases where we previously
did so.

This isn't really fixing anything, as we only shift the boundary by
1 msat, but it makes the next commit more logical.

Handle missing splice tx_signatures on reestablish

When reconnecting after one side has received `tx_signatures` for a
splice but the peer has not, `channel_reestablish` may need to recover
two different pieces of state: the missing `tx_signatures` and a later
commitment update generated after quiescence ended locally.

Previously the lost-remote-commitment path discarded any `tx_signatures`
prepared while processing the peer's `next_funding` TLV, as we assumed
that if a `tx_signatures` is owed, then no pending updates must exist.
That left the peer awaiting splice signatures and still treating the
channel as quiescent, so the subsequent HTLC commitment update was
rejected as a normal update while quiescent.

This was incorrect as the fuzzer highlighted that a new update can be
made after the `tx_signatures` exchange (while the counterparty has yet
to process the responding `tx_signatures`) and both messages need to be
retransmistted after a reconnect.

We fix this by carrying `tx_signatures` through that reestablish branch
and making the `tx_signatures/commitment_update` order explicit. Initial
splice funding retransmission remains
commitment_signed-before-tx_signatures, while post-splice reconnect
recovery sends tx_signatures before normal commitment updates so the
peer can exit quiescence first.

offers: Allow disabling invoice response MPP

Preserve the MPP-enabled default for invoice-request response builders
so existing OffersMessageFlow callers retain their prior behavior.

Allow callers with single-path requirements to explicitly remove the
advertised MPP feature before signing. This controls feature
advertisement only; receive-side enforcement remains the caller's
responsibility.

Co-Authored-By: HAL 9000

channelmanager: upgrade best_block_updated log from trace to info

Change assign-reviewer authorized integration token to a bot acct

I didn't realize using my own authorized integration token would
result in every assignment being listed as coming from me, which is
weird so here we swap it for a bot.

Fixes #4804

Increase probabilistic scorer defaults 5x

Increase the base and historical-liquidity penalties fivefold. This
applies to both the fixed and payment-size parts, so their balance stays
the same. The router will now pay more to avoid longer routes and routes
the scorer considers less likely to work.

I tested this using the graph and scorer pulled from my ldk-server. The
scorer was kept unchanged during the test. Codex randomly assigned 600
different high-degree nodes to the old or new settings, with 300 probes
per setting. The test was balanced across 100 rounds and used amounts of
1,000, 10,000, and 30,000 sats. Only one probe ran at a time.

The old settings reached 167/300 targets (55.7%) within 10 seconds. The
5x settings reached 214/300 (71.3%), an improvement of 15.7 percentage
points. Results were 69% vs 82% at 1,000 sats, 47% vs 72% at 10,000
sats, and 51% vs 60% at 30,000 sats.

Across the 587 targets where both settings found a route, the quoted fee
rose by 2.4 sats on average. These probes used one node and did not
settle, so they do not guarantee payment success elsewhere.

Expose sources for pending outbound HTLCs

Pending outbound HTLC details do not identify which payment or
inbound HTLC produced them. A payment hash cannot provide that
mapping when multiple parts of a multipart payment share both a hash
and route.

Expose an optional source enum containing the payment ID for locally
initiated HTLCs, the inbound HTLC for normal forwards, or all inbound
HTLCs aggregated by a trampoline forward. Derive it from the existing
HTLC source for committed and holding-cell HTLCs.

Serialize the source as an optional upgradable TLV so older data
remains readable and unknown future source variants degrade to None.

Handle `DNSSECError` messages when attempting DNSSEC resolution

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 client-side support for the new message, accepting
`DNSSECError` messages and marking payments as failed when all our
queries have failed.

Largely writen by an LLM

Add infrastructure for handling `DNSSECError` onion messages

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 simply add the new message framing and empty handlers.

Largely writen by an LLM

Remove taproot build check

Increase no-channel peer limit

Pin jobserver to 0.1.34 on pre-1.85 rustc

Bump esplora-client to 0.13 to switch from `reqwest` to `bitreq`

...fixing MSRV builds

Test cross-version serialization of pending splices

Add tests exercising the 0.2/current wire boundary for pending splices:
- A current node with a single pending splice (whether or not we
contributed to it) is loadable by LDK 0.2.
- A current node with a splice under RBF is refused by 0.2 via the even
RBF-gate TLV.
- A single pending splice written by 0.2 is read by current with no
contribution recorded, since 0.2 never tracked one.

The downgrade reload configs enable anchors so 0.2 accepts the current
channel type rather than refusing it before the splice state is reached.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>