rust-lightning

Add a `OfferFromHrn` type to wrap `Offer`s which came from HRNs

In a coming commit we'll provide users a different `ChannelManager`
method for sending to `Offer`s which were fetched by resolving an
HRN. Here, we first ad a wrapper type which can be used by HRN
resolution methods to nudge users towards calling the correct
payment method on `ChannelManager`.

Somewhat DRY `pay_for_offer_intern` callback method

Mention the `bitcoin-payment-instructions` crate in docs

Drop spurious limitations section on `pay_for_offer`

For some time we've automatically opened a connection to the
blinded path introduction point when we need to send a message we
generated. However, the "Limitations" section in
`ChannelManager::pay_for_offer` lists having a direct connection
as required for the payment to succeed, which is not true.

Instead, we simply remove the section from both `pay_for_offer` and
`pay_for_offer_from_human_readable_name`.

Miscellanous CI fixes

Add basic end-to-end splice tests

This adds a new test for both splice-in and splice-out in favor of
maintaining the existing test. Helpers have been added to DRY up a lot
of the logic necessary for driving the splice state machine forward.

Set current block locktime for coinbase in provide_anchor_reserves

This guarantees we get a unique txid when calling
`provide_anchor_reserves` successively as we're immediately mining (and
therefore advancing the chain) the transaction after creating it.

Switch TestWalletSource to use P2WPKH script

We plan to reuse it for dual-funding/splicing, and those require
standard SegWit inputs only.

Implement `KVStore` for `TestStore`

We implement the async `KVStore` trait for `TestStore`. This is mostly
useful in LDK Node tests, where we use `TestStore` and we now require
all stores to implement both variants.

Move `TestStore` logic to `_internal` methods

.. to be easier reusable by different trait implementations.

Remove redundant `startup_replay` arg to `claim_funds_internal`

`startup_replay` should always exactly mirror
`background_events_processed_since_startup`, so we should just use
that rather than having a dedicated argument for it.

Properly provide `PaymentPathSuccessful` event for replay claims

When a payment was sent and ultimately completed through an
on-chain HTLC claim which we discover during startup, we
deliberately break the payment tracking logic to keep it around
forever, declining to send a `PaymentPathSuccessful` event but
ensuring that we don't constantly replay the claim on every
startup.

However, now that we now have logic to complete a claim by marking
it as completed in a `ChannelMonitor` and not replaying information
about the claim on every startup. Thus, we no longer need to take
the conservative stance and can correctly replay claims now,
generating `PaymentPathSuccessful` events and allowing the state to
be removed.

Stop re-hydrating pending payments once they are fully resolved

`MonitorEvent`s aren't delivered to the `ChannelManager` in a
durable fasion - if the `ChannelManager` fetches the pending
`MonitorEvent`s, then the `ChannelMonitor` gets persisted (i.e. due
to a block update) then the node crashes, prior to persisting the
`ChannelManager` again, the `MonitorEvent` and its effects on the
`ChannelManger` will be lost. This isn't likely in a sync persist
environment, but in an async one this could be an issue.

Note that this is only an issue for closed channels -
`MonitorEvent`s only inform the `ChannelManager` that a channel is
closed (which the `ChannelManager` will learn on startup or when it
next tries to advance the channel state), that
`ChannelMonitorUpdate` writes completed (which the `ChannelManager`
will detect on startup), or that HTLCs resolved on-chain post
closure. Of the three, only the last is problematic to lose prior
to a reload.

In previous commits we ensured that HTLC resolutions which came to
`ChannelManager` via a `MonitorEvent` were replayed on startup if
the `MonitorEvent` was lost. However, in cases where the
`ChannelManager` was so stale that it didn't have the payment state
for an HTLC at all, we only re-add it in cases where
`ChannelMonitor::get_pending_or_resolved_outbound_htlcs` includes
it.

Because constantly re-adding a payment state and then failing it
would generate lots of noise for users on startup (not to mention
risk of confusing stale payment events for the latest state of a
payment when the `PaymentId` has been reused to retry a payment).
Thus, `get_pending_or_resolved_outbound_htlcs` does not include
state for HTLCs which were resolved on chain with a preimage or
HTLCs which were resolved on chain with a timeout after
`ANTI_REORG_DELAY` confirmations.

This critera matches the critera for generating a `MonitorEvent`,
and works great under the assumption that `MonitorEvent`s are
reliably delivered. However, if they are not, and our
`ChannelManager` is lost or substantially old (or, in a future
where we do not persist `ChannelManager` at all), we will not end
up seeing payment resolution events for an HTLC.

Instead, we really want to tell our `ChannelMonitor`s when the
resolution of an HTLC is complete. Note that we don't particularly
care about non-payment HTLCs, as there is no re-hydration of state
to do there - `ChannelManager` load ignores forwarded HTLCs coming
back from `get_pending_or_resolved_outbound_htlcs` as there's
nothing to do - we always attempt to replay the success/failure and
figure out if it mattered based on whether there was still an HTLC
to claim/fail.

Here we, finally, begin actually using the new
`ChannelMonitorUpdateStep::ReleasePaymentComplete` updates,
skipping re-hydration of pending payments once they have been fully
resolved through to a user `Event`.

Generate new `ReleasePaymentComplete` monitor updates

`MonitorEvent`s aren't delivered to the `ChannelManager` in a
durable fasion - if the `ChannelManager` fetches the pending
`MonitorEvent`s, then the `ChannelMonitor` gets persisted (i.e. due
to a block update) then the node crashes, prior to persisting the
`ChannelManager` again, the `MonitorEvent` and its effects on the
`ChannelManger` will be lost. This isn't likely in a sync persist
environment, but in an async one this could be an issue.

