rust-lightning

Consider prior contributions when filtering unique inputs/outputs

When funding_contributed is called while a splice negotiation is already
in progress, unique contributions are computed to determine what to
return via FailSplice or DiscardFunding. Without considering negotiated
candidates stored in PendingFunding::contributions, UTXOs locked in
earlier candidates could be incorrectly returned as reclaimable.

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

Filter prior contributions from SpliceFundingFailed events

SpliceFundingFailed events return contributed inputs and outputs to the
user so they can unlock the associated UTXOs. When an RBF attempt is
in progress, inputs/outputs already consumed by prior contributions
must be excluded to avoid the user prematurely unlocking UTXOs that
are still needed by the active funding negotiation.

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

Handle FeeRateAdjustmentError variants in splice acceptor path

Replace the generic error handling in splice_init and tx_init_rbf with
explicit matching on FeeRateAdjustmentError variants:

- FeeRateTooLow: initiator's feerate is below our minimum. Proceed
without contribution and preserve QuiescentAction for an RBF retry at
our preferred feerate.
- FeeRateTooHigh: initiator's feerate exceeds our maximum and would
consume too much of our change output. Reject the splice with
WarnAndDisconnect.
- FeeBufferInsufficient: our fee buffer can't cover the acceptor's
estimated fee at this feerate. Proceed without contribution.

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

Preserve our funding contribution across counterparty RBF attempts

When the counterparty initiates an RBF and we have no new contribution
queued via QuiescentAction, we must re-use our prior contribution so
that our splice is not lost. Track contributions in a new field on
PendingFunding so the last entry can be re-used in this scenario.

Each entry stores the feerate-adjusted version because that reflects
what was actually negotiated and allows correct feerate re-adjustment
on subsequent RBFs. Only explicitly provided contributions (from a
QuiescentAction) append to the vec. Re-used contributions are replaced
in-place with the version adjusted for the new feerate so they remain
accurate for further RBF rounds, without growing the vec.

Add test_splice_rbf_acceptor_recontributes to verify that when the
counterparty initiates an RBF and we have no new QuiescentAction
queued, our prior contribution is automatically re-used so the splice
is preserved.

Add test_splice_rbf_recontributes_feerate_too_high to verify that when
the counterparty RBFs at a feerate too high for our prior contribution
to cover, the RBF is rejected rather than proceeding without our
contribution.

Add test for sequential RBF splice attempts

