rust-lightning

Allow cancellation of pending splice funding negotiations

A user may wish to cancel an in-flight funding negotiation for whatever
reason (e.g., mempool feerates have gone down, inability to sign, etc.),
so we should make it possible for them to do so. Note that this can only
be done for splice funding negotiations for which the user has made a
contribution to.

Produce FundingInfo::Contribution variants in ChannelMonitor

Similar to the `ChannelManager`, we expose the contributed inputs and
outputs of a splice via `FundingInfo::Contribution` at the
`ChannelMonitor` level such that we don't lose the context when the
channel closes while a splice is still pending. This relies on tracking
the `FundingContribution` that was provided to the `ChannelManager`
prior to negotiating the new funding transaction. If no
`FundingContribution` exists, then we continue to emit the
`FundingInfo::OutPoint` variant.

Change FundingInfo::Contribution to expose contributed output scripts

Exposing the amounts for each output isn't very helpful because it's
possible that they vary across over multiple splice candidates due to
RBF. This commit changes `FundingInfo::Contribution` and several of the
helpers used to derive it to be based on output scripts instead.

Strip Unicode `Cf` characters in `PrintableString`

`PrintableString` is the sanitiser LDK uses to render untrusted strings
(node aliases, BOLT-12 invoice / offer text, `UntrustedString`, LSPS
messages, `lightning-invoice` descriptions) to logs and UI. It only
replaced `char::is_control` matches (Unicode general category `Cc`)
with U+FFFD, leaving the entire `Cf` (Format) category untouched.

That is the exact category covering the bidirectional override /
isolate codepoints (U+202A..U+202E, U+2066..U+2069) and zero-width
characters (U+200B..U+200D, U+FEFF) behind the "Trojan Source" attack
family (CVE-2021-42574): a peer can set its alias / invoice description
/ offer fields to e.g. `safe\u{202E}cipsxe.exe`, which previously
passed through verbatim while a human reader sees `safeexe.cips` —
defeating the threat model `PrintableString` exists to defend against.

Replace `Cf` codepoints alongside `Cc` ones. The `Cf` ranges are
inlined as a `matches!` table sourced from Unicode 16.0 to keep the
change `no_std`-friendly with no new dependencies.

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

Expose probe status in recent payments

Previously, `ChannelManager::list_recent_payments` didn't give us the
means to discern 'real' payments from inflight probes. In
https://github.com/lightningdevkit/ldk-node/pull/815 we found that we
need a way to re-derive which probes are still pending so our accounting
of inflight probing amounts is still correct after restart.

To this end, we here let callers distinguish liquidity probes while they
are pending or abandoned.

Co-Authored-By: HAL 9000

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

Derive DiscardFunding inputs and outputs from contributions on promotion

When a splice funding is promoted, produce FundingInfo::Contribution
instead of FundingInfo::Tx for the discarded funding events. Each
contribution is filtered against the promoted funding transaction's
inputs and outputs, so only inputs and outputs unique to the discarded
round are reported.

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

Check can_initiate_rbf in stfu handler before sending tx_init_rbf

If splice_locked is sent between our outgoing STFU and the
counterparty's STFU response, the stfu() handler would proceed to
send tx_init_rbf for an already-confirmed splice. Guard against this
by re-checking can_initiate_rbf when entering quiescence. Disconnect
because there is no way to cancel quiescence after both sides have
exchanged STFU.

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

Add pending changelog for splice negotiation event changes

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

Remove unused NegotiationError and contributed_inputs_and_outputs methods

Now that splice_funding_failed_for! derives inputs and outputs from
FundingContribution directly, remove the unused NegotiationError struct
and into_negotiation_error methods from the interactive tx types, along
with the into/to_contributed_inputs_and_outputs methods on
ConstructedTransaction.

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

Derive SpliceFundingFailed inputs from FundingContribution

Replace the maybe_create_splice_funding_failed! macro and
splice_funding_failed_for method with a unified splice_funding_failed_for!
macro that derives contributed inputs and outputs from the
FundingContribution rather than extracting them from the negotiation
state.

Callers pass ident parameters for which PendingSplice filtering methods
to use: contributed_inputs/contributed_outputs when the current round's
contribution has been popped or was never pushed, and
prior_contributed_inputs/prior_contributed_outputs for the read-only
persistence path where the contribution is cloned instead.

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

Fix output filtering in into_unique_contributions

Filter outputs by script_pubkey rather than full TxOut equality. Outputs
reusing the same address as a prior round are still considered committed
even if the value differs (e.g., different change amounts across RBF
rounds with different feerates).

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

Simplify contribution pop in reset_pending_splice_state

