rust-lightning

Avoid initial commitment channel_ready retransmission while splicing

If nodes have started a splice, this means they have both sent and
received `channel_ready` already: in that case, it's unnecessary to
retransmit `channel_ready` on reconnection.

Wait for inbound commitment_signed before producing tx_signatures

We only want to produce `tx_signatures` once we know that the monitor
update (either the initial one for a dual-funded channel, or a
`RenegotiatedFunding` one for a splice) has been persisted. If we
haven't received the counterparty's `commitment_signed` yet, then the
monitor update hasn't been created, leading us to pass the
`!awaiting_monitor_update` condition and produce a holder
`tx_signatures` message.

Return early on duplicate calls to `funding_transaction_signed`

We may produce duplicate `FundingTransactionReadyForSigning` events if
the user has processed an initial event but has not yet called back with
`funding_transaction_signed` and a peer reconnection occurs. If the user
also handles the duplicate events, any duplicate calls to
`funding_transaction_signed` after an initial successful one would
return an error. This doesn't make sense, as the API should remain
idempotent, so we return early on any duplicate calls.

Only claim HTLCs with matching payment hash upon preimage monitor update

Previously, we'd attempt to claim all HTLCs that have expired or that we
have the preimage for on each preimage monitor update. This happened due
to reusing the code path (`get_counterparty_output_claim_info`) used
when producing all claims for a newly confirmed counterparty commitment.
Unfortunately, this can result in invalid claim transactions and
ultimately in loss of funds (if the HTLC expires and the counterparty
claims it via the timeout), as it didn't consider that some of those
HTLCs may have already been claimed by a separate transaction.

This commit changes the behavior when handling preimage monitor updates
only. We will now only attempt to claim HTLCs for the specific preimage
that we learned via the monitor update. This is safe to do, as even if a
preimage HTLC claim transaction is reorged out, the `OnchainTxHandler`
is responsible for continuous claiming attempts until we see a reorg of
the corresponding commitment transaction.

Rustfmt get_counterparty_output_claim_info

We plan to rework this method in the following commit, so we start by
formatting it first.

Correctly handle new `ChannelMonitorUpdate`s to old post-FC chans

In 0.1 (1481216793169ae83c87ae26fddda8a1971e35f9) we started
setting `ChannelMonitorUpdate::update_id` to a non-`u64::MAX` value
for updates generated after a channel has been closed.

This is great, but in 71a364c13345396fd75b22877e03b6a7b1d2bca1 we
then started calculating the next `update_id` by incrementing the
last `update_id` we saw when we started and were looking at the
`ChannelMonitor`. However, the last-applied `update_id` may well be
`u64::MAX` for old `ChannelMonitor`s which were closed prior to
0.1. In that case the increment would overflow.

Here we fix this naively by simply replacing the increment with a
`saturating_add`. While its possible this will result in a
`ChannelMonitorUpdate` being tracked as in-flight (only for the
`ReleasePaymentComplete` updates added in 71a364c13345396fd75b2287)
at the same `update_id` as other updates already in-flight and
handling post-`ChannelMonitorUpdate` actions too early, this should
only apply to releasing payment complete updates, which have no
post-`ChannelMonitorUpdate` action.

Its also possible that this leads to a regression in the future,
where we have some new post-closure update that does have a
post-`ChannelMonitorUpdate` action and we run it too early, but by
then presumably its fairly rare to have a `ChannelMonitor` for a
channel closed pre-0.1 that still needs multiple updates.

Correctly track reloaded update_id in `chanmon_consistency` fuzzer

In the `chanmon_consistency` fuzzer, when reloading a node, we
take a pending monitor update (or the latest persisted one) and put
it in `persisted_monitor` as it is implicitly the latest persisted
monitor on restart. However, we failed to update
`persisted_monitor_id`. As a result, we may restart and write the
loaded monitor to `persisted_monitor` (eg at ID 2) but have a
later `persisted_monitor_id` (eg ID 3). Then, when we complete
the monitor update for the `persisted_monitor_id` (here, 3) we will
think that its not a new update and neglect to update
`persisted_monitor`/`persisted_monitor_id`. As a result, later
updates (e.g. ID 4) will fail as we're trying to apply them to the
original persisted monitor (at ID 2).

The fix is simply to ensure `persisted_monitor_id` is always
updated in lock-step with `persisted_monitor` on reload.

Correct EOF handling in stream read in `ChaChaDualPolyReadAdapter`

