rust-lightning

Simplify calculation of the biggest HTLC value that can be sent next

This commit has no functional changes.

Add total-MPP-value storage in pending payments

In some uses of LDK we need the ability to send HTLCs for only a
portion of some larger MPP payment. This allows payers to make
single payments which spend funds from multiple wallets, which may
be important for ecash wallets holding funds in multiple mints or
graduated wallets which hold funds across a trusted wallet and a
self-custodial wallet.

In the previous commits we moved the total-MPP-value we set in
onions from being manually passed through onion-building to passing
it via `RecipientOnionFields`. This introduced a subtle bug, though
- payments which are retried will get a fresh
`RecipientOnionFields` built from the data in
`PendingOutboundPayment::Retryable`, losing any custom
total-MPP-value settings and causing retries to fail.

Here we fix this by storing the total-MPP-value directly in
`PendingOutboundPayment::Retryable`.

Add a pending changelog entry to note new backwards incompat

Require `RecipientOnionFields` in the claimable HTLC pipeline

We added `RecipientOnionFields` in the
`ClaimablePayment`/`ClaimingPayment` structs in 0.0.115/0.0.124,
always writing them for new HTLCs. As of 0.1, we do not support
upgrading from 0.0.123 or earlier with pending HTLCs to forward or
claim. Thus, we already don't support upgrading in cases where no
`RecipientOnionFields` is set and we can thus go ahead and mark it
as non-`Option`al.

Further, there's some super ancient upgrade logic in
`ChannelManager` deserialization we can remove at the same time.

Allow BOLT 11 payments to be a part of a larger MPP payment

In some uses of LDK we need the ability to send HTLCs for only a
portion of some larger MPP payment. This allows payers to make
single payments which spend funds from multiple wallets, which may
be important for ecash wallets holding funds in multiple mints or
graduated wallets which hold funds across a trusted wallet and a
self-custodial wallet.

In the previous few commits we added support for making these
kinds of payments when using the payment methods which explicitly
accepted a `RecipientOnionFields`. Here we also add support for
such payments made via the `pay_for_bolt11_invoice` method,
utilizing the new `OptionalBolt11PaymentParams` to hide the
parameter from most calls.

Test mostly by Claude

Drop `total_msat` from individual `ClaimableHTLC`s

