rust-lightning

Verify Electrum transaction responses before use

Electrum confirmations must reject transaction_get responses whose body
does not compute the requested txid. Otherwise a malicious server can
substitute an unrelated transaction and provide matching Merkle data for
the substituted body.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe

Check Esplora Merkle leaf risk by base size

Esplora confirmation checks must use the non-witness transaction size
for the 64-byte Merkle leaf guard. Witness padding can otherwise raise
total_size without changing the serialization hashed into the txid and
Merkle tree.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe

Check Electrum Merkle leaf risk by base size

Electrum confirmation checks must reject transactions whose non-witness
serialization is 64 bytes, since txids and Merkle leaves are computed
from that serialization. Witness padding can otherwise move total_size
above 64 without removing the inner-node ambiguity.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe

Fix underflow in blinded path amt_to_forward

If we have a high (200%+) proportional fee as an intermediate blinded node
combined with a low inbound amount, we previously had some code that calculated
the outbound amount of the forward that would've underflowed. This would've
caused a panic in debug builds and caused us to relay a payment that should've
been rejected (due to being unable to cover our high fee) in release builds.

Reported by Project Loupe.

Clear duplicate monitor-pending RAA on signer resend

The `chanmon_consistency` fuzz target found a reconnect ordering where
`signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack`
could both describe the same owed `revoke_and_ack`.

The channel first received a `commitment_signed` whose monitor update
completed, but the signer could not provide the next point or secret,
leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer
`revoke_and_ack` freed holding-cell HTLCs and produced a held monitor
update. While that monitor update was still blocked,
`channel_reestablish` saw the peer one state behind and recorded
`monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending
`commitment_signed`, so the messages could be replayed once monitor
updating was restored.

If the signer unblocked before the held monitor update was released,
`signer_maybe_unblocked` generated and sent the already monitor-safe RAA
using `signer_pending_revoke_and_ack`. The monitor-pending flag was not
cleared at that point, so `monitor_updating_restored` later generated
the same RAA again when the held update completed. The peer had already
advanced after accepting the signer-unblocked RAA, so it rejected the
duplicate secret as not corresponding to its current pubkey and
force-closed.

Fix this by clearing `monitor_pending_revoke_and_ack` in the
signer-resume path only once a signer-pending RAA is actually being
returned.

Validate reserved fees on both commitments

The local and remote commitments may have different dust limits, which
can cause each commitment to have a different transaction fee.

Therefore when we reserve commitment transaction fees in
`get_available_balances`, we must ensure that we read the maximum of the
transaction fees on the local and the remote commitments. Otherwise, we
may have not reserved enough fees to ensure that our next proposed
channel state update is onside.

Break `get_available_balances` into small helper functions

Most diffs here are code moves.

Validate `next_splice_out_maximum_sat` on both commitments

Wilmer's fuzzing runs caught a case where an advertised splice out
maximum hit the debug assertions in `get_next_splice_out_maximum`.
These debug assertions ensure that any adverstised splice out maximum
passes the validation of splice contributions.

The core issue is that we only read the local commitment when
calculating the splice out maximum, but our splice validation requires
that any splice out maximum is covered by the minimum of the holder's
balances on the local and the remote commitments.

Therefore, if a HTLC is dust on the local commitment, but non-dust on
the remote commitment, and the holder is the funder of the channel, we
advertise a splice out maximum that is not covered by the holder's
balance on the remote commitment, and fails our validation of splice
contributions.

We now read both commitments when calculating the next splice out
maximum, which fixes this issue.

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.

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.

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.

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.

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.

Bump transaction sync dev dependencies

Bump electrum-client to v0.25

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.

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>

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>

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>

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>

Add `ChannelDetails::next_splice_out_maximum_sat`

Add `test_0reserve_splice`

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 `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.