rust-lightning

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.

Extract chanmon harness payment helpers

Move payment bookkeeping into a payment tracker.

Payment sends, resolutions, claims, and stuck checks share one owner.

This avoids borrowing several local maps.

Extract chanmon harness nodes

Centralize creation of the three chanmon harness nodes. The fuzzer now
initializes the node array through one path, which reduces duplicated
setup before the event and payment helpers are split out.

Extract chanmon harness node lifecycle

Move persistence, reload, and chain sync state onto each harness node.
Keeping serialized managers and heights with the node makes restarts and
block updates easier to reason about.

Extract chanmon harness node operations

Move the action helpers onto `HarnessNode` methods. Node-local
operations now live with the state they mutate, which reduces argument
threading through the fuzz loop.

Route chanmon messages through EventQueues

Replace the four directional message vectors with one queue owner.
Move per-node queue draining, middle-node routing, and disconnect
cleanup into EventQueues so routing behavior lives with the queue
state.

Route chanmon fuzz exits through loop break

Replace the local test_return macro with a labeled fuzz loop.

Keep one invariant check after the loop.

Leave harness setup extraction for the next commit.

Extract chanmon harness peer links

Represent each channel pair as a peer link with its channel ids and
disconnect state. Link methods now own peer reconnect, disconnect, and
monitor-update operations for that channel group.

Hoist chanmon process_all_events macro

Move the settlement helper outside the final input arm.

This lets later payment helper extraction use it from more arms.

Build chanmon node resources

Move construction of loggers, keys, monitors, broadcasters, wallets,
and fee estimators into node resource setup. This removes ad hoc local
closures while preserving the deterministic test inputs used by the
fuzzer.

Extract chanmon bootstrap helpers

Extract the repeated peer-connection and channel-funding setup into
small helpers. This leaves the fuzz scenario setup behavior unchanged
while making later harness refactors easier to review.

Wrap chanmon nodes in HarnessNode

Introduce a small wrapper around each channel manager and its test
resources. This keeps node-local state together before moving more
operations onto the harness.

Error if the calculated v2 reserve is greater than the channel value

In 0FC channels, capping the reserve to the total value of the channel
allowed a splice initiator to withdraw past their reserve in case the
acceptor had no balance in the channel.

This is because the post-splice value of the channel was equal to the
initiator's post splice balance. Hence, this post splice balance always
matched the reserve, even though the reserve was below the dust limit.

The only thing that prevented the initiator from withdrawing all their
balance was the script dust limit check in
`interactivetxs::NegotiationContext::receive_tx_add_output`.

In case the splice acceptor had any balance in the channel, or there
were HTLCs in the channel, or the channel was not 0FC, the
splice initiator's post-splice balance was always below the full channel
value. Hence when the reserve was capped at the channel value, the
post-splice balance was always below the reserve, and the splice was
rejected.

Also, in `validate_splice_contributions`, to determine the
`counterparty_selected_channel_reserve`, we now read the holder's dust
limit from the context, instead of the current global constant.

Error if the calculated v1 reserve is greater than the channel value

We made the same change to the calculation of the v2 reserve in the
previous commit.

Rename should_reset_pending_splice_state argument

There's a case in `should_reset_pending_splice_state` where we are
awaiting signatures, but still want to preserve the pending negotiation
upon a disconnection. We previously used `counterparty_aborted` as a way
to toggle this behavior. Now that we support the user manually canceling
an ongoing negotiation, we interpret the argument a bit more
generically in terms of whether we wish to resume the negotiation or not
when we are found in such a state.