Now that we have `total_mpp_amount_msat` in the now-required
`RecipientOnionFields` in `ClaimablePayment`s, the `total_msat`
field in `ClaimableHTLC` is redundant. Given it was already
awkward that we stored it in *each` `ClaimableHTLC` despite it
being required to match in all of them, its good to drop it.

Include MPP payment amount in `RecipientOnionFields`

In some uses of LDK we need the ability to send HTLCs for only a
portion of some larger MPP payment. This allows payers to make
single payments which spend funds from multiple wallets, which may
be important for ecash wallets holding funds in multiple mints or
graduated wallets which hold funds across a trusted wallet and a
self-custodial wallet.

In order to allow for this, we need to separate the concept of the
payment amount from the onion MPP amount. Here we start this
process by adding a `total_mpp_amount_msat` field to
`RecipientOnionFields` (which is the appropriate place for a field
describing something in the recipient onion).

We currently always assert that it is equal to the existing fields,
but will relax this in the coming commit(s).

We also start including a payment preimage on probe attempts,
which appears to have been the intent of the code, but which did
not work correctly.

The bulk of the test updates were done by Claude.

Replace existing MPP-total args with `RecipientOnionFields`

In some uses of LDK we need the ability to send HTLCs for only a
portion of some larger MPP payment. This allows payers to make
single payments which spend funds from multiple wallets, which may
be important for ecash wallets holding funds in multiple mints or
graduated wallets which hold funds across a trusted wallet and a
self-custodial wallet.

In the previous commit we added a new field to
`RecipientOnionFields` to describe the total value of an MPP
payment. Here we start using this field when building onions,
dropping existing arguments to onion-building methods.

Validate the `Router` is meeting MPP and max-fee limitations given

When `OutboundPayments` calls the provided `Router` to fetch a
`Route` it passes a `RouteParameters` with a specific max-fee. Here
we validate that the `Route` returned sticks to the limits
provided, and also that it meets the MPP rules of not having any
single MPP part which can be removed while still meeting the
desired payment amount.

Add FilesystemStoreV2 with paginated listing support

Implements PaginatedKVStore traits with timestamp-prefixed filenames for
newest-first pagination and [empty] directory markers for consistent
namespace hierarchy.

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

prefactor: move FilesystemStore utilies into fs_store/common.rs

Ahead of adding the FilesystemStoreV2 we move some common utilies into a
shared file.

We also move the FilesystemStore into its own module.

Add PaginatedKVStore traits upstreamed from ldk-server

Allows for a paginated KV store for more efficient listing of keys so
you don't need to fetch all at once. Uses monotonic counter or timestamp
to track the order of keys and allow for pagination. The traits are
largely just copy-pasted from ldk-server.

Adds some basic tests that were generated using claude code.

Error api change- replaced io::error with string based format

Replace `get_payment_preimage_hash!` macro with direct function calls

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

Replace `get_closing_signed_broadcast!` macro with direct function calls

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

Replace `check_closed_broadcast!` macro with direct function calls

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

changes: switch to bitreq from chunked_transfer

we changed the http layer from the manual tcpstream client
implementation to bitreq, this change lets us rely on bitreq for
http request formatting, sockets, HTTP parsing, chunked bodies,
pooling, and async support instead of having to manually implement
them.

cargo.toml: we added bitreq 0.3 and updates the rest-client and
rpc-client feature wiring to depend on bitreq. A tokio feature is
also enabled to allow bitreq async support and pipelining.

http.rs: The old HttpEndpoint builder and all manual TCP/socket
timeout logic are dropped along with the manual GET/POST
construction and response parsing. The client API now uses base_url
and get/post return Result with a typed HttpClientError instead of
std::io::Result. HttpClientError splits transport failures
(bitreq::Error), non-2xx HTTP responses (HttpError), and response
decoding issues (std::io::Error).

rest.rs and rpc.rs: HttpEndpoint and the Mutex<Option<HttpClient>>
caching pattern are removed and both clients now own an HttpClient
directly using base_url. rpc.rs also adds RpcClientError so we can
represent HTTP failures, JSON-RPC errors from the server, and
malformed responses instead of just giving out std::io::Error.

convert.rs: it maps HttpClientError and RpcClientError into
BlockSourceError with this retry classification: transport errors
and HTTP 5xx are transient, HTTP 4xx and invalid data are
persistent, and RPC errors are treated as transient.

Avoid sending stfu for quiescent splice action while pending splice

We can't splice while one is already pending, so there's no point in
attempting to become quiescent.

Rework max commitment transaction balance debug assertions

These assertions made sure that our balance would never dip below the
reserve, and if they ever were, that the balance must only move towards
meeting the reserve. With splicing, this doesn't always work, as a node
that is not interested in contributing could end up below the reserve of
the post-splice channel. Therefore, we rework these assertions such that
we only keep track of the previous commitment transaction balance, and
compare against the current, ensuring that our balance only increases
when below the reserve.

Account for missing balance in channel reserve assertions for splices

When we create the post-splice `FundingScope`, the monotonicity debug
assertion trackers were initialized to the post-splice balance without
accounting for pending HTLCs or anchor costs. Since splices can have
in-flight HTLCs (unlike fresh channel opens), the first commitment
transaction's actual balance was lower than the initialized max, causing
the debug assertion in `ChannelContext::build_commitment_transaction` to
fire.

Note that we don't need to recompute the full post-splice balance here.
We can rely on the pre-splice `FundingScope`'s
`holder/counterparty_max_commitment_tx_output` instead since they're
already accounted for there.

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

Bind Channel::commitment_signed result in internal_commitment_signed

Inline unreachable debug assertion in MsgHandlErrInternal::no_such_peer

Avoid persisting ChannelManager on handle_tx_* errors

These errors will only ever affect our in-memory state, so there's no
need to persist the ChannelManager when we come across one. Note that
`tx_abort` is not included here because there is a possibility we force
close the channel, which we should persist.

Refactor channel splice operations into helper in chanmon_consistency

Add newline to fuzz log statements

This regressed at some point, making the logs harder to parse on a
failed test run.