rust-lightning

Count symlinked fuzz corpus files

The fuzz CI job links cloned corpus dirs into hfuzz_workspace, but
plain find does not descend through those symlinked directories.

Count with find -L so the iteration budget reflects the real corpus
size, and fail loudly if a linked corpus resolves to zero files.

Remove FundingTxInput type alias in favor of ConfirmedUtxo

ConfirmedUtxo already documents its use as a funding input for v2
channel establishment and splicing, so the alias added a layer of
indirection without conveying additional information.

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

Don't check for no-outputs under fee spikes in `get_available_balances`

We only assume fee spikes in legacy channels, and we do not allow
`holder_selected_channel_reserve_satoshis` to be set to zero in such
channels. It is nonetheless still possible to reach the no-outputs case
in a fee spike with solely the counterparty selected reserve set to
zero, so we still guard against this case in
`get_next_commitment_stats`.

We don't guard against no-outputs under fee spikes
`get_available_balances`; in the worst case, the receiver of the HTLC we
just sent fails it back.

Remove all tests covering 0-reserve legacy channels

Disallow holders from selecting 0-reserve in legacy channels

We still allow counterparties to set 0-reserve legacy channels, as in
prior releases.

Add test coverage for the ban on 0-reserve legacy channels

Detect duplicate inputs and outputs upon building FundingBuilder

While this is already enforced when we get to the interactive
negotiation phase, we choose to fail early anyway.

Include spliceable balance in every FundingTemplate

There's no reason not to do so, and it allows us to fail earlier when
the user's net contribution exceeds their spliceable balance.

Support manually selecting inputs consuming their entire value

This commit introduces an alternative way of splicing in funds without
coin selection by requiring the full UTXO to be provided. Each UTXO's
entire value (minus fees) is allocated towards the channel, which
provides unified balance wallets a more intuitive API when splicing
funds into the channel, as they don't particularly care about
maintaining a portion of their balance onchain.

To simplify the implementation, we require that contributions are not
allowed to mix coin-selected inputs with manually-selected ones. Users
will need to start a fresh contribution if they want to change the
funding input mode.

Account for fuzz signature weight

When secp256k1_fuzz is active, dummy ECDSA signatures may
serialize one byte larger per signature. Use fuzz-aware witness
estimates for keyed-anchor bumping and HTLC resolution so debug
weight assertions and aggregation limits use the fuzz signer bound.

Avoid grind signatures in fuzz builds

Disable default lightning features in the fuzz crate and persister
so fuzz builds do not inherit grind_signatures.

Add a compile-time guard for fuzzing plus grind_signatures.
Refresh the splice fuzz seed because the no-low-R weight model
changes the signed funding transaction amount and fake-hash txid.

Skip stale fs store artifacts

The exhaustive filesystem store listing treated leftover temp and trash
files as namespace directories after identifying them as non-keys.
Skip those artifacts before recursing so migrations can ignore crash
leftovers.

Document script_pubkey-only matching in into_unique_contributions

The function compares outputs by script_pubkey alone, not full TxOut,
so any contribution output sharing a script with an existing output is
filtered regardless of value. This is intentional — a change output's
value may shift between rounds (e.g., for a new feerate) and should
still match. But the consequence isn't obvious: multiple contribution
outputs sharing a script are all filtered together when any existing
output uses that script. Document it.

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

Document SpliceNegotiationFailed contribution / DiscardFunding overlap

The contribution returned in Event::SpliceNegotiationFailed may include
inputs and outputs already committed to a prior negotiated (but not yet
locked) splice transaction. Those overlapping items are intentionally
omitted from the preceding Event::DiscardFunding to avoid prompting the
user to reclaim UTXOs that are still in use elsewhere. The relationship
was documented on the internal SpliceFundingFailed fields but lost when
they were made private; surface it on the public event field doc.

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

Pick NegotiationFailureReason at error construction

QuiescentError::FailSplice was built with a placeholder
NegotiationFailureReason::Unknown and expected callers to chain a
with_negotiation_failure_reason builder. Sites that forgot the chain
leaked Unknown into Event::SpliceNegotiationFailed, and the pattern
forced splice-specific reason vocabulary into the generic
QuiescentAction helper.

