rust-lightning

`LSPS1ServiceHandler`: Use `TimeProvider` when creating new orders

Since we by now have the `TimeProvider` trait, we might as well use it
in `LSPS1ServiceHandler` instead of requiring the user to provide a
`created_at` manually.

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

Drop `OutboundCRChannel`

The `OutboundChannel` construct simply wrapped `ChannelOrder` which we
can now simply use directly.

Respond to `GetOrder` requests from our saved state

Previously, we'd use an event to have the user check the order status
and then call back in. As we already track the order status, we here
change that to a model where we respond immediately based on our state
and have the user/LSP update that state whenever it detects a change
(e.g., a received payment, reorg, etc.). In the next commmit we will
add/modify the corresponding API methods to do so.

Actually remember the order state in `ChannelOrder`

We here remember and update the order state and channel details in
`ChannelOrder`

Require `supported_options` in `LSPS1ServiceConfig`

In the future we might want to inline the fields in `LSPS1ServiceConfig`
(especially once some are added that we'd want to always/never set for
the user), but for now we just make the `supported_options` field in
`LSPS1ServiceConfig` required, avoiding some dangerous `unwrap`s.

Use `PeerState::{register,remove}_request` instead of map access

We introduce two new methods on `PeerState` to avoid direct access to
the internal `pending_requests` map.

Use `PeerState::{get_order, has_active_orders}` instead of map

Previously, we'd directly access the internal `outbound_` map of
`PeerState`. Here we refactor the code to avoid this.

Note this also highlighted a bug in that we currently don't actually
update/persist the order state in `update_order_state`. We don't fix
this here, but just improve isolation for now, as all state update
behavior will be reworked later.

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

Drop Arik from SECURITY.md

Sadly Arik hasn't contributed to LDK in some time, so its time to
drop him 😭.

Support persistent 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
will simplify things - on restart instead of examining the set of HTLCs in
monitors we can simply replay all the pending MonitorEvents.

Here we complete work that was built on recent prior commits and actually start
re-providing monitor events on startup if they went un-acked during runtime. We
also remove a test that explicitly relied on the old non-persistent behavior.

Re-enable signer op for one channel at a time in chanmon_consistency

Node B has two channels: one with A and another with C. Re-enabling
signer ops only one channel at a time allows us to have them in
different states, which may be helpful for fuzzing coverage.

remove unnecessary clone in channel.rs

Move log channel_reestablish event when needed

Move feerate parameters from splice_channel/rbf_channel to FundingTemplate

The user doesn't choose the feerate at splice_channel/rbf_channel time —
they choose it when performing coin selection. Moving feerate to the
FundingTemplate::splice_* methods gives users more control and lets
rbf_channel expose the minimum RBF feerate (25/24 of previous) on the
template so users can choose an appropriate feerate.

splice_channel and rbf_channel no longer take min_feerate/max_feerate.
Instead, FundingTemplate gains a min_rbf_feerate() accessor that returns
the RBF floor when applicable (from negotiated candidates or in-progress
funding negotiations). The feerate parameters move to the splice_in_sync,
splice_out_sync, and splice_in_and_out_sync methods (and their async
variants), which validate that min_feerate >= min_rbf_feerate before
coin selection.

Fee estimation documentation moves from splice_channel/rbf_channel to
funding_contributed, where the contribution (and its feerate range)
is actually provided and the splice process begins.

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

Ack monitor events immediately

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
will simplify things - on restart instead of examining the set of HTLCs in
monitors we can simply replay all the pending MonitorEvents.

Here for the purposes of merging initial support for persistent monitor events,
we ack each immediately after it is received/handled by the ChannelManager,
which is equivalent to the behavior we had prior to monitor events becoming
persistent.

In upcoming work, we'll want to have much more special handling for HTLCUpdate
monitor events in particular -- e.g. for outbound payment claim events, we
should only ACK the monitor event when the PaymentSent event is processed,
until that point we want it to keep being provided back to us on startup.

All the other monitor events are trivial to ACK, since they don't need to be
re-processed on startup.

Drop claude-review github action and just run it externally instead

Refactor reorg_tests.rs to make formatting not span as many lines

Set max channel dust limit to 10,000 sats for all zero-fee-htlc-tx chans

This includes both keyed anchor channels, and 0FC channels.

The dust limit for HTLCs in such channels is independent of the
negotiated feerate, so a party may set a higher dust limit for such
channels.

Fixes #4225

Clamp our selected reserve to the counterparty's dust limit

In a subsequent commit, we will allow the counterparty's dust limit to
be greater than our `MIN_THEIR_CHANNEL_RESERVE_SATOSHIS`. Our selected
reserve must always be greater than their dust limit, so we set our
selected reserve to be equal to or greater than their dust limit.

Remove ChannelSignerType

We plan to have a single channel signer type going forward, so this is
unnecessary.

Remove musig2 crate

Taproot support is not planned we see an increase in demand for it by
users. The `musig2` crate is now owned by a third-party, and ultimately
won't be used by the production version of Taproot that we end up
releasing.

Remove TaprootChannelSigner

We plan to have a single channel signer type going forward, so this is
unnecessary.

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>

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>

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>

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>