rust-lightning

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>

Drop `lsps1_service` cfg flag

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

Read persisted LSPS1ServiceHandler state on startup

.. we read the persisted state in `LiquidityManager::new`

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

Implement `LSPS1ServiceHandler` persistence and state pruning

We follow the model already employed in LSPS2/LSPS5 and implement
state pruning and persistence for `LSPS1ServiceHandler` state.

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

Add serialization logic for LSPS1 `PeerState` types

We add the serializations for all types that will be persisted as part
of the `PeerState`.

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.

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

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.

Actually remember the order state in `ChannelOrder`

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

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.

Drop `OutboundCRChannel`

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

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

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>

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.

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>