The was_negotiated check is unnecessary because reset_pending_splice_state
only runs when funding_negotiation is present, meaning
on_tx_signatures_exchange hasn't been called yet. Since the feerate is
only recorded in last_funding_feerate_sat_per_1000_weight during
on_tx_signatures_exchange, the current round's feerate can never match
it. So the contribution can always be unconditionally popped.

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

Rename SplicePending and SpliceFailed events

Rename Event::SplicePending to Event::SpliceNegotiated and
Event::SpliceFailed to Event::SpliceNegotiationFailed. These names
better reflect the per-round semantics: each negotiation attempt
resolves to one of these two outcomes, independent of the overall
splice lifecycle.

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

Emit DiscardFunding before SpliceFailed

Reverse the event ordering at all emission sites so that
Event::DiscardFunding is emitted before Event::SpliceFailed. If the
user retries the splice when handling SpliceFailed, the contributed
inputs would still be locked. A subsequent DiscardFunding would then
incorrectly unlock inputs that are now committed to the new attempt.
Emitting DiscardFunding first avoids this by ensuring inputs are
unlocked before any retry occurs.

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

Add FundingContribution to SpliceFailed event

Replace the abandoned_funding_txo and channel_type fields on
Event::SpliceFailed with an Option<FundingContribution> from the failed
round. Users can feed this back to funding_contributed to retry or use
it to inform a fresh attempt via splice_channel.

Also makes FundingContribution::feerate() public so users can inspect
the feerate when deciding whether to retry or bump.

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

Add NegotiationFailureReason to SpliceFailed event

Each splice negotiation round can fail for different reasons, but
Event::SpliceFailed previously gave no indication of what went wrong.
Add a NegotiationFailureReason enum so users can distinguish failures
and take appropriate action (e.g., retry with a higher feerate vs.
wait for the channel to become usable).

The reason is determined at each channelmanager emission site based on
context rather than threaded through channel.rs internals, since the
channelmanager knows the triggering context (disconnect, tx_abort,
shutdown, etc.) while channel.rs functions like abandon_quiescent_action
handle both splice and non-splice quiescent actions.

The one exception is QuiescentError::FailSplice, which carries a reason
alongside the SpliceFundingFailed. This is appropriate because FailSplice
is already splice-specific, and the channel.rs code that constructs it
(e.g., contribution validation, feerate checks) knows the specific
failure cause. A with_negotiation_failure_reason method on QuiescentError
allows callers to override the default when needed.

Older serializations that lack the reason field default to Unknown via
default_value in deserialization. The persistence reload path uses
PeerDisconnected since a reload implies the peer connection was lost.

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

Attempt to unblock blocked monitor updates on startup

When we make an MPP claim we push RAA blockers for each chanel to
ensure we don't allow any single channel to make too much progress
until all channels have the preimage durably on disk. We don't have
to store those RAA blockers on disk in the ChannelManager as
there's no point - if the ChannelManager gets to disk with the RAA
blockers it also brought with it the pending ChannelMonitorUpdates
that contain the preimages and will now be replayed, ensuring the
preimage makes it to all ChannelMonitors.

However, just because those RAA blockers dissapear on reload
doesn't mean the implications of them does too - if a later
ChannelMonitorUpdate was blocked in the channel we don't have logic
to unblock it on startup.

Here we add such logic, simply attempting to unblock all blocked
`ChannelMonitorUpdate`s that existed on startup.

Code written by Claude.

Fixes #4518

Expose additional FundingContribution accessors

Add public getters for `estimated_fee`, `inputs`, and `max_feerate`, and
elevate `feerate` from `pub(super)` to `pub`. Together with the existing
`value_added`, `outputs`, and `change_output`, this gives downstream
consumers of `TransactionType::Splice` (notably LDK Node, which updates
`PaymentDetails` from the broadcast callback) the data they need
without reaching into the raw transaction.

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

Expose interactive funding candidates on broadcast

Replace TransactionType::Splice with TransactionType::InteractiveFunding
so downstream consumers can update their own state tracking from the
broadcast callback. The local contribution data isn't recoverable from
the on-chain transaction, so the broadcast must surface it directly.
Each candidate carries the participating channels and their local
contributions; the broadcast lists every negotiated candidate — original
first, then each RBF replacement — letting downstream reconcile any
historical txid, not just the immediate predecessor.

The new variant is structured to be forward-compatible with batches and
V2 (dual-funded) channel establishment, neither of which is implemented
today. The new types are Writeable/Readable so downstream can persist
them directly.

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

Roll back composite sub-handlers when one rejects `peer_connected`