Each call site in propose_quiescence now picks the reason at
construction. The pending-quiescent-action branch is unreachable, so
it asserts unconditionally; the match retains arms for both action
variants so release builds return a sensible error if the invariant
is violated. abandon_quiescent_action returns SpliceFundingFailed
directly without round-tripping through QuiescentError, since the
reason was always discarded there.

Make funding_contributed's pending-quiescent-action check exhaustive
on QuiescentAction. A future variant produces a compile error here
and at the matching arm in propose_quiescence, forcing the author to
decide how it interacts with funding contribution.

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

Enforce `min_funding_satoshis` after splices

In inbound channels, we already enforce this minimum at channel open, so
it makes sense to also enforce this minimum on any splices in which the
counterparty's contribution is negative.

Codex wrote the tests.

Bound sync loops in lightning-transaction-sync

If we start syncing from an electrum or esplora server and find
that the chain moved during our sync, we reset and start fresh.
However, if that happens repeatedly, we probably shouldn't just
spin forever. Here we give up after ten attempts and just hope we
can sync properly later.

Don't persist inbound committed onions in prod

A few PRs ago, we started persisting inbound committed HTLC onions in Channels.
These onions were persisted to lay groundwork for reconstructing the
ChannelManager's pending HTLC maps from them in a future version. However,
we've since discovered a different direction where we can instead reconstruct
these same maps using persistent monitor events, which may mean that we don't
need to persist these onions.

Since persisting a bunch of onions on every manager write is a big commitment
that we're not fully confident in yet, switch it off for now until we either
confirm the monitor events direction and can delete all this onion persisting
code OR realize that we definitely do need it.

Add a `payment_metadata` map in blinded payment path contexts

Similar to how BOLT 11 payments can use a `payment_metadata` to
provide arbitrary bytes in the invoice to be communicated back to
them when receiving, its useful to be able to provide some bytes
which are communicated back upon receiving a payment.

Here we do so in the BOLT 12 blinded path contexts, offering a
`BTreeMap<u64, Vec<u8>>` instead to enable more easily including
multiple sets of data.

Also note that a `Router` building a blinded path is allowed to
modify the `payment_metadata` without breaking the payment.

Tests by claude

Add a `payment_metadata` map in BOLT 12 blinded message path ctxs

Similar to how BOLT 11 payments can use a `payment_metadata` to
provide arbitrary bytes in the invoice to be communicated back to
them when receiving, its useful to be able to provide some bytes
which are communicated back upon receiving a payment.

Here we do so in the BOLT 12 blinded message path contexts,
offering a `BTreeMap<u64, Vec<u8>>` instead to enable more easily
including multiple sets of data.

We don't yet wire it up to the public `ChannelManager` API, but do
allow selecting values for those using the manual
`OffersMessageFlow`.

Tests by claude

Run `cargo fmt` on `maybe_downgrade_channel_features`

Move the calculation of the spiked feerate to `tx_builder`

In the next commit, we will make changes to how the fee spike buffer is
calculated which require the real feerate to always be passed to
`tx_builder::get_next_commitment_stats`, even in the case where we
include a fee spike multiple.

Don't trim HTLCs when calculating the fee spike commit tx fee

We previously accounted for HTLC trims at the spiked feerate when
calculating the commitment transaction fee including the fee spike
multiple.

This only ensured that the funder of the channel could afford the
commitment transaction fee for an exact 2x increase in the feerate.

Now, we check that the funder can cover any increase in the feerate
between 1x to 2x.

Support async signing of splice shared input

While user signatures may be provided whenever ready at the user's
discretion when handling a `FundingTransactionReadyForSigning` event, it
does not cover the user's signature for the 2-of-2 multisig input in a
splice. This signature is obtained via the `EcdsaChannelSigner`, which
did not support providing it asynchronously.

Since the splice shared input signature is part of the `tx_signatures`
message, we're not allowed to send the message until it's complete. This
results in us needing to explicitly handle the signature exchange logic
when the signer unblocks the shared input signature.

Add reload test for stuck MPP fulfill

Add a characterization test for a claimed MPP payment whose
preimage monitor updates are only partially persisted before restart.
The test drives both channels through a held fee-update commitment
dance, claims with async monitor persistence, reloads one fresh and
one stale monitor, and verifies that we don't leave a sender-side
HTLC stuck after reconnect.