rust-lightning

Count zero-fee-commitments channels in anchor reserve check

`can_support_additional_anchor_channel` decides whether the wallet has
enough on-chain reserve to back another anchor channel by counting the
node's existing anchor channels. The classification only checked the
`anchors_zero_fee_htlc_tx` feature, so channels negotiated with the
`anchor_zero_fee_commitments` (TRUC / 0FC, option 41) variant — which
require the same on-chain reserve to fund commitment / HTLC fee bumps
on force-close — were silently dropped from the count.

A node enabling `negotiate_anchor_zero_fee_commitments` would therefore
be green-lit to open more anchor channels than its wallet can actually
back, risking unfunded fee bumps and HTLC loss on simultaneous
force-closes.

Treat both feature flags as marking a channel as an anchor channel for
reserve-accounting purposes (factored into a small `is_anchor_channel_type`
helper, used in both the chain-monitor and channel-manager loops), and
add a regression test that opens a single 0FC channel with reserves
sized for exactly one channel and asserts the function refuses to
authorize a second.

Co-Authored-By: HAL 9000

Free pending_query_count slot when DNS proof build fails

`OMDomainResolver` rate-limits in-flight DNSSEC proof builds via a
`pending_query_count` counter capped at `MAX_PENDING_RESPONSES` (1024).
The counter was only released when the proof build succeeded, so any
failure mode -- NXDOMAIN, insecure zones, unreachable resolvers, I/O
timeouts, malformed names -- permanently consumed a slot.

Because the queried name is attacker-controlled (it travels in over a
`DNSSECQuery` onion message from any LN peer, given DNS resolution is
an opt-in network-advertised feature), an adversary could exhaust the
counter with ~1025 failing queries and persistently DoS the resolver
for any subsequent legitimate BIP-353 lookups, until the process is
restarted.

Always release the slot once the proof build completes, regardless of
outcome, and add a regression test which points the resolver at a
TCP-refusing local port and asserts the counter returns to zero.

Co-Authored-By: HAL 9000

Fix signed comparison in `ElectrumClient`

`GetHistoryRes::height` from electrum-client is a *signed* integer. Here
we first check for `<= 0` *before* casting to `u32`.

Signed-off-by: Elias Rohrer <dev@tnull.de>

Always enforce the 1000sat min channel value in zero-reserve channels

We did not enforce this minimum when accepting 0-reserve channels. This
is because we depended on the `MIN_THEIR_CHAN_RESERVE_SATOSHIS` constant
to guarantee this minimum channel value, but this value is no longer
read in 0-reserve channels.

Note that the user's `min_funding_satoshis` value would still be
respected in this case.

When splicing 0-reserve channels, we only enforced that the commitment
transaction retained at least one output after the splice, which could
produce a channel value lower than 1000sats.

Along the way, we also now enforce this 1000sat minimum when splicing
reserve-enabled channels. We previously correctly enforced the reserves
after the splice, but this could still result in a channel value smaller
than 1000sats. This case is now rejected during splice validation.

Note that the user's `min_funding_satoshis` is not respected when
validating splice contributions, we leave this for follow-up work.

Add `ChannelDetails::next_splice_out_maximum_sat`

Add `test_0reserve_splice`

Use `next_splice_out_maximum_sat` to validate `funding_contributed`

This is equivalent to the previous commit, see the debug assertions
added in the previous commit. We now also get to communicate the
exact maximum back to the user, instead of some "balance is lower
than our reserve" message, which is hard to react to.

Add `AvailableBalances::next_splice_out_maximum_sat`

We previously determined this value by subtracting the htlcs, the
anchors, and the commitment transaction fee. This ignored the reserve,
as well as the at-least-one-output requirement in zero-reserve channels.

This new field now accounts for both of these constraints. It can be
seen as the total spliceable balance from the channel.

Run existing validation code against the candidate funding scope

As a result, we now validate that both commitments retain at least one
output under the new funding scope, which is crucial for zero-reserve
channels.

Switch to ldk-fuzzing-corpus repo rather than CI cache

Rather than storing our fuzzing corpus in the CI cache, move it to
a new repo which anyone can use for their own local fuzzing and
can be updated outside of CI with additional seeds.

Fix typo in `_encode_tlv` leading to confused encoding

`as_ref()` before wrapping encoded types in writing `option` TLVs

We almost certainly don't want to be moving `option` TLVs during
serialization, and while we had logic elsewhere to work around this
previously its nice not to have to in the future.

Check fuzz workspace formatting in CI

Extend the rustfmt CI job to check the fuzz workspace.

This covers fuzz alongside the root workspace and lightning-tests.

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>

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>

Model RBF splice tx replacement in chanmon_consistency

