rust-lightning

Don't validate a splice if updates are pending

`FundedChannel::get_next_splice_out_maximum` is called in
`FundedChannel::splice_channel`, which can be called when updates are
pending in the channel.

If this is the case, `FundedChannel::get_next_splice_out_maximum` may
report a value that is not yet valid on both commitments, and thus fails
`FundedChannel::validate_splice_contributions`. That value will
nonetheless be valid on both commitments once the updates are cleared
from the channel, and splice negotiation actually begins.

So, we now validate `FundedChannel::get_next_splice_out_maximum` with
`FundedChannel::validate_splice_contributions` only if there are no
pending updates in the channel.

Joost and Wilmer's fuzzing runs caught this discrepancy.

Allow stdin fuzz targets to suppress logs

Add an environment-variable switch that lets stdin fuzz targets use the
dev-null test logger. This keeps direct invocations verbose by default,
while external runners can opt into quieter passing-case replays.

Fix fuzz build warnings

Restore splice fuzzing by default

This removes the temporary cfg flag that was added while the splice
fuzzer was broken. We also include coverage for the newly supported
async signing of a splice's shared input.

Manually exit quiescence in fuzzing upon disconnect

In certain cases, we may need to terminate quiescence as a result of
some error via a `ChannelError::WarnAndDisconnect`. We don't need to
necessarily reconnect the peers, so we choose to manually terminate
quiescence via the existing `ChannelManager::exit_quiescence` test
helper.

Encrypt `payment_metadata` when we build the payment secret

In 657ac8f58e51af74c610375cb65cdad6f7a18c6b we started committing
to the `payment_metadata` in the `payment_secret`. We'd largely
assumed that downstream code could simply encrypt the
`payment_metadata` itself before passing it to `lightning` and
decrypt before reading it from `lightning`. However, this presents
a challenge - we'd very much love for that downstream code to avoid
adding any extra bytes to its `payment_metadata` if at all
possible, but it doesn't have a great way to get a decent IV
without simply shoving it in the encrypted `payment_metadata`.

Instead, here, we encrypt and decrypt the `payment_metadata`
internally in `lightning`. This allows us to reuse the IV that is
used for `lightning`-generated `payment_hash`es as the IV for the
encrypted `payment_metadata` as well. Sadly, we don't have any
similar IV for user-provided `payment_hash`es. In that case, we
simply accept the limitations and document that users must avoid
encrypting multiple `payment_metadata`s for payments with the same
`payment_hash`. This avoids padding the size of the
`payment_metadata` and should generally not be a material concern -
`payment_hash` reuse should generally not exist anyway, and if it
does it should only be in cases where its "the same payment" being
retried after failure, at which point `payment_metadata` should
hopefully be the same.

Unify and simplify the application of simple chacha20 passes

Most of our `chacha20` calls don't actually care about the concept
of ChaCha20's "seek" vs "nonce" - we just want to use the full
128 bits of nonce space as nonce. Here we unify those calls to
keep a consistent API and consolidate the `unwrap`s to one place.

Track chanmon payment persistence generations

Stamp pending payments with the first manager generation.

On deferred reload, drop payments born after the loaded snapshot.

This keeps tracker state aligned with explicit persistence.

Refactor chanmon payment tracker helpers

Move node-local payment tracking mutations onto NodePayments.

Pending and resolved payment state are updated the same way.

The owner of that state now owns the helper methods.

Skip ChannelManager persistence for message-only monitor completions

When process_pending_monitor_events processes only Completed events
and the resulting work is limited to message-only monitor
completion handling, ChannelManager persistence can be skipped.

Completion handling now reports whether it actually mutated
ChannelManager state, and process_pending_monitor_events uses
that to decide between SkipPersistHandleEvents and DoPersist.

Return NotifyOption from process_pending_monitor_events

Refactor process_pending_monitor_events to return a NotifyOption
instead of a bool, allowing callers to distinguish between
DoPersist, SkipPersistHandleEvents, and SkipPersistNoEvents.

Both call sites in process_events_body and
get_and_clear_pending_msg_events are updated accordingly.

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

Gate interactive commitment_signed on user approval during reestablish

Interactive funding transactions must be approved by the user via
`ChannelManager::funding_transaction_signed` prior to exchanging
signatures for it. This ensures the user is able to cancel up until the
very last point throughout the handshake. When this was done in 83b2d3e,
we forgot the cover the reestablish cases, which we do here.

