rust-lightning

Don't fail channel if inbound UA breaches counterparty-selected reserve

We do not care if our balance drops below the counterparty-selected
reserve upon an inbound `update_add_htlc`. This is the counterparty's
problem.

Hence, we drop the assumption that once our balance rises above the
counterparty-selected reserve, it will always remain above this reserve
for the lifetime of a funding scope.

In the following commit, we make the assumption that the counterparty
does not complain if we push them below our selected reserve when adding
a HTLC, so we accommodate this assumption here.

Prevent downgrades in case holder-selected reserve is zero satoshis

We prevent downgrades from 0.3 only in the case where the
holder-selected reserve is 0, as we've had support for counterparty
selected 0-reserves in prior releases.

There is no need for this sentinel in `FundingScope` serialization code
as this would only apply to pending `FundingScope`'s.

Also, if the current scope has some zero-reserve, that reserve is
carried over to all pending scopes automatically. Therefore it is not
possible for a pending scope to have some 0-reserve without the current
one also having it.

Reject RBF with non-confirming feerate after several attempts

After a few RBF attempts, both our own and the counterparty's RBF
should target a feerate that will actually confirm. Reject attempts
with feerates below the fee estimator's NonAnchorChannelFee target
to prevent exhausting the RBF budget at low feerates.

The spec requires: "MUST set a high enough feerate to ensure quick
confirmation."

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

Re-validate contribution at quiescence time

Outbound HTLCs can be sent between funding_contributed and quiescence,
reducing the holder's balance. Re-validate the contribution when
quiescence is achieved and balances are stable. On failure, emit
SpliceFailed + DiscardFunding events and disconnect the peer so both
sides cleanly exit quiescence.

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

Set the correct floor for the reserves in inbound V2 channels

The floor for *our* selected reserve is *their* dust limit.

Add inbound and outbound checks for zero reserve channels

The goal is to prevent any commitments with no outputs, since these are
not broadcastable.

Add FundingContributionError for FundingTemplate methods

Replace opaque Err(()) returns from FundingTemplate methods with a
descriptive FundingContributionError enum. This gives callers diagnostic
information about what went wrong: feerate bounds violations, invalid
splice values, coin selection failures, or non-RBF scenarios.

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

Preserve original contribution on counterparty RBF abort

When the counterparty initiates an RBF, the prior contribution was
popped and replaced with the feerate-adjusted version. If the RBF
aborted, the adjusted version persisted, leaving a stale higher
feerate in contributions.

Change contributions to be an append-only log where each negotiation
round pushes a new entry. On abort, pop the last entry if its feerate
doesn't match the locked feerate. This naturally preserves the original
contribution as an earlier entry in the vec.

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

Merge rbf_channel into splice_channel and expose prior contribution

Users previously had to choose between splice_channel (fresh splice) and
rbf_channel (fee bump) upfront. Since splice_channel already detects
pending splices and computes the minimum RBF feerate, rbf_channel was
redundant. Merging into a single API lets the user call one method and
discover from the returned FundingTemplate whether an RBF is possible.

The FundingTemplate now carries the user's prior contribution from the
previous splice negotiation when one is available. This lets users reuse
their existing contribution for an RBF without performing new coin
selection. A PriorContribution enum distinguishes whether the
contribution has been adjusted to the minimum RBF feerate (Adjusted) or
could not be adjusted due to insufficient fee buffer or max_feerate
constraints (Unadjusted).

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

Adjust contribution feerate to minimum RBF feerate in funding_contributed

When splice_channel is called before a counterparty's splice exists, the
user builds a contribution at their chosen feerate without a minimum RBF feerate.
If the counterparty completes a splice before funding_contributed is
called, the contribution's feerate may be below the 25/24 RBF
requirement. Rather than always waiting for the pending splice to lock
(which would proceed as a fresh splice), funding_contributed now attempts
to adjust the contribution's feerate upward to the minimum RBF feerate when the
budget allows, enabling an immediate RBF.

When the adjustment isn't possible (max_feerate too low or insufficient
fee buffer), the contribution is left unchanged and try_send_stfu delays
until the pending splice locks, at which point the splice proceeds at the
original feerate.

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

Send BroadcastChannelAnnouncements via the broadcast queue

In 47a3e5c694321dac1a1d0f53e6dcb357282a79be we started asserting
that the per-peer message queue was empty when a peer connected to
ensure we don't have stale messages sitting around in memory. This
turned up an issue for `channel_announcement` messages generated by
block connections while a peer was disconnected.

Here we push those out through the broadcast message queue rather
than the per-peer message queue as there's no reason to tie them to
the individual peer anyway, fixing the assertions.

This should fix #4437

Written by Claude

fuzz: improve iteration scaling, add minimization and summary table

Replace the fixed 30s run_time with iteration counts scaled to 8x
corpus size (plus a 1000 baseline) with a 10-minute hard cap per
target. This ensures the full corpus is replayed with room for
mutations, while small targets finish quickly.