The SplicePending event handler was immediately confirming splice
transactions, which caused force-closes when RBF splice replacements
were also confirmed for the same channel. Since both transactions spend
the same funding UTXO, only one can exist on a real chain.

Model this properly by adding a mempool-like pending pool to ChainState.
Splice transactions are added to the pool instead of being confirmed
immediately. At chain-sync time, pending transactions are sorted by
txid and confirmed together in one block; candidates that double-spend
an already-confirmed outpoint or another candidate earlier in the sort
are dropped.

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

Rename `BestBlock` to `BlockLocator`

`BestBlock` is now really a pointer to a block rather than just a
block itself, so its weird to still call it `BestBlock`. Here we
rename it to `BlockLocator`.

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

Use `bitreq::Url` for LSPS5 webhook URLs

Replace the custom LSPS5 URL parser with `bitreq::Url` while keeping the
LSPS5-specific HTTPS and length checks. This reduces bespoke parsing
logic and aligns accepted webhook URLs with the HTTP client's URL
handling.

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

Handle DiscardFunding with FundingInfo::Tx variant in chanmon_consistency

The process_events! macro only handled DiscardFunding events with
FundingInfo::Contribution, but splice RBF replacements can produce
DiscardFunding with FundingInfo::Tx when the original splice transaction
is discarded.

Co-Authored-By: Claude Opus 4.6 (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>

Return InteractiveTxMsgError from splice_init and tx_init_rbf

The prior two commits manually intercepted ChannelError::Abort in the
channelmanager handlers for splice_init and tx_init_rbf to exit
quiescence before returning, since the channel methods didn't signal
this themselves. The interactive TX message handlers already solved this
by returning InteractiveTxMsgError which bundles exited_quiescence into
the error type.

Apply the same pattern: change splice_init and tx_init_rbf to return
InteractiveTxMsgError, adding a quiescent_negotiation_err helper on
FundedChannel that exits quiescence for Abort errors and passes through
other variants unchanged. Extract handle_interactive_tx_msg_err in
channelmanager to deduplicate the error handling across internal_tx_msg,
internal_splice_init, internal_tx_init_rbf, and internal_tx_complete.

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

Remove exited_quiescence from error handling

The `exited_quiescence` field on `MsgHandleErrInternal` and
`InteractiveTxMsgError` is a leaky abstraction -- the channelmanager
error handling shouldn't know about quiescence, only whether the holding
cell needs to be released.

Infer this from the presence of a `tx_abort` instead, since exiting
quiescence via an error always produces one. Remove `exited_quiescence`
from `InteractiveTxMsgError`, `MsgHandleErrInternal`, and the return
type of `Channel::tx_abort`, along with the `with_exited_quiescence`
builder.

For unfunded v2 channels, `tx_abort` may be present without quiescence
having been exited, but the holding cell release is a no-op since an
unfunded channel won't have any HTLCs. Similarly, the unreachable
`debug_assert!(false)` branch in `fail_interactive_tx_negotiation` for
funded channels produces a `tx_abort` without exiting quiescence, but
the holding cell release is a no-op since the channel is still quiescent.

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

Exit quiescence when tx_init_rbf is rejected with Abort

When tx_init_rbf is rejected with ChannelError::Abort (e.g.,
insufficient RBF feerate, negotiation in progress, feerate too high),
the error is converted to a tx_abort message but quiescence is never
exited and holding cells are never freed. This leaves the channel stuck
in a quiescent state.

Fix this by intercepting ChannelError::Abort before try_channel_entry!
in internal_tx_init_rbf, calling exit_quiescence on the channel, and
returning the error with exited_quiescence set so that handle_error
frees holding cells. Also make exit_quiescence available in non-test
builds by removing its cfg gate.

Update tests to use the proper RBF initiation flow (with tampered
feerates) so that handle_tx_abort correctly echoes the abort and exits
quiescence, rather than manually crafting tx_init_rbf messages that
leave node 0 without proper negotiation state.

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

Exit quiescence when splice_init is rejected with Abort

The same bug fixed in the prior commit for tx_init_rbf also exists in
internal_splice_init: when splice_init triggers FeeRateTooHigh in
resolve_queued_contribution, the ChannelError::Abort goes through
try_channel_entry! without exiting quiescence.

Apply the same fix: intercept ChannelError::Abort before
try_channel_entry!, call exit_quiescence, and return the error with
exited_quiescence set.

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

Add FilesystemStoreV2Error for v1 data detection

FilesystemStoreV2::new previously returned io::Error with
ErrorKind::InvalidData when the data directory contained top-level
files left behind by FilesystemStore (v1). That forced us to
match on an error that could potentially be given by our normal io
calls. This adds a dedicated FilesystemStoreV2Error enum with a
V1DataDetected(PathBuf) so we can distinguish between normal io
errors and an old V1 fs store.