rust-lightning

Ignore stale announcement_signatures instead of force-closing

A peer may transmit `announcement_signatures` signed over a stale
`short_channel_id` — most plausibly a retransmission or a peer
implementation whose view hasn't caught up to our post-splice
promotion. Verifying such sigs against the current
`UnsignedChannelAnnouncement` (built from `self.funding`) always fails
the hash check, which previously produced a force-close.

BOLT #7 does not require closing in this situation; the mismatch is
expected across splice handoffs. Short-circuit with
`ChannelError::Ignore` when `msg.short_channel_id` doesn't match the
current funding's scid, leaving the genuine invalid-signature paths
in place for sigs that actually target our current scid.

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

Skip pre-splice announcement_signatures on reestablish

When a splice transaction confirms on both sides while peers are
disconnected, each peer's `channel_reestablish` carries
`my_current_funding_locked` with the splice txid. In the reestablish
handler, `get_announcement_sigs` was called before the inferred
`splice_locked` was processed and the splice was promoted, so
`self.funding` still pointed to the pre-splice scope. If
`announcement_sigs_state` was `NotSent`, the generated
`announcement_signatures` carried the pre-splice `short_channel_id`
and bitcoin key — which the peer (having already promoted via its own
inferred `splice_locked`) would verify against the post-splice
`UnsignedChannelAnnouncement`, failing the signature check and
force-closing.

Skip the pre-promotion call when `my_current_funding_locked` matches
the splice we've already confirmed — i.e. `pending_splice.sent_funding_txid`
is set and equals the peer's locked txid. `maybe_promote_splice_funding`
emits correct post-splice signatures after the inferred `splice_locked`
is processed.

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

Clear disconnect timer when exiting quiescence

Several code paths exit quiescence by calling `clear_quiescent()` directly
without also clearing the disconnect timer via `mark_response_received()`.
This causes the timer to fire after the splice completes or is aborted,
spuriously disconnecting the peer.

Replace `clear_quiescent()` with `exit_quiescence()` in
`on_tx_signatures_exchange`, `reset_pending_splice_state`, and
`peer_connected_get_handshake`, which clears both the quiescent state and
the disconnect timer.

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

Split fuzz runners by hash mode

Move shared fuzz logic into the root fuzz crate and generate
fake-hashes and real-hashes runner crates.

Keep `chanmon_consistency_target` on the real-hashes side, remove
the fuzz-local Cargo config, and update scripts, CI, coverage,
and docs to use explicit flags for each runner.

Generate the hash-mode compile checks in the wrapper bins
without a synthetic Cargo feature, while keeping the wrapper
template close to its original shape.

AI tools were used in preparing this commit.

ci: pin hyper-rustls for Rust 1.75 sync builds

The build-sync job started resolving hyper-rustls v0.27.8 for the esplora-async-https configuration. That release requires rustc 1.85, but the sync CI job still runs on Rust 1.75.0.

Pin hyper-rustls to 0.27.7 when building with rustc older than 1.85, alongside the existing MSRV dependency pins in ci-tests-common.sh.

AI tools were used in preparing this commit.

Use `saturating_mul` when multiplying feerates by the fee spike buf

In theory a channel's feerate could be set to some absurd value
(millions of satoshis per vB) and we'd overflow the fee spike
buffer, accepting the absurd fee and ignoring our fee spike buffer
check. This is harmless - the counterparty has much easier ways of
bricking the channel if they want, and paying several BTC in fees
is probably not the best way. Our commitment transaction and dust
fee exposure logic all correctly map the `u32` to a `u64` before
multiplying, making them overflow-safe.

Still, its good to fix overflows because it is a remotely-reachable
crash in debug builds.

Reported by Jordan Mecom of Block's Security Team

Correct blinded path forwarding CLTV expiry check

The `PaymentConstraints::max_cltv_expiry` field exists to ensure
a blinded path expires across the entire path at once - once the
path is expired it will be rejected by the introduction node rather
than traversing the entire path and failing at the destination.

This was broken by the fact that we were checking the outgoing CLTV
value rather than the incoming one, which admittedly isn't clear in
the spec but is somewhat implied. Here we fix this, updating a test
which was actually (kinda) exploiting this privacy loss rather than
allowing the HTLC to fail at the introduction node.

This, of course, does not risk funds loss as our own CLTV policy is
still enforced on top. The only impact it could have is a recipient
which was relying on blinded path expiry to avoid some cost (e.g.
LSPS5 node wakeup cost) involved in receiving an HTLC they
ultimately fail, though I'm not aware of any practical deployment
where that is a concern.

Reported by Jordan Mecom of Block's Security Team

Remove dead string search in fuzz SearchingOutput