`composite_custom_message_handler!` expanded `peer_connected` to call
every sub-handler and remember the last error, but never undo the
already-succeeded ones. The `CustomMessageHandler::peer_connected`
contract is that `PeerManager` will *not* invoke `peer_disconnected`
when `peer_connected` returns `Err` — so any per-peer state allocated
by an earlier sub-handler that returned `Ok` was leaked permanently
once a later sub-handler returned `Err`.

A peer who can elicit `Err` from any sub-handler in the composite
(feature-bit gate, banlist, etc.) could repeatedly reconnect to grow
that leaked state without bound (slow resource DoS), and "currently
connected" predicates in the leaking sub-handler would lie about
peers that were actually rejected.

Mirror the rollback pattern `PeerManager` already uses for the four
built-in handlers (`peer_handler.rs:2149-2188`): record each
sub-handler's `peer_connected` result, and if any returned `Err`,
call `peer_disconnected` on the ones that succeeded before
propagating the failure.

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

Drop local chacha20poly1305 implementation

Complete the migration process from the local chacha20poly1305 to the
rust-bitcoin chacha20-poly1305 crate.

Replace local ChaCha20-Poly1305 with external crate

Migrates ChaCha20-Poly1305 encryption from the local crypto
module to rust-bitcoin's `chacha20-poly1305` crate.

Integrated the crate across all modules (Router,
PeerStorage, Onion Utils, etc.).

Add the chacha20_poly1305_fuzz flag to fuzz config to after
implementing the fuzz logic upstream.

Release `OutputSweeper::pending_sweep` flag on future drop

`regenerate_and_broadcast_spend_if_necessary` used `pending_sweep:
AtomicBool` as a single-runner gate but only cleared the flag with an
unconditional `store(false)` *after* the inner future resolved. If the
caller's future was dropped while the inner await was `Pending` —
which `tokio::time::timeout`, `futures::select!`, manual
`JoinHandle::abort`, etc. all do — the reset never ran, leaving the
flag stuck `true` and every subsequent call to the function
short-circuiting with `Ok(())`.

Because `OutputSweeper` is what claims `SpendableOutputDescriptor`s
back to the user's wallet after channel closure (including HTLC
outputs with time-bounded recovery deadlines), a stuck flag turns
into fund-loss exposure: time-sensitive HTLC sweeps simply stop
happening, while every other code path keeps queueing new outputs to
sweep, until the process is restarted.

Replace the trailing `store(false)` with an RAII `PendingSweepGuard`
whose `Drop` impl always releases the flag — covering normal return,
error, and cancellation alike.

Co-Authored-By: HAL 9000

Validate Esplora merkle proof against the block header's merkle root

`EsploraSyncClient::get_confirmed_tx` parsed the SPV proof returned by
the Esplora server but threw away the security check: the merkle root
computed by `PartialMerkleTree::extract_matches` was discarded
(`let _ = …`), and only the leaf-equality check (`matches[0] == txid`)
remained. Anyone can construct a single-leaf partial tree advertising
an arbitrary txid via `PartialMerkleTree::from_txids(&[txid], &[true])`,
so this gate was vacuous.

A malicious or compromised Esplora server could therefore convince
`EsploraSyncClient` that any transaction was confirmed in any block by
returning `MerkleBlock { header: real_header, txn: forged_partial_tree }`,
causing LDK to feed a synthesized `ConfirmedTx` into `Confirm`
implementations such as `ChannelManager` / `ChainMonitor`. From there,
the channel-funding / closing / HTLC flows would treat the transaction
as confirmed at an attacker-chosen height, with consequences ranging
from premature state transitions to force-close races.

Capture the merkle root returned by `extract_matches` and require it
to equal `block_header.merkle_root`, matching the validation the
Electrum sibling already performs via `validate_merkle_proof`.

Co-Authored-By: HAL 9000

Fix `StaticInvoice::is_offer_expired` to check the offer's expiry

The std-only `StaticInvoice::is_offer_expired` accessor delegated to
`InvoiceContents::is_expired`, which compares `created_at +
relative_expiry` against the current time — that is the *invoice*'s
expiry, not the offer's. The `_no_std` sibling and `flow.rs::
enqueue_static_invoice` already treat the two as distinct checks.

A payer or forwarder using the std API to decide whether to honor a
static invoice would therefore get the wrong answer in either
direction: forwarding offers the issuer has already retired (when the
invoice is still fresh), or refusing offers that are still valid (when
the invoice has aged past its `relative_expiry` but the offer itself
has no `absolute_expiry`).

Route the std accessor through `InvoiceContents::is_offer_expired` so
both the std and no-std paths consult the offer's expiry.

Co-Authored-By: HAL 9000