rust-lightning

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.

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

We previously accounted for HTLC trims at the spiked feerate when
calculating the reserved commitment transaction fees.

This could cause an underestimate of the real current commitment fee at
the current channel feerate. This is because a 2x increase in the
feerate could trim enough HTLCs to result in a smaller commitment
transaction fee.

Also, the previous code only reserved the fee for an exact 2x increase
in the feerate, instead of reserving the fee for any increase in the
feerate between 1x to 2x.

Fixes #4563.

Commit to payment_metadata in inbound payment HMAC

When payment_metadata is set in a BOLT 11 invoice, users expect to
receive it back as-is in the payment onion. In order to ensure it
isn't tampered with, they presumably will add an HMAC, or worse, not
add one and forget that it can be tampered with.

Instead, here we include it in the HMAC computation for the payment
secret. This ensures that the sender must relay the correct
metadata for the payment to be accepted by the receiver, binding
the metadata to the payment cryptographically.

The metadata is only included in the HMAC when present, so existing
payments without metadata continue to verify correctly. However,
this does break receiving payments with metadata today. On an
upgrade this seems acceptable to me given we have seen almost no
use of payment metadata in practice.

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

Default to requiring `payment_metadata` when building BOLT 11s

Now that we commit to payment metadata fields and require them
implicitly as a part of payments, we should match that in
`lightning-invoice` - instead marking them as required by default.

Refer to payment info as `info` in `inbound_payment` not `metadata`

`payment_metadata` is a separate concept at the BOLT 11 layer
(similar to payment secret, but arbitrary-sized) and at the BOLT 12
layer, so referring to payment information as "payment metadata" is
confusing. Instead, use simply "payment info".

Add an auto-generated unicode character category file

1a01b5ae4fb74bfff763b968719e362e546bd594 added detection of unicode
format characters in `PrintableString`, but used a hard-coded table
which may eventually become out of date.

Here we switch to an auto-generated table, include all
`General_Category` `Other` characters, and also ban unallocated
code points.

Finally, CI validates that the file is kept up to date.

Written by Claude

Include NegotiationFailureReason in InteractiveTxMsgError

Each `SpliceNegotiationFailed` event originating from an
`InteractiveTxMsgError` needs a `NegotiationFailureReason`, so it makes
sense to track it in the same place. In most cases, the
`NegotiationFailureReason` included uses the `NegotiationError` variant,
but other cases may require their own specific variant, such as
`LocallyCanceled` after calling
`ChannelManager::cancel_funding_contributed`.

Bump transaction sync dev dependencies

Bump electrum-client to v0.25

Reset LSPS5 `persistence_in_flight` counter on persist errors

`LSPS5ServiceHandler::persist` incremented `persistence_in_flight` at
the top as a single-runner gate, but only decremented it on the
success path: each interior `?` on a `kv_store` future propagated the
error out of the function while leaving the counter at >= 1. After
one transient I/O failure (disk full, brief unavailability of a
remote `KVStore`, EPERM, etc.) every subsequent `persist()` call hit
the `fetch_add > 0` short-circuit and silently returned `Ok(false)`.

The in-memory `needs_persist` flags then continued to grow without
ever reaching disk, so webhook state, removals, and notification
cooldowns were lost on the next process restart — including the
spec-mandated webhook retention/pruning state — without any error
surfaced to the operator. The counter is monotonic, so recovery
required a process restart.

Adopt the LSPS1 / LSPS2 pattern: split the body into an inner
`do_persist` and an outer `persist` that unconditionally clears the
counter via `store(0)` after the call returns, regardless of
outcome. A failed write now still propagates `Err`, but the next
`persist()` attempt actually retries the write instead of no-op'ing.

Co-Authored-By: HAL 9000

Add chanmon stuck HTLC invariant

Assert that channel HTLC sets are empty after harness quiescence.

Build chanmon consistency harness

Collect the chanmon consistency setup, state, and main fuzz
flow into a harness.

Keep do_test focused on reading fuzz bytes and dispatching
actions.