Note that this is only an issue for closed channels -
`MonitorEvent`s only inform the `ChannelManager` that a channel is
closed (which the `ChannelManager` will learn on startup or when it
next tries to advance the channel state), that
`ChannelMonitorUpdate` writes completed (which the `ChannelManager`
will detect on startup), or that HTLCs resolved on-chain post
closure. Of the three, only the last is problematic to lose prior
to a reload.

In previous commits we ensured that HTLC resolutions which came to
`ChannelManager` via a `MonitorEvent` were replayed on startup if
the `MonitorEvent` was lost. However, in cases where the
`ChannelManager` was so stale that it didn't have the payment state
for an HTLC at all, we only re-add it in cases where
`ChannelMonitor::get_pending_or_resolved_outbound_htlcs` includes
it.

Because constantly re-adding a payment state and then failing it
would generate lots of noise for users on startup (not to mention
risk of confusing stale payment events for the latest state of a
payment when the `PaymentId` has been reused to retry a payment).
Thus, `get_pending_or_resolved_outbound_htlcs` does not include
state for HTLCs which were resolved on chain with a preimage or
HTLCs which were resolved on chain with a timeout after
`ANTI_REORG_DELAY` confirmations.

This critera matches the critera for generating a `MonitorEvent`,
and works great under the assumption that `MonitorEvent`s are
reliably delivered. However, if they are not, and our
`ChannelManager` is lost or substantially old (or, in a future
where we do not persist `ChannelManager` at all), we will not end
up seeing payment resolution events for an HTLC.

Instead, we really want to tell our `ChannelMonitor`s when the
resolution of an HTLC is complete. Note that we don't particularly
care about non-payment HTLCs, as there is no re-hydration of state
to do there - `ChannelManager` load ignores forwarded HTLCs coming
back from `get_pending_or_resolved_outbound_htlcs` as there's
nothing to do - we always attempt to replay the success/failure and
figure out if it mattered based on whether there was still an HTLC
to claim/fail.

Here we begin generating the new
`ChannelMonitorUpdateStep::ReleasePaymentComplete` updates,
updating functional tests for the new `ChannelMonitorUpdate`s where
required.

Address ChannelState inconsistency throughout splicing

Once a channel open has become locked (i.e., we've entered
`ChannelState::ChannelReady`), the channel is intended to remain within
this state for the rest of its lifetime until shutdown. Previously, we
had assumed a channel being spliced would go through the `ChannelState`
lifecycle again starting from `NegotiatingFunding` but skipping
`AwaitingChannelReady`. This inconsistency departs from what we strive
to achieve with `ChannelState` and also makes the state of a channel
harder to reason about.

This commit ensures a channel undergoing a splice remains in
`ChannelReady`, clearing the quiescent flag once the negotiation is
complete. Dual funding is unaffected by this change as the channel is
being opened and we want to maintain the same `ChannelState` lifecycle.

Remove tx_signatures flags for interactive signing ChannelState

This commit addresses an overlap of state between
`InteractiveTxSigningSession` and `ChannelState::FundingNegotiated`. The
signing session already tracks whether both holder and counterparty
`tx_signatures` have been produced, so tracking the state duplicatively
at the `ChannelState` level is unnecessary.

Move interactive signing session into ChannelContext

Since the `InteractiveTxSigningSession` already tracks everything we
need, we can remove the duplicate interactive signing state tracking
within `ChannelState`.

Remove incomplete dual funding tests

The tests have become a bit painful to maintain, and they don't even
fully test the production code paths, so we opt to just remove them for
now. In the future, we plan to unify the dual funding code paths with
splicing.

Drop `Readable`/`Writeable` for `InFlightHtlcs`

Its not clear why this needs to be serialized at all (it should
generally always be generated live when needed), but its
serialization isn't forward-compatible, so really needs to be
dropped so that we can add additional field(s) to `InFlightHtlcs`.

Make `InFlightHtlcs` a named-field struct instead of a tuple struct

In the next commit we'll track blinded path in-flights in
`InFlightHtlcs` as well as unblinded hops, so here we convert
`InFlightHtlcs` to a named-field struct so that we can add more
fields to it with less confusion.

test(invoice): add new BOLT11 test vector to test public-key recovery high-S signature

refactor(invoice): align signature checks with BOLT11 semantics

Simplify `check_signature` logic to follow the BOLT11 rules discussed:

- If an `n` field is present, verify the signature against the included
pubkey using `secp256k1_ecdsa_verify`, which enforces normalized
low-S form.

- If no `n` field is present, rely on `secp256k1_ecdsa_recover` to
extract the pubkey. Recovery accepts both high-S and low-S signatures,
matching existing implementations (lnd, c-lightning).

This avoids redundant recovery+verify checks while preserving
interoperability.

Update handling of `BumpTransactionEvent::ChannelClose` for 0FC channels

Set an empty witness to spend the P2A anchor, and set the version of the
anchor transaction to 3.

We still check whether the commitment transaction has enough fees to be
broadcast on its own, as these transactions may be non-zero fee due to
trimmed / rounded outputs.

Delay HTLC txs in 0FC channels until both commit and anchor txs confirm

It is possible to claim HTLCs and the P2A anchor in the same
transaction, but we leave aggregating these claims to a follow-up.

For now, we imitate the behavior of CSV anchor channels, and wait for
the commitment transaction to confirm before broadcasting HTLC
transactions.

Co-authored-by: Matt Corallo <git@bluematt.me>

Do not produce 0FC HTLC txs on `unsafe_get_latest_holder_commitment_txn`

As in CSV anchor channels, HTLC transactions in 0FC channels require
external funding before they can be finalized, so we choose to return
the commitment transaction alone here.