rust-lightning

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>

Filter stale closed hop sends in chanmon fuzz

Hop sends can route over an open SCID while LDK's non-strict
forwarding still selects a parallel channel that the harness has
already tracked closed but a node still lists. Skip those API sends
until the stale listing clears, while keeping the existing open-id
checks for fully dropped closed channels.

Tolerate stale STFU warnings in chanmon fuzz

When stale message events are delivered after a channel close, the
recipient can respond with the expected STFU warning instead of the
control error path. Treat that warning as expected for channels the
harness already tracks closed, while documenting that stale events
should still be delivered so handlers exercise their normal error paths.

ln: persist the paid BOLT 12 invoice and build payer proofs

Carry the paid `Bolt12Invoice` through the outbound payment so it survives
restarts, and surface it as a `PaidBolt12Invoice` on `Event::PaymentSent` so the
payer can build a payer proof. The payer signing key is re-derived from the
invoice's own payer metadata, so no extra key material is stored.

`PaidBolt12Invoice` now lives in `offers::payer_proof`; existing async payment
tests and a test helper are updated to construct it via the new API. Adds an
end-to-end test that pays a BOLT 12 offer and builds + verifies a payer proof
from the resulting `Event::PaymentSent`.

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

fuzz: add a payer proof deserialization target

Throw arbitrary bytes at `PayerProof::try_from` to exercise the merkle-root
reconstruction and the deserialization path together.

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

refactor(offers): extract payer key derivation helpers

Move the invoice/refund payer key derivation logic into reusable helpers so
payer proofs can derive the same signing keys without duplicating the metadata
and signer flow.

offers: add merkle selective-disclosure primitives

Extend the BOLT 12 merkle module with selective-disclosure support: build
the full merkle tree from a TLV stream, compute the omitted-TLV markers and
the minimal set of missing hashes for omitted subtrees, and reconstruct the
merkle root from a partial disclosure. These are the primitives a payer proof
is built on.

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

Co-Authored-By: OpenAI Codex <codex@openai.com>

offers: add BOLT 12 payer proof primitives

Add the `payer_proof` module: `PayerProof`/`UnsignedPayerProof`, the
`PayerProofBuilder` (with selective disclosure and a derived-key path), bech32
`lnp` encoding, and parse-time verification, implementing the payer proof
extension to BOLT 12 (https://github.com/lightning/bolts/pull/1295). Also
exposes the offer/invoice TLV-type constants and an invoice-bytes accessor used
to build proofs, and a `Sha256` `Writeable`/`Readable` impl for the proof hashes.

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

Co-Authored-By: OpenAI Codex <codex@openai.com>

Upload new fuzz corpus entries as a short-lived CI artifact

Fork-PR runs get no credentials from Forgejo — neither secrets nor
authorized-integration identity tokens — so the fuzz job cannot push
new corpus entries to the corpus repo from CI. Instead, clone the
corpus from this Forgejo instance (rather than the GitHub copy, so
new entries are detected against the repo they will land in), stage
the new entries plus any SIG* crashes like the GitHub workflow does,
and upload them as an `hfuzz-corpus` artifact with a two-day
retention. The ldk-fuzzing-corpus repo's nightly job sweeps these
artifacts into a corpus pull request and deletes them once processed.

Unlike the GitHub workflow's version, the crash-staging loop here uses
the `rust-lightning/<target>` prefix the corpus entries are actually
staged under (upstream checks the wrong path, so no crash file is ever
picked up there), and it stages crashes for targets that produced no
new corpus entries rather than only creating the target directory as a
side effect of staging corpus files.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Add upgrade test for legacy post-close monitor update persistence

Fix assign-reviewer's auth by setting the authorized integration audience

ci: don't double-assign reviewers, support manual assignment runs

The assign-reviewer workflow blindly picked a random reviewer every
time it ran, so a re-run (or any future non-opened trigger) could
request review from a second person even when someone was already on
the PR. Teach it to inspect the PR state first:

* Anyone already requested as a reviewer or who has submitted a
review is never picked. The author self-reviewing (commenting on
their own PR) doesn't count.
* On automatic runs (including re-runs), skip assignment entirely if
anyone from the REVIEWERS pool has already reviewed or been
requested; reviews from people outside the pool are ignored.

Also add a workflow_dispatch trigger taking a PR number so a reviewer
can be assigned manually. Manual runs skip the "someone is already on
it" check and always add a new (not-yet-involved) reviewer if an
eligible candidate remains.

This should let us fully emulate the old bot's second-reviewer
assignment logic fully via the action. A first reviewer can go hunt in
the actions page and trigger a second assignment (but we'll add a UI
element in the PR page above merge to trigger this in a nice UI).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

fuzz: factor chanmon broadcast relay helper

Extract the all-node broadcaster drain into a helper and use it
from the finish-time mempool cleanup loop. This leaves relay behavior
unchanged while giving cleanup paths a shared relay primitive.

fuzz: settle chanmon force-closes on chain

Route BumpTransaction events through the wallet-backed handler and
drain raw ChainMonitor events during normal event processing. This
matches the background processor path and lets anchor commitments and
claim transactions enter the harness mempool from fuzz opcodes as well
as final cleanup.

During settle_all, alternate event processing, relay, and mining until
tracked force-closed channels no longer report claimable balances. The
bounded loop catches stuck on-chain cleanup instead of leaving
broadcasts or claims unresolved.

fuzz: sync reloaded monitors from their own best block

A node's channel monitors can be persisted at different heights, so on
reload they are not all at the same chain tip. Driving them to the tip
through the shared ChainMonitor from the oldest monitor's height replays
blocks that monitors already ahead have seen, which they interpret as a
reorg. That reorg discards force-close claims registered at a later
height, leaving the closed channel with no transaction to broadcast.

Sync each monitor to the tip from its own best block instead, and sync
the manager separately, matching LDK's per-listener startup contract.