The searched-for log message ("Outbound update_fee HTLC buffer
overflow") no longer exists in the lightning crate, so the
from_utf8 + contains check on every log line was pure waste.

AI tools were used in preparing this commit.

Add 0-reserve to `accept_inbound_channel_from_trusted_peer`

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

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.

Add inbound and outbound checks for zero reserve channels

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

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>

Validate all common fields in LSPS1 `is_valid` order check

Add missing cross-validation of `LSPS1OrderParams` against
`LSPS1Options` as required by bLIP-51:

- Check `required_channel_confirmations` >= `min_required_channel_confirmations`
- Check `funding_confirms_within_blocks` >= `min_funding_confirms_within_blocks`
- Check total channel balance (`lsp_balance_sat` + `client_balance_sat`)
is within [`min_channel_balance_sat`, `max_channel_balance_sat`],
using `checked_add` to guard against overflow

Co-Authored-By: HAL 9000

Remove ChannelSignerType

We plan to have a single channel signer type going forward, so this is
unnecessary.

Remove musig2 crate

Taproot support is not planned we see an increase in demand for it by
users. The `musig2` crate is now owned by a third-party, and ultimately
won't be used by the production version of Taproot that we end up
releasing.

Handle FeeRateAdjustmentError variants in splice acceptor path

Replace the generic error handling in splice_init and tx_init_rbf with
explicit matching on FeeRateAdjustmentError variants:

- FeeRateTooLow: initiator's feerate is below our minimum. Proceed
without contribution and preserve QuiescentAction for an RBF retry at
our preferred feerate.
- FeeRateTooHigh: initiator's feerate exceeds our maximum and would
consume too much of our change output. Reject the splice with
WarnAndDisconnect.
- FeeBufferInsufficient: our fee buffer can't cover the acceptor's
estimated fee at this feerate. Proceed without contribution.

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

Handle tx_ack_rbf on the initiator side

After sending tx_init_rbf, the initiator receives tx_ack_rbf from the
acceptor. Implement the handler to validate the response and begin
interactive transaction construction for the RBF funding transaction.

Only clear the interactive signing session in `reset_pending_splice_state`
when the current funding negotiation is in `AwaitingSignatures`. When an
earlier round completed signing and a later RBF round is in `AwaitingAck`
or `ConstructingTransaction`, the session belongs to the prior round and
must be preserved. Otherwise, disconnecting mid-RBF would destroy the
completed prior round's signing session and fire a false debug assertion.

Update test_splice_rbf_acceptor_basic to exercise the full initiator
flow: rbf_channel → funding_contributed → STFU exchange → tx_init_rbf →
tx_ack_rbf → interactive TX → signing → mining → splice_locked. This
replaces the previous test that manually constructed tx_init_rbf.

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

Contribute to splice as acceptor

When both nodes want to splice simultaneously, the quiescence
tie-breaker designates one as the initiator. Previously, the losing
node responded with zero contribution, requiring a second full splice
session after the first splice locked. This is wasteful, especially for
often-offline nodes that may connect and immediately want to splice.

Instead, the losing node contributes to the winner's splice as the
acceptor, merging both contributions into a single splice transaction.
Since the FundingContribution was originally built with initiator fees
(which include common fields and shared input/output weight), the fee is
adjusted to the acceptor rate before contributing, with the surplus
returned to the change output.

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

Adjust FundingContribution for acceptor

When constructing a FundingContribution, it's always assumed the
estimated_fee is for when used as the initiator, who pays for the common
fields and shared inputs / outputs. However, when the contribution is
used as the acceptor, we'd be overpaying fees.

Additionally, the initiator's chosen fee rate may not be compatible with
the acceptors contributions. The selected UTXOs may not be enough to pay
for a higher feerate (i.e., the change output is not enough to pay or
there is no change output).

This change provides a method on FundingContribution for adjusting the
fee rate with the above concerns in mind. It also updates it to include
a max_feerate specified by the user when initiating a splice. This
ensures the acceptor isn't forced to pay an overly high fee rate.

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

Include change output weight in estimate_transaction_fee

Add a `change_output: Option<&TxOut>` parameter to
`estimate_transaction_fee` so the initial fee estimate accounts for the
change output's weight. Previously, the change output weight was omitted
from `estimated_fee` in `FundingContribution`, causing the estimate to
be slightly too low when a change output was present.

This also eliminates an unnecessary `Vec<TxOut>` allocation in
`compute_feerate_adjustment`, which previously cloned outputs into a
temporary Vec just to include the change output for the fee estimate.

A mock `TightBudgetWallet` is added to `splicing_tests` to demonstrate
that `validate()` correctly rejects contributions where the input value
is sufficient without the change output weight but insufficient with it.

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

Stop persisting QuiescentAction and remove legacy code

Now that the Splice variant (containing non-serializable
FundingContribution) is the only variant produced, and the previous
commit consumes the acceptor's quiescent_action in splice_init(),
there is no longer a need to persist it. This allows removing
LegacySplice, SpliceInstructions, ChangeStrategy, and related code
paths including calculate_change_output, calculate_change_output_value,
and the legacy send_splice_init method.

With ChangeStrategy removed, the only remaining path in
calculate_change_output was FromCoinSelection which always returned
Ok(None), making it dead code. The into_interactive_tx_constructor
method is simplified accordingly, and the signer_provider parameter
is removed from it and from splice_init/splice_ack since it was only
needed for the removed change output calculation.

On deserialization, quiescent_action (TLV 65) is still read for
backwards compatibility but discarded, and the awaiting_quiescence
channel state flag is cleared since it cannot be acted upon without
a quiescent_action.

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

Propagate unexpected metadata errors when preserving mtime in fs_store

Previously, all fs::metadata errors were silently ignored via .ok(),
which could hide permission or I/O errors. Now error are properly
handled.