When `ChaChaDualPolyReadAdapter` encounters an EOF (`Read::read`
returns `Ok(0)`) while trying to drain the stream (even though the
`FixedLengthReader` thinks it has available space) we'll end up
infinite-looping trying to drain the stream looking for
`Read::read` to return an `Err` (which it won't).

The fix is, of course, simple, to detect the EOF signal.

Found by the `onion_message_target` fuzzer which @dergoegge ran.
Thanks to @morehouse for digging deeper on the specific fuzz test
case and thoroughly reporting the underlying causes.

Fixes #4139.

Trivially replace `wake_by_ref` with `wake`.

`Waker::wake_by_ref` is allowed to be less efficient than
`Waker::wake` and given we have ownership we might as well use the
more efficient one.

Rustfmt handle_new_monitor_update

We'll be breaking up this macro in upcoming commits.

Wipe splice state upon failed interactive funding construction

An interactive funding construction can be considered failed upon a
disconnect or a `tx_abort` message. So far, we've consumed the
`InteractiveTxConstructor` in the latter case, but not the former.
Additionally, we may have splice-specific state that needs to be
consumed as well to allow us to negotiate another splice later on.

This commit ensures that we properly consume all splice and interactive
funding state whenever possible upon a disconnect or `tx_abort`.

The interactive funding state is safe to consume as long as we have
either yet to reach `AwaitingSignatures`, or we have but `tx_signatures`
has not been sent/received. In all of these cases, we also make sure to
clear the quiescent state flag such that we're able to resume processing
updates on the channel.

The splice state is safe to consume as long as we don't have a pending
`FundingNegotiation::AwaitingSignatures` with a `tx_signatures`
sent/received and we don't have any negotiated candidates. Note that
until splice RBF is supported, it is not currently possible to have any
negotiated candidates with a pending interactive funding transaction.

Consume InteractiveTxConstructor after error checks

InteractiveTxConstructor contains the users contributed inputs. When an
interactive tx sessions is aborted, the user will need to be notified
with an event indicating which inputs and outputs were contributed. This
allows them to re-use inputs that are no longer in use. This commit
ensures the InteractiveTxConstructor is only consumed after all error
checking. That way, in the case of a failure, we're able to produce an
event from its input data.

Use u16 for ConstructedTransaction::shared_input_index

The number of inputs allowed during an interactive-tx construction
session is limited to 4096, so a u16 can be used instead of u32 when
serializing ConstructedTransaction.

Store shared output index in ConstructedTransaction

Currently, only the shared input index is stored in
ConstructedTransaction. This will be used later to filter out the shared
input when constructing an error during interactive tx negotiation.
Store the shared output index as well so that the shared output can be
filtered out as well.

Keep InteractiveTxConstructor contributed inputs and outputs

Instead of popping each input and output to contribute during an
interactive tx session, clone the necessary parts and keep around the
original inputs and outputs. This will let us reuse them later when
constructing an error. The tradeoff is using additional memory to avoid
more code complexity required to extract the sent input and outputs from
NegotiationContext.

Make `util::async_poll` public

We have several interfaces that rely on types from `async_poll`, so
it clearly needs to be public.

Make background-processor `NO_*` constants actually `Send` + `Sync`

In 0d59d73c55f873e9d78703763ae97de47c186bd8 we added constants to
better enable users to call background processor methods without
optional parameters. Sadly, they didn't work for the async BP as
they weren't actually `Send` + `Sync`, which we fix here.

Give the `get_change_destination_script` future access to `self`

Its generally useful for trait methods to be able to access `self`,
sadly our definition of `get_change_destination_script` was screwed
up and couldn't. Luckily its an easy fix as none of the callsites
care about the extra `self` lifetime.

Drop `OutputSweeper` non-`BestBlock` `Readable` implementation

`OutputSweeper`, like any `Confirm`/`Listen` client, needs to have
the chain synced back up on startup. Thus, like `ChannelMonitor`
and `ChannelManager`, we force users to `read` it via a method that
gives them the latest chain tip so that they can sync.

Add missing `Listen`/`Readable`/methods for `OutputSweeperSync`

It appears we just forgot to add these when we added the sync
wrapper.

rustfmt: Remove skip from request_refund_payment

Refactor: Introduce `get_payment_info` closure for invoice creation

To ensure correct Bolt12 payment flow behavior, the `amount_msats`
used for generating the `payment_hash`, `payment_secret`,
and payment path must remain consistent. Previously, these steps
could inadvertently diverge due to separate sources of `amount_msats`.

This commit refactors the interface to use a `get_payment_info` closure,
which captures the required variables and provides a single source of
truth for both payment info (payment_hash, payment_secret) and path
generation. This ensures consistency and eliminates subtle bugs
that could arise from mismatched amounts across the flow.

Introduce specific InvoiceBuilders in OffersMessageFlow

This change improves type safety and architectural clarity
by introducing dedicated `InvoiceBuilder` methods tied to
each variant of `VerifiedInvoiceRequestEnum`.

With this change, users are now required to match on the
enum variant before calling the corresponding builder method.
This pushes the responsibility of selecting the correct
builder to the user and ensures that invalid builder
usage is caught at compile time, rather than relying
on runtime checks.

The signing logic has also been moved from the builder
to the `ChannelManager`. This shift simplifies the
builder's role and aligns it with the rest of the API,
where builder methods return a configurable object that
can be extended before signing. The result is a more
consistent and predictable interface that separates
concerns cleanly and makes future maintenance easier.

Introduce VerifiedInvoiceRequest<S: SigningPubkeyStrategy>

This commit reintroduces `VerifiedInvoiceRequest`, now parameterized by
`SigningPubkeyStrategy`.

The key motivation is to restrict which functions can be called on a
`VerifiedInvoiceRequest` based on its strategy type. This enables
compile-time guarantees — ensuring that an incorrect `InvoiceBuilder`
cannot be constructed for a given request, and misuses are caught early.

Refactor: Convert fields function to macro

In the following commits we will introduce `fields` function
for other types as well, so to keep code DRY we convert the
function to a macro.