Validate reserved fees on both commitments

The local and remote commitments may have different dust limits, which
can cause each commitment to have a different transaction fee.

Therefore when we reserve commitment transaction fees in
`get_available_balances`, we must ensure that we read the maximum of the
transaction fees on the local and the remote commitments. Otherwise, we
may have not reserved enough fees to ensure that our next proposed
channel state update is onside.

Break `get_available_balances` into small helper functions

Most diffs here are code moves.

Validate `next_splice_out_maximum_sat` on both commitments

Wilmer's fuzzing runs caught a case where an advertised splice out
maximum hit the debug assertions in `get_next_splice_out_maximum`.
These debug assertions ensure that any adverstised splice out maximum
passes the validation of splice contributions.

The core issue is that we only read the local commitment when
calculating the splice out maximum, but our splice validation requires
that any splice out maximum is covered by the minimum of the holder's
balances on the local and the remote commitments.

Therefore, if a HTLC is dust on the local commitment, but non-dust on
the remote commitment, and the holder is the funder of the channel, we
advertise a splice out maximum that is not covered by the holder's
balance on the remote commitment, and fails our validation of splice
contributions.

We now read both commitments when calculating the next splice out
maximum, which fixes this issue.

Enforce that node_ids are sorted in channel_announcements

We already enforced that nodes can't have a chanel with themselves,
but the spec was updated to require strict ordering at
https://github.com/lightning/bolts/pull/1333 so we enforce this as
well.

Test fixes by claude.

Add explicit chanmon manager persistence commands

Add chanmon_consistency commands to persist each node's
ChannelManager state explicitly. This lets the fuzz target exercise
delayed manager persistence instead of checkpointing it after every
command.

Handle inferred splice_locked on reestablish first prior to updates

Upon channel reestablishment, we free our holding cells to send any
pending updates to our peer. If we happened to implicitly lock a pending
splice during reestablishment, we want to make sure any updates we send
after the fact are considering the new channel state (post-splice), even
if the update was queued while the splice was still pending. Therefore,
we must always handle the inferred `splice_locked` first.

Found by the `chanmon_consistency` fuzz target.

Send missing splice_locked when confirmation precedes reestablishment

In most cases, we end up sending our `splice_locked` either implicitly
during reestablishment via
`ChannelReestablish::my_current_funding_locked`, or explicitly after
reestablishment. However, we did not consider that it's possible for the
node to be notified of the splice confirmation after connecting to their
peer but prior to reestablishing their channel. In such cases, we need
to explicitly send the `splice_locked` since it wasn't included in
`my_current_funding_locked`, but only after the channel has been
reestablished.

Found by the chanmon_consistency fuzz target.

Avoid splice checks when responding to stfu

Only gate local quiescence initiation on splice RBF eligibility. If the
counterparty initiated quiescence first, respond with non-initiator stfu
once pending channel updates are clear.

Handle overflowing route-hint fee aggregates

Crafted route hints can overflow aggregate downstream proportional fees
when the payer disables the routing fee cap. Treat such paths as
unusable so route finding fails cleanly instead of panicking.

Co-Authored-By: HAL 9000
Signed-off-by: Elias Rohrer <dev@tnull.de>

fuzz: add deferred chanmon checkpoints

Track deferred monitor writes in the harness and checkpoint the
ChannelManager state before flushing them to the persister.

This extends setup, reload, and settle paths to model deferred
ChainMonitor persistence ordering.

fuzz: keep settling after progress-only passes

Treat HTLC-forward processing and monitor completion as real progress
in the chanmon harness.

This keeps the settle loop running after passes that only unblock
follow-up work instead of stopping before the next event or message
batch.

fuzz: reload monitors with the configured status

Build the replacement persister with the configured monitor update
status during reload.

This keeps non-deferred restart behavior aligned with the active
persistence-style matrix.

fuzz: model chanmon persistence in harness

Replace the chanmon consistency harness' Watch wrapper with a Persist
implementation backed by HarnessPersister. Monitor writes now flow
through the real ChainMonitor persistence hooks.

Track restart candidates separately from monitor completion callbacks. A
monitor can stop being a valid reload candidate once a newer baseline is
durable, while its callback may still be needed to unblock the live
ChainMonitor.

On reload, choose the durable baseline, first pending snapshot, or last
pending snapshot. Startup monitor registration completes immediately
before the configured persistence style is restored.