On main (and on PRs with the fuzz-minimize label), run honggfuzz
corpus minimization after each target to prune inputs that don't
contribute unique coverage, keeping the cache size manageable.

Print a summary table at the end with per-target stats: iterations,
corpus sizes before/after fuzzing and minimization, and run times.

Other changes:
- Use -q (quiet) to suppress per-iteration status output
- Set 3s per-input timeout (-t 3) for all targets
- Pass FUZZ_MINIMIZE env var from PR label in workflow
- Check for crashes after minimization, not just after fuzzing

AI tools were used in preparing this commit.

ci: split fuzz sanity check into separate parallel job

The sanity check (cargo test on fuzz targets) doesn't use the
restored corpus and was blocking the actual fuzz run. Move it to
a separate fuzz_sanity job so both run in parallel.

AI tools were used in preparing this commit.

Skip mixed-mode assertion for replayed monitor updates

When a node restarts and switches from async to sync persistence, the
in-flight monitor updates from the previous session are replayed as
background events. These replayed updates are resubmitted to the Watch
which now returns Completed, while earlier in-flight updates are still
queued as background events. This triggered a false panic in the
assertion that guards against out-of-order monitor update completion.

Track whether an update is a replay (already present in
in_flight_monitor_updates) and skip the assertion for replays, since
the remaining in-flight updates will be submitted by subsequent
background events.

AI tools were used in preparing this commit.

Add .cargo/config.toml for fuzz cfg flags

Set fuzzing, secp256k1_fuzz, and hashes_fuzz cfg flags in
fuzz/.cargo/config.toml so they are automatically applied to plain
cargo commands (cargo test, cargo run) run from the fuzz directory.
Remove the now-redundant RUSTFLAGS from the README crash reproduction
examples, the CI cargo test step, and generate_fuzz_coverage.sh.

The honggfuzz and cargo-fuzz docs are unchanged because those tools
build their own RUSTFLAGS env var (which overrides config.toml) and
require the flags to be exported separately.

AI tools were used in preparing this commit.

Defer monitor update completions after funding spend

When no_further_updates_allowed() is true and the persister returns
Completed, ChainMonitor now overrides the return to InProgress and
pushes a MonitorEvent::Completed directly into pending_monitor_events.
In release_pending_monitor_events, these deferred completions are
appended after per-monitor events, so ChannelManager sees the
force-close MonitorEvents before the completion.

This eliminates phantom InProgress entries that would never complete:
previously, a rejected pre-close update (e.g. commitment_signed
arriving after funding spend) returned InProgress with no completion
path, blocking MonitorUpdateCompletionActions (PaymentClaimed,
PaymentForwarded) indefinitely. A subsequent post-close update
returning Completed would then violate the in-order completion
invariant.

AI tools were used in preparing this commit.

fuzz: use process::exit panic hook in stdin_fuzz on macOS

On macOS, panic=abort causes the process to call abort() which sends
SIGABRT. The ReportCrash daemon then tries to generate a crash report,
leaving the process stuck in an uninterruptible wait state that cannot
be killed even with SIGKILL. This makes stdin_fuzz unusable for crash
reproduction on macOS.

