rust-lightning

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>

Queue a splice on a channel with an inherited splice until it locks

A pending splice negotiated before an upgrade from a prior LDK version
(e.g. 0.2) comes back without its feerate or our contribution: 0.2
persists neither and drops the odd TLVs that carry them. Without them the
inherited splice cannot be RBF'd.

Rather than refuse to splice the channel, leave the RBF feerate floor unset
so the new splice is queued and begins as a fresh splice once the inherited
splice locks -- the same path taken whenever a contribution cannot replace
the pending candidate via RBF, such as on a zero-conf channel.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Compute the minimum splice RBF feerate via PendingFunding

splice_channel derived the pending splice's minimum RBF feerate by mapping
a standalone helper over the prior round's feerate, shadowing the helper's
name with the resulting local. Encapsulate the derivation as
PendingFunding::min_rbf_feerate, mirroring the FundingTemplate accessor it
feeds, and keep the formula as an associated function for the call sites
that derive the prior feerate differently.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Add pending changelog entry for PR 4687

Expose pending splice details in ChannelDetails

A channel may have splice attempts in progress: a contribution we have
committed but not yet begun negotiating, one under negotiation with the
counterparty, and any negotiated transactions (the original splice and
any RBF replacements) waiting on confirmations. This state was only
observable through events and the broadcaster's
TransactionType::InteractiveFunding, neither of which can be queried on
demand.

Add an optional splice_details field to ChannelDetails. Every splice or
RBF round on the channel that has not yet locked is reported as a
candidate, each carrying our contribution to it (if any) and a status
giving the stage it has reached, from a contribution awaiting quiescence,
through negotiation, to a signed transaction awaiting confirmations. This
also reports the single candidate that has confirmed, with its
confirmation progress and whether we have sent splice_locked for it, and
the txid of any splice_locked received from the counterparty.

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

Remove redundant witness program check

With rust-bitcoin `0.32.4` release, verifying a script is a witness
program delegates to `Script::witness_version`, This makes adding
`Script::is_witness_program` check alongside a witness_version check
redundant.

Add amounts to HTLC locators

Include per-HTLC amounts in `PaymentForwarded` locators so callers can
account for each channel independently when a forward uses multiple
incoming or outgoing HTLCs.

AI-assisted-by: OpenAI Codex

Correct CHANGELOG dates on 0.2.1 and 0.2.2

Panic on unexpected chanmon monitor events

Monitor event draining expects BumpTransaction events, which the
harness must mine, plus SpendableOutputs and DiscardFunding events,
which it intentionally ignores because it does not model an external
wallet. Make that whitelist explicit by panicking on any other monitor
event instead of silently ignoring it.

Store splice contributions with their negotiated candidates

PendingFunding tracked our splice contributions in a compact list
implicitly aligned to the tail of the negotiated candidates, with the
in-flight negotiation round's contribution as the implicit last entry.
Every consumer had to re-derive this positional relationship, which is
easy to get wrong -- e.g., attributing an in-flight round's
contribution to a completed counterparty-only candidate.

Instead, store each candidate's contribution with the candidate itself
and give the in-flight round's contribution its own field, making such
misattribution unrepresentable. The contributions still form a suffix
of the candidates -- once a round includes our contribution, every
subsequent round carries it forward (possibly feerate-adjusted) so the
splice intention is never lost -- which is now asserted when a round
completes.

Serialize this so a single (non-RBF) pending splice stays loadable by
LDK 0.2 while RBF is refused loudly. 0.2 predates per-candidate
contributions, the in-flight contribution, and the last-negotiated
feerate, so writing any of them in an even (required) TLV would make 0.2
refuse even a single splice it can otherwise operate. The legacy TLV 3
therefore carries only the first candidate's funding -- the single-splice
view 0.2 reads -- while the full candidate list, the in-flight
contribution, and the feerate go in odd TLVs that 0.2 skips. An even gate
TLV is written only when there is more than one negotiation round (RBF),
so 0.2 loads single splices and refuses RBF, which it cannot operate.

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

Require `htlc_value_satoshis` in [pending] `HTLCUpdate`s

In 0.0.100 we started tracking the amounts being claimed in
`OnchainEvent::HTLCUpdate` and then also in
`MonitorEvent::HTLCUpdate`'s `HTLCUpdate`. It was always set, but
stored as an `Option` to support further downgrade. Because these
objects time out after `ANTI_REORG_DELAY` (6) blocks, there's not
really much reason to keep supporting backwards compatibility to
upgrade with such objects without an amount.

In 0.0.115, we started providing the amount in `PaymentForwarded`.
For whatever reason, despite the event only being generated in
cases where we had amounts, the field was added as an `Option`.

Still, in 0.0.118 we started generating them from both off-chain
and on-chain claims. For off-chain claims it was always set, but
for claims which originated from on-chain claims, the amounts came
from the `MonitorEvent::HTLCUpdate` and thus were always an
`Option`. If we no longer care about `MonitorEvent::HTLCUpdate`'s
without a claim amount, we no longer need to worry about
`Event::PaymentForwarded` either. Thus, we make it required here
as well.

Use a builder for sign_interactive_funding_tx arguments

The signing helper had accumulated several boolean/option parameters beyond
the two nodes, so call sites passed opaque positional `false`s and bare
`None`s whose meaning was unclear without consulting the signature.

Replace the two overloaded functions with a single `sign_interactive_funding_tx`
taking a `SignInteractiveFundingTxArgs` builder, mirroring `PassAlongPathArgs`:
`new(initiator, acceptor)` defaults to a first-attempt splice on a confirmed
channel with no acceptor contribution, and each non-default behavior is opted
into by a named method (`zero_conf`, `with_acceptor_contribution`, `replacing`).

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