rust-lightning

Add test for monitor update after funding spend

Add a regression test that reproduces the panic when a commitment_signed
is processed after the counterparty commitment transaction has confirmed.
The ChannelMonitor's no_further_updates_allowed() returns true, causing
update_monitor to fail, which ChainMonitor overrides to InProgress. A
subsequent preimage claim returning Completed then triggers the
per-channel assertion that Completed must not follow InProgress.

AI tools were used in preparing this commit.

Replace dual-sync-async persistence panic with Watch contract

Commit 0760f99 ("Disallow dual-sync-async persistence without
restarting") added a panic in non-test builds when a Persist
implementation returns both Completed and InProgress from the same
ChannelManager instance. However, this check runs against the status
that ChainMonitor returns to ChannelManager, not the raw Persist
result. When ChannelMonitor::update_monitor fails (e.g. a
counterparty commitment_signed arrives after a funding spend
confirms), ChainMonitor persists the full monitor successfully but
overrides the return value to InProgress. If the user's Persist impl
only ever returns Completed, this override triggers a false
mode-mismatch panic.

This replaces the panic with a per-channel contract at the Watch
trait level: a Watch implementation must not return Completed for a
channel update while prior InProgress updates are still pending.
Switching from Completed to InProgress is always allowed, but
switching back is impractical because the Watch implementation cannot
observe when ChannelManager has finished processing a
MonitorEvent::Completed. The documentation on
ChannelMonitorUpdateStatus is updated to describe these rules.

The mode tracking and panic checks from 0760f99 are removed and
replaced with a panic that validates the new contract directly on
the in-flight update state. Legacy tests that switch the persister
between modes mid-flight can opt out via
Node::disable_monitor_completeness_assertion().

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

ci: fix OOM in artifact upload and update actions to v4

fuzz: handle missing SendTx* message events in chanmon_consistency

Add handlers for SendTxInitRbf, SendTxAckRbf, SendTxRemoveInput, and
SendTxRemoveOutput in the chanmon_consistency fuzz target. These
variants were reachable but not matched, causing panics on the wildcard
arm ("Unhandled message event").

SendTxInitRbf became reachable after commit 5873660a0 added splicing
support without updating the fuzz target's message delivery logic.

AI tools were used in preparing this commit.

Assign random ids to monitor events

Currently, the resolution of HTLCs (and decisions on when HTLCs can be
forwarded) is the responsibility of Channel objects (a part of ChannelManager)
until the channel is closed, and then the ChannelMonitor thereafter. This leads
to some complexity around race conditions for HTLCs right around channel
closure. Additionally, there is lots of complexity reconstructing the state of
all HTLCs in the ChannelManager deserialization/loading logic.

Instead, we want to do all resolution in ChannelMonitors (in response to
ChannelMonitorUpdates) and pass them back to ChannelManager in the form of
MonitorEvents (similar to how HTLCs are resolved after channels are closed). In
order to have reliable resolution, we'll need to keep MonitorEvents around in
the ChannelMonitor until the ChannelManager has finished processing them. This
simplifies things - on restart instead of examining the set of HTLCs in
monitors we can simply replay all the pending MonitorEvents.

To allow the ChannelManager to ack specific monitor events once they are
resolved, here we give each MonitorEvent a corresponding unique id. It's
implemented in such a way that we can delete legacy monitor event serialization
in future LDK versions when persistent monitor events are enabled by default.

Fail HTLCs from late counterparty commitment updates after funding spend

When a ChannelMonitorUpdate containing a new counterparty commitment is
dispatched (e.g. via deferred writes) before a channel force-closes but
only applied to the in-memory monitor after the commitment transaction
has already confirmed on-chain, the outbound HTLCs in that update must
be failed back.

Add fail_htlcs_from_update_after_funding_spend to ChannelMonitorImpl
which detects this race condition during update_monitor. When a
LatestCounterpartyCommitmentTXInfo or LatestCounterpartyCommitment
update is applied and the funding output has already been spent, the
function iterates all outbound HTLCs from the update and creates
OnchainEvent::HTLCUpdate entries for those that need to be failed back.
These entries mature after ANTI_REORG_DELAY blocks, giving time for the
peer to potentially broadcast the newer commitment.

HTLCs that appear as non-dust outputs in the confirmed commitment
(whether counterparty or holder) are skipped, as they will be resolved
on-chain via the normal HTLC timeout/success path. HTLCs already
fulfilled by the counterparty (tracked in counterparty_fulfilled_htlcs)
are also skipped. Duplicate failures from previously-known counterparty
commitments are handled gracefully by the ChannelManager.

AI tools were used in preparing this commit.

Implement deferred monitor write queueing and flushing

Replace the unimplemented!() stubs with a full deferred write
implementation. When ChainMonitor has deferred=true, Watch trait
operations queue PendingMonitorOp entries instead of executing
immediately. A new flush() method drains the queue and forwards
operations to the internal watch/update methods, calling
channel_monitor_updated on Completed status.

The BackgroundProcessor is updated to capture pending_operation_count
before persisting the ChannelManager, then flush that many writes
afterward - ensuring monitor writes happen in the correct order
relative to manager persistence.

Key changes:
- Add PendingMonitorOp enum and pending_ops queue to ChainMonitor
- Implement flush() and pending_operation_count() public methods
- Integrate flush calls in BackgroundProcessor (both sync and async)
- Add TestChainMonitor::new_deferred, flush helpers, and auto-flush
in release_pending_monitor_events for test compatibility
- Add create_node_cfgs_deferred for deferred-mode test networks
- Add unit tests for queue/flush mechanics and full payment flow

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

Clarify that each pending monitor update ID must be marked complete

The previous wording implied that persisting a full ChannelMonitor
would automatically resolve all pending updates. Reword to make clear
that each update ID still needs to be individually marked complete via
channel_monitor_updated, even after a full monitor persistence.

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

Extract shared dummy_monitor helper in channelmonitor.rs

Extract the ChannelMonitor construction boilerplate that was
duplicated across channelmonitor test functions into a reusable
#[cfg(test)] pub(super) dummy_monitor helper, generic over the
signer type.

AI tools were used in preparing this commit.

Extract watch_channel_internal/update_channel_internal from Watch impl

Pure refactor: move the bodies of Watch::watch_channel and
Watch::update_channel into methods on ChainMonitor, and have
the Watch trait methods delegate to them. This prepares for adding
deferred mode where the Watch methods will conditionally queue
operations instead of executing them immediately.

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

Add deferred bool to ChainMonitor

Add a `deferred` parameter to `ChainMonitor::new` and
`ChainMonitor::new_async_beta`. When set to true, the Watch trait
methods (watch_channel and update_channel) will unimplemented!() for
now. All existing callers pass false to preserve current behavior.

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

Validate all common fields in LSPS1 `is_valid` order check

Add missing cross-validation of `LSPS1OrderParams` against
`LSPS1Options` as required by bLIP-51:

- Check `required_channel_confirmations` >= `min_required_channel_confirmations`
- Check `funding_confirms_within_blocks` >= `min_funding_confirms_within_blocks`
- Check total channel balance (`lsp_balance_sat` + `client_balance_sat`)
is within [`min_channel_balance_sat`, `max_channel_balance_sat`],
using `checked_add` to guard against overflow

Co-Authored-By: HAL 9000

Reject clients if request registration failed (e.g., duplicative Id)

Signed-off-by: Elias Rohrer <dev@tnull.de>

Limit pending requests and peers in LSPS1 service

Add per-peer and global rate limiting to `LSPS1ServiceHandler` to
prevent resource exhaustion, mirroring the existing LSPS2 pattern.

Introduce `MAX_PENDING_REQUESTS_PER_PEER` (10),
`MAX_TOTAL_PENDING_REQUESTS` (1000), and `MAX_TOTAL_PEERS` (100000)
constants and enforce them in `handle_create_order_request`. Rejected
requests receive a `CreateOrderError` with
`LSPS0_CLIENT_REJECTED_ERROR_CODE`. A `total_pending_requests` atomic
counter tracks the global count, and a `verify_pending_request_counter`
debug assertion ensures it stays in sync.

Co-Authored-By: HAL 9000

Reset `persistence_in_flight` counter on error in LSPS1/LSPS2

Previously, if any `.await?` in the persist loop returned an error, the
`?` would propagate out of `persist()` before reaching the `fetch_sub`
at the end of the loop. This left the counter permanently > 0, causing
all subsequent `persist()` calls to early-return and effectively
disabling persistence for the lifetime of the handler.

Fix this by extracting the loop into `do_persist()` and unconditionally
resetting the counter via `store(0, Release)` in the outer `persist()`
after `do_persist()` returns, regardless of success or failure.

Co-Authored-By: HAL 9000

Add `onchain_payment_required` method

We previously had no way to reject requests in case the LSP requires
onchain payment while the client not providing
`refund_onchain_address`. Here we add a method allowing to do so.

Drop unused `LSPS1ServiceEvent::Refund` event

Turns out this was another variant we didn't actually use anywhere. So
we're dropping it.

Drop unused `LSPS1OnchainPayment` type

Add integration tests for LSPS1 order state transition API

Add two new integration tests to cover the new public API methods:

- `lsps1_order_state_transitions`: Tests the full flow of
`order_payment_received` followed by `order_channel_opened`,
verifying that payment states are updated correctly and channel
info is returned after the channel is opened.

- `lsps1_order_failed_and_refunded`: Tests the `order_failed_and_refunded`
method, verifying that payment states are set to Refunded.

Co-Authored-By: HAL 9000

Add integration test for expired order pruning

Add `lsps1_expired_orders_are_pruned_and_not_persisted` test that verifies:

- Orders with expired payment details (expires_at in the past) are
accessible before persist() is called
- After persist() is called, expired orders in ExpectingPayment state
are pruned and no longer accessible
- Pruned orders are not recovered after restart, confirming that
the pruning also removes the persisted state

Co-Authored-By: HAL 9000

Add `Hold` payment state per bLIP-51 spec

The bLIP-51 specification defines a `HOLD` intermediate payment state:
- `EXPECT_PAYMENT` -> `HOLD` -> `PAID` (success path)
- `EXPECT_PAYMENT` -> `REFUNDED` (failure before payment)
- `HOLD` -> `REFUNDED` (failure after payment received)

This commit adds the `Hold` variant to `LSPS1PaymentState` and updates
the state machine transitions:

- `payment_received()` now sets payment state to `Hold` (not `Paid`)
- `channel_opened()` transitions payment state from `Hold` to `Paid`
- Tests updated to verify the correct state at each transition

This allows LSPs to properly communicate when a payment has been
received but the channel has not yet been opened (e.g., Lightning
HTLC held, or on-chain tx detected but channel funding not published).

Co-Authored-By: HAL 9000

Refactor `ChannelOrder` to use `ChannelOrderState` state machine

This refactors `ChannelOrder` to use an internal state machine enum
`ChannelOrderState` that:
- Encapsulates state-specific data in variants (e.g., `channel_info`
only available in `CompletedAndChannelOpened`)
- Provides type-safe state transitions
- Replaces the generic `update_order_status` API with specific
transition methods: `order_payment_received`, `order_channel_opened`,
and `order_failed_and_refunded`

The state machine has four states:
- `ExpectingPayment`: Initial state, awaiting payment
- `OrderPaid`: Payment received, awaiting channel open
- `CompletedAndChannelOpened`: Terminal state with channel info
- `FailedAndRefunded`: Terminal state for failed/refunded orders

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

Add some checks on provided payment details

As per spec, we check that the user provides at least one payment detail
*and* that they don't provide onchain payment details if
`refund_onchain_address` is unset.

Signed-off-by: Elias Rohrer <dev@tnull.de>

Add test case asserting `LSPS1ServiceState` is persisted across restarts

Co-authored by Claude AI

Add test case for `invalid_token_provided` flow

We test the just-added API.

Co-authored by Claude AI