Install a custom panic hook (gated behind #[cfg(target_os = "macos")])
that flushes stdout (preserving log output), prints the panic info with
a full backtrace to stderr, then calls process::exit(1) to terminate
cleanly before the abort machinery runs. The hook is only installed on
macOS to avoid interfering with debuggers like GDB on Linux.

AI tools were used in preparing this commit.

Release tx_signatures after async monitor update completes

In 83b2d3e, we reworked `ChannelManager::funding_transaction_signed`
such that it would also for a user to cancel a splice up until they send
`commitment_signed`. Previously, we would would only emit
`Event::FundingTransactionReadyForSigning` when both nodes exchanged
`commitment_signed` and the corresponding monitor update completed. With
the event now being generated immediately after the nodes exchange
`tx_complete`, we now need to handle the monitor update not having
completed by the time we are ready to send `tx_signatures`.
Unfortunately, we also did not have test coverage, allowing this to go
unnoticed until being caught by the fuzzer due to a debug assertion.
Doing so avoids a potential funds-loss scenario if the funding
transaction confirms without the counterparty's signature for our
commitment being durably persisted.

Add test for monitor update after funding spend

Add a regression test that reproduces the panic when a commitment_signed
is processed after the counterparty commitment transaction has confirmed.
The ChannelMonitor's no_further_updates_allowed() returns true, causing
update_monitor to fail, which ChainMonitor overrides to InProgress. A
subsequent preimage claim returning Completed then triggers the
per-channel assertion that Completed must not follow InProgress.

AI tools were used in preparing this commit.

Replace dual-sync-async persistence panic with Watch contract

Commit 0760f99 ("Disallow dual-sync-async persistence without
restarting") added a panic in non-test builds when a Persist
implementation returns both Completed and InProgress from the same
ChannelManager instance. However, this check runs against the status
that ChainMonitor returns to ChannelManager, not the raw Persist
result. When ChannelMonitor::update_monitor fails (e.g. a
counterparty commitment_signed arrives after a funding spend
confirms), ChainMonitor persists the full monitor successfully but
overrides the return value to InProgress. If the user's Persist impl
only ever returns Completed, this override triggers a false
mode-mismatch panic.

This replaces the panic with a per-channel contract at the Watch
trait level: a Watch implementation must not return Completed for a
channel update while prior InProgress updates are still pending.
Switching from Completed to InProgress is always allowed, but
switching back is impractical because the Watch implementation cannot
observe when ChannelManager has finished processing a
MonitorEvent::Completed. The documentation on
ChannelMonitorUpdateStatus is updated to describe these rules.

The mode tracking and panic checks from 0760f99 are removed and
replaced with a panic that validates the new contract directly on
the in-flight update state. Legacy tests that switch the persister
between modes mid-flight can opt out via
Node::disable_monitor_completeness_assertion().

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

ci: fix OOM in artifact upload and update actions to v4

fuzz: handle missing SendTx* message events in chanmon_consistency

Add handlers for SendTxInitRbf, SendTxAckRbf, SendTxRemoveInput, and
SendTxRemoveOutput in the chanmon_consistency fuzz target. These
variants were reachable but not matched, causing panics on the wildcard
arm ("Unhandled message event").

SendTxInitRbf became reachable after commit 5873660a0 added splicing
support without updating the fuzz target's message delivery logic.

AI tools were used in preparing this commit.

Assign random ids to monitor events

Currently, the resolution of HTLCs (and decisions on when HTLCs can be
forwarded) is the responsibility of Channel objects (a part of ChannelManager)
until the channel is closed, and then the ChannelMonitor thereafter. This leads
to some complexity around race conditions for HTLCs right around channel
closure. Additionally, there is lots of complexity reconstructing the state of
all HTLCs in the ChannelManager deserialization/loading logic.

Instead, we want to do all resolution in ChannelMonitors (in response to
ChannelMonitorUpdates) and pass them back to ChannelManager in the form of
MonitorEvents (similar to how HTLCs are resolved after channels are closed). In
order to have reliable resolution, we'll need to keep MonitorEvents around in
the ChannelMonitor until the ChannelManager has finished processing them. This
simplifies things - on restart instead of examining the set of HTLCs in
monitors we can simply replay all the pending MonitorEvents.

To allow the ChannelManager to ack specific monitor events once they are
resolved, here we give each MonitorEvent a corresponding unique id. It's
implemented in such a way that we can delete legacy monitor event serialization
in future LDK versions when persistent monitor events are enabled by default.

Fail HTLCs from late counterparty commitment updates after funding spend

When a ChannelMonitorUpdate containing a new counterparty commitment is
dispatched (e.g. via deferred writes) before a channel force-closes but
only applied to the in-memory monitor after the commitment transaction
has already confirmed on-chain, the outbound HTLCs in that update must
be failed back.

Add fail_htlcs_from_update_after_funding_spend to ChannelMonitorImpl
which detects this race condition during update_monitor. When a
LatestCounterpartyCommitmentTXInfo or LatestCounterpartyCommitment
update is applied and the funding output has already been spent, the
function iterates all outbound HTLCs from the update and creates
OnchainEvent::HTLCUpdate entries for those that need to be failed back.
These entries mature after ANTI_REORG_DELAY blocks, giving time for the
peer to potentially broadcast the newer commitment.

HTLCs that appear as non-dust outputs in the confirmed commitment
(whether counterparty or holder) are skipped, as they will be resolved
on-chain via the normal HTLC timeout/success path. HTLCs already
fulfilled by the counterparty (tracked in counterparty_fulfilled_htlcs)
are also skipped. Duplicate failures from previously-known counterparty
commitments are handled gracefully by the ChannelManager.

AI tools were used in preparing this commit.

Implement deferred monitor write queueing and flushing

Replace the unimplemented!() stubs with a full deferred write
implementation. When ChainMonitor has deferred=true, Watch trait
operations queue PendingMonitorOp entries instead of executing
immediately. A new flush() method drains the queue and forwards
operations to the internal watch/update methods, calling
channel_monitor_updated on Completed status.

The BackgroundProcessor is updated to capture pending_operation_count
before persisting the ChannelManager, then flush that many writes
afterward - ensuring monitor writes happen in the correct order
relative to manager persistence.

Key changes:
- Add PendingMonitorOp enum and pending_ops queue to ChainMonitor
- Implement flush() and pending_operation_count() public methods
- Integrate flush calls in BackgroundProcessor (both sync and async)
- Add TestChainMonitor::new_deferred, flush helpers, and auto-flush
in release_pending_monitor_events for test compatibility
- Add create_node_cfgs_deferred for deferred-mode test networks
- Add unit tests for queue/flush mechanics and full payment flow

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