Add test_splice_rbf_sequential that exercises three consecutive RBF
rounds on the same splice (initial → RBF #1 → RBF #2) to verify:
- Each round requires the 25/24 feerate increase (253 → 264 → 275)
- DiscardFunding events reference the correct funding txid from each
replaced candidate
- The final RBF splice can be mined and splice_locked successfully

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

Allow acceptor contribution to RBF splice via tx_init_rbf

Previously, the tx_init_rbf acceptor always contributed zero to the RBF
transaction. This is incorrect when both parties try to RBF
simultaneously and one loses the quiescence tie-breaker — the loser
becomes the acceptor but still has a pending QuiescentAction::Splice
with inputs/outputs that should be included in the RBF transaction.

Consume the acceptor's QuiescentAction in the tx_init_rbf handler, just
as is already done in the splice_init handler, and report the
contribution in the TxAckRbf response.

Send tx_init_rbf instead of splice_init when a splice is pending

When the quiescence initiator has a pending splice and enters the stfu
handler with a QuiescentAction::Splice, send tx_init_rbf to bump the
existing splice's feerate rather than starting a new splice_init.

This reuses the same QuiescentAction::Splice variant for both initial
splices and RBF attempts -- the stfu handler distinguishes them by
checking whether pending_splice already exists.

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

Handle tx_ack_rbf on the initiator side

After sending tx_init_rbf, the initiator receives tx_ack_rbf from the
acceptor. Implement the handler to validate the response and begin
interactive transaction construction for the RBF funding transaction.

Only clear the interactive signing session in `reset_pending_splice_state`
when the current funding negotiation is in `AwaitingSignatures`. When an
earlier round completed signing and a later RBF round is in `AwaitingAck`
or `ConstructingTransaction`, the session belongs to the prior round and
must be preserved. Otherwise, disconnecting mid-RBF would destroy the
completed prior round's signing session and fire a false debug assertion.

Update test_splice_rbf_acceptor_basic to exercise the full initiator
flow: rbf_channel → funding_contributed → STFU exchange → tx_init_rbf →
tx_ack_rbf → interactive TX → signing → mining → splice_locked. This
replaces the previous test that manually constructed tx_init_rbf.

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

Allow multiple RBF splice candidates in channel monitor

The channel monitor previously rejected any new pending funding when one
already existed. This prevented adding RBF candidates for a pending
splice since each candidate needs its own pending funding entry.

Relax the check to only reject new pending funding when its splice
parent differs from existing entries, allowing multiple RBF candidates
that compete to confirm the same splice.

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

Add rbf_channel API for initiating splice RBF

Expose ChannelManager::rbf_channel as the entry point for bumping the
feerate of a pending splice funding transaction. Like splice_channel,
it returns a FundingTemplate to be completed and passed to
funding_contributed.

Validates that a pending splice exists with at least one negotiated
candidate, no active funding negotiation, and that the new feerate
satisfies the 25/24 increase rule required by the spec.

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

Accept tx_init_rbf for pending splice transactions

When a splice funding transaction has been negotiated but not yet
confirmed, either party may initiate RBF to bump the feerate. This
enables the acceptor to handle such requests, allowing continued
progress toward on-chain confirmation of splices in rising fee
environments.

Only the acceptor side is implemented; the acceptor does not contribute
funds beyond the shared funding input. The initiator side (sending
tx_init_rbf and handling tx_ack_rbf) is left for a follow-up.

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

Rustfmt reorg_tests.rs

Fix claude-code-action CI failures

Use pull_request_target to ensure secrets are available, and pass
github_token explicitly to avoid the OIDC token exchange flow.
See https://github.com/anthropics/claude-code-action/issues/649

AI tools were used in preparing this commit.

Emit SpliceFailed for acceptor contributions

The maybe_create_splice_funding_failed! macro only emitted SpliceFailed
and DiscardFunding events for the splice initiator. When an acceptor
contributed inputs/outputs and the negotiation failed (e.g., disconnect),
their contributions were silently discarded with no event notification,
preventing the acceptor from reclaiming its UTXOs.

Replace the is_initiator() filter with a post-hoc check on whether there
are contributions to discard. The initiator always gets events, the
acceptor gets events when it has contributions, and acceptors without
contributions get no events (nothing to discard).

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

Add claude code reviewing

We can tweak the prompt as we get experience, for now its just the
one copied
https://github.com/anthropics/claude-code-action/blob/main/docs/solutions.md

Tell claude to be DRY

Clean up redundant steps in ci-tests-workspace.sh

Replace the per-member cargo check + cargo doc loop with a single
`cargo doc --workspace` call. The per-member cargo check is redundant
with the workspace-level cargo check already run earlier in the script.
Also remove the separate `cargo test -p lightning-custom-message` which
is covered by the workspace-level cargo test.

Fix stale "except lightning-transaction-sync" echo messages, as it has
been a workspace member for a while now.

AI tools were used in preparing this commit.

Reject offer_amount of 0 as invalid per BOLT 12

Per the spec clarification in https://github.com/lightning/bolts/pull/1316:
- Writers MUST set offer_amount greater than zero when present
- Readers MUST NOT respond to offers where offer_amount is zero

Reject amount_msats(0) in the builder with InvalidAmount, and reject
parsed offers with amount=0 (with or without currency) during TLV
deserialization.

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

ln: handle trampoline claims on restart

This commit uses the existing outbound payment claims replay logic
to restore trampoline claims. If any single previous hop in a htlc
source with multiple previous hops requires claim, we represent this
with a single outbound claimed htlc because we assume that *all* of
the incoming htlcs are represented in the source, and will be
appropriately claimed (rather than submitting multiple claims, which
will end up being duplicates of each other). This is the case for
trampoline payments, where the htlc_source stores all previous hops.

ln: no longer support claims with missing counterparty_node_id

Move handling of payment replay into its own function and deprecate
old code that handled missing counterparty_node_id. By the time we
reach 0.3 we should have this data present.

ln: add channel monitor recovery for trampoline forwards

Implement channel monitor recovery for trampoline forwards
iterating over all hop data and updating pending forwards.

ln/refactor: extract channelmonitor recovery to external helper

Move recovery logic for `HTLCSource::PreviousHopData` into
`channel_monitor_recovery_internal` to prepare for trampoline
forward reuse.

Co-authored-by: Arik Sosman <git@arik.io>
Co-authored-by: Maurice Poirrier <mpch@hey.com>

ln: add trampoline routing failure handling

Implement failure propagation for `HTLCSource::TrampolineForward`
by iterating through previous hop data and failing each HTLC with
`TemporaryTrampolineFailure`.

Note that testing should be implemented when trampoline forward is
completed.

Co-authored-by: Arik Sosman <git@arik.io>
Co-authored-by: Maurice Poirrier <mpch@hey.com>

ln/refactor: add blinded forwarding failure helper function

We'll want this extracted when we need to handle trampoline and regular
forwards.

Co-authored-by: Arik Sosman <git@arik.io>
Co-authored-by: Maurice Poirrier <mpch@hey.com>

ln: add trampoline routing payment claiming

Implement payment claiming for `HTLCSource::TrampolineForward` by
iterating through previous hop data and claiming funds for each
HTLC. Similar to regular forwards, we need to block the outbound
channel's RAA on the inbound monitor persisting preimages received.
If we have multiple inbound HTLCs for trampoline, we'll add multiple
blockers so that we don't proceed until each inbound HTLC is claimable.

Co-authored-by: Arik Sosman <git@arik.io>
Co-authored-by: Maurice Poirrier <mpch@hey.com>

ln/refactor: pass closure to create PaymentForwarded event

When we introduce trampoline forwards, we're going to want to provide
two external pieces of information to create events:
- When to emit an event: we only want to emit one trampoline event, even
when we have multiple incoming htlcs. We need to make multiple calls
to claim_funds_from_htlc_forward_hop to claim each individual htlc,
which are not aware of each other, so we rely on the caller's closure
to decide when to emit Some or None.
- Forwarding fees: we will not be able to calculate the total fee for
a trampoline forward when an individual outgoing htlcs is fulfilled,
because there may be other outgoing htlcs that are not accounted for
(we only get the htlc_claim_value_msat for the single htlc that was
just fulfilled). In future, we'll be able to provide the total fee
from the channelmanager's top level view.