rust-lightning

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.

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>

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.

Set 0FC `HolderHTLCOutput`, `HolderFundingOutput` to require addl funds

Also set the malleability of 0FC `HolderHLTCOutput` to be the same as in
CSV anchor channels.

And add debug asserts from CSV anchor channels that also apply to P2A
anchor channels.

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

Set `AnchorDescriptor` output value to CSV and P2A anchor amounts

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

Add a new `ChannelMoniorUpdateStep::ReleasePaymentComplete`

`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 take the first step towards that notification, adding a new
`ChannelMonitorUpdateStep` for the completion notification, and
tracking HTLCs which make it to the `ChannelMonitor` in such
updates in a new map.

Prepare to provide 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 prepare to generate the new
`ChannelMonitorUpdateStep::ReleasePaymentComplete` updates, adding
a new `PaymentCompleteUpdate` struct to track the new update before
we generate the `ChannelMonitorUpdate` and passing through to the
right places in `ChannelManager`.

The only cases where we want to generate the new update is after a
`PaymentSent` or `PaymentFailed` event when the event was the
result of a `MonitorEvent` or the equivalent read during startup.

Derive `Copy` for `HumanReadableName`s

Now that these do not allocate, we should allow them to be
`Copy`ed.

Clean up FundedChannel::pending_splice docs

Persist FundedChannel::pending_splice

Once a splice funding transaction has been constructed, the
corresponding state must be persisted so that the process can be
continued across restarts. This includes exchanging signatures, waiting
for enough confirmations, and RBF'ing.

Forward invoice requests to async recipient

As a static invoice server, if we receive an invoice request on
behalf of an often-offline recipient we will reply to the sender
with the static invoice previously provided by the async recipient.

Here, in addition to doing that we'll forward the invoice request
received to the async recipient to give it a chance to reply with
a fresh invoice in case it is online.

Account for pending splice in claimable balances

There are two states in which a pending splice balance should be
considered:

1. The channel has closed with a confirmed holder commitment transaction
from a splice that did not become locked. The balance from this
transaction is reported.
2. The channel is open and has multiple holder commitment transaction
candidates that are valid based on the funding transaction that
confirms. We want to report the pending splice balance to users while
it has yet to become locked, such that they are able to see their
funds have moved from their onchain wallet to the channel. We default
to reporting the latest splice/RBF balance via
`Balance::claimable_amount_satoshis` to mimic how an onchain wallet
would behave when reporting unconfirmed balance, otherwise we report
the balance for the confirmed splice transaction.

Use struct syntax for FundingNegotiation variants

To use impl_writeable_tlv_based_enum_upgradable with unread_variants,
currently tuple syntax can't be used enum variants. Update
FundingNegotiation to use this syntax so that it can be used with that
macro.

Update OnionMessage with link to BOLTs

Use correct nonce in InvoiceRequest context

Previously it would generate a new nonce for this context
instead of using the offer nonce. This would make it so
that verification would fail later when receiving a
invoice request.

Inline promote_splice_funding macro

Release held htlcs on release_held_htlc

As part of supporting sending payments as an often-offline sender, the sender's
always-online channel counterparty needs to hold onto the sender's HTLC until
they receive a release_held_htlc onion message from the often-offline
recipient.

Here we implement forwarding these held HTLCs upon receipt of the release
message from the recipient.

Add pending_changelog for async send

See prior commits.

Support creating reply_path for HeldHtlcAvailable

As part of supporting sending payments as an often-offline sender, the sender
needs to send held_htlc_available onion messages such that the reply path to
the message terminates at their always-online channel counterparty that is
holding the HTLC. That way when the recipient responds with release_held_htlc,
the sender's counterparty will receive that message.

Here we add a method for creating said reply path, which will be used in the
next commit.

Include release_held_htlc blinded paths in RAA

As part of supporting sending payments as an often-offline sender, the sender
needs to send held_htlc_available onion messages such that the reply path to
the message terminates at their always-online channel counterparty that is
holding the HTLC. That way when the recipient responds with release_held_htlc,
the sender's counterparty will receive that message.

Here the counterparty starts including said reply paths in the revoke_and_ack
message destined for the sender, so the sender can use these paths in
subsequent held_htlc_available messages.

We put the paths in the RAA to ensure the sender receives the blinded paths,
because failure to deliver the paths means the HTLC will timeout/fail.

Store held htlcs in pending_intercepted_htlcs

As part of supporting sending payments as an often-offline sender, the sender's
always-online channel counterparty needs to hold onto the sender's HTLC until
they receive a release_held_htlc onion message from the often-offline
recipient.

Here we implement storing these held HTLCs in the existing
ChannelManager::pending_intercepted_htlcs map.

We want to move in the direction of obviating the need to persistence the
ChannelManager entirely, so it doesn't really make sense to add a whole new map
for these HTLCs.

Extract helper + logger for failing HTLC intercepts

Makes the next commit cleaner.

Remove forward_htlcs<>intercepted_htlcs lock dep

We previously had a lock order dependency where the forward_htlcs lock had to
be taken before the intercepted_htlcs lock. Here we remove this dependency,
which also prepares for a cleaner commit once we start also intercepting HTLCs
for often-offline recipients.

Add RevokeAndACK::release_htlc_message_paths

As part of supporting sending payments as an often-offline sender, the sender
needs to send held_htlc_available onion messages where the reply path
terminates at their always-online channel counterparty that is holding the HTLC
until the recipient comes online. That way when the recipient sends
release_held_htlc, the sender's counterparty will receive that message.

To accomplish this, the sender's always-online counterparty includes said reply
path in the revoke_and_ack message corresponding to the held HTLC. Here we add
support for this field, though we don't set it yet.

We also had to tweak the ser macros for this because impl_writeable_msg had
never had to write a Vec in a message TLV field before.

Rename PendingSplice to PendingFunding

While PendingSplice is only used for splicing a FundedChannel, it will
be useful when supporting RBF for V2 channel establishment.