rust-lightning

Format `ChannelManager::create_channel_internal` and...

`ChannelContext::do_accept_channel_checks`,
`ChannelContext::new_for_outbound_channel`,
`ChannelContext::new_for_inbound_channel`,
`InboundV1Channel::new`,
`OutboundV1Channel::new`.

Add 0-reserve to the internal API of V2 channels

Note that this currently does not match the spec as we use an odd TLV
for the `disable_channel_reserve` field in `open_channel2` and
`accept_channel2` msgs.

If the counterparty does not understand this field, that's ok as it just
means that the counterparty will not send some HTLCs we would have
accepted.

We make the assumption that the counterparty will not complain if we
send a HTLC that pushes their balance below our selected reserve; this
could happen if the counterparty is the funder of the channel. They
should not complain because if we push them below our selected reserve,
this is our problem.

Add `ChannelManager::create_channel_to_trusted_peer_0reserve`

This new method sets 0-reserve for the channel accepter.

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.

Shakedown zero reserve channels

Add 0-reserve to `accept_inbound_channel_from_trusted_peer`

This new flag sets 0-reserve for the channel opener.

Update `chanmon_consistency` to include 0FC and 0-reserve channels

Co-Authored-By: HAL 9000

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.

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>

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>

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>

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.