Anchor outputs channels are no longer susceptible to fee spikes as they
now mostly target the dynamic minimum mempool fee and can contribute the
remainder of fees when closing.
We should make sure the funding amount of a channel can cover all its
associated costs, including the value of anchor outputs, to make sure
that it is actually usable once "opened".
This could lead us to sending/forwarding HTLCs that would put us below
our reserve, forcing our counterparty to close the channel on us due to
an invalid update.
`OnchainTxHandler` will need to construct `HTLCDescriptor`s for holder
HTLCs, but it did not have access to all of the derivation parameters
that need to be provided.
We plan to use `EcdsaChannelSigner::sign_holder_htlc_transaction` to
also sign holder HTLC transactions on non-anchor outputs channels.
`HTLCDescriptor` was only used in an anchor outputs context, so a few
things needed changing, mostly to handle the different scripts and
feerate.
In a96e2fe144 we renamed
`MonitorEvent::CommitmentTxConfirmed` to `HolderForceClosed` to
better document what actually happened. However, we failed to
update the documentation on the type, which we do here.
Pointed out by @yellowred.
Define the BOLT 12 message flow in ChannelManager's
OffersMessageHandler implementation.
- An invoice_request message results in responding with an invoice
message if it can be verified that the request is for a valid offer.
- An invoice is paid if it can be verified to have originated from a
sent invoice_request or a refund.
- An invoice_error is sent in some failure cases.
- Initial messages enqueued for sending are released to OnionMessenger
Building an invoice will fail if the underlying offer or refund has
already expired. The check was skipped in no-std since there is no
system clock. However, the invoice creation time can be used instead.
This prevents responding to an invoice request if the offer has already
expired.
Add a utility to ChannelManager for creating a Bolt12Invoice for a
Refund such that the ChannelManager can recognize the PaymentHash and
reconstruct the PaymentPreimage from the PaymentSecret, the latter of
which is contained in a BlindedPath within the invoice.
Add a utility to ChannelManager for sending an InvoiceRequest for an
Offer such that derived keys are used for the payer id. This allows for
stateless verification of any Invoice messages before it is paid.
Also tracks future payments using the given PaymentId such that the
corresponding Invoice is paid only once.
Pending outbound payments use an absolute expiry to determine when they
are considered stale and should be fail. In `no-std`, this may result in
long timeouts as the highest seen block time is used. Instead, allow for
expiration based on timer ticks. This will be use in an upcoming commit
for invoice request expiration.
Upcoming commits will add utilities for sending an InvoiceRequest for an
Offer and an Invoice for a Refund. These messages need to be enqueued so
that they can be released in ChannelManager's implementation of
OffersMessageHandler to OnionMessenger for sending.
These messages do not need to be serialized as they must be resent upon
restart.
When `MonitorUpdateCompletionAction`s were added, we didn't
consider the case of a duplicate claim during normal HTLC
processing (as the handling only had an `if let` rather than a
`match`, which made the branch easy to miss). This can lead to a
channel freezing indefinitely if an HTLC is claimed (without a
`commitment_signed`), the peer disconnects, and then the HTLC is
claimed again, leading to a never-completing
`MonitorUpdateCompletionAction`.
The fix is simple - if we get back an
`UpdateFulfillCommitFetch::DuplicateClaim` when claiming from the
inbound edge, immediately unlock the outbound edge channel with a
new `MonitorUpdateCompletionAction::FreeOtherChannelImmediately`.
Here we implement this fix by actually generating the new variant
when a claim is duplicative.
When `MonitorUpdateCompletionAction`s were added, we didn't
consider the case of a duplicate claim during normal HTLC
processing (as the handling only had an `if let` rather than a
`match`, which made the branch easy to miss). This can lead to a
channel freezing indefinitely if an HTLC is claimed (without a
`commitment_signed`), the peer disconnects, and then the HTLC is
claimed again, leading to a never-completing
`MonitorUpdateCompletionAction`.
The fix is simple - if we get back an
`UpdateFulfillCommitFetch::DuplicateClaim` when claiming from the
inbound edge, immediately unlock the outbound edge channel with a
new `MonitorUpdateCompletionAction::FreeOtherChannelImmediately`.
Here we add the new variant, which we start generating in the next
commit.
If we receive a channel update from an intermediary via a failure onion
we shouldn't apply them in a persisted and network-observable way to our
network graph, as this might introduce a privacy leak. Here, we
therefore avoid applying such updates to our network graph.
This refactors ShutdownResult as follows:
- Makes ShutdownResult a struct instead of a tuple to represent
individual results that need to be handled. This recently also
includes funding batch closure propagations.
- Makes Channel solely responsible for constructing ShutdownResult as
it should own all channel-specific logic.
The check_closed_event function verified closure events against multiple
counterparty nodes, but only a single closure reason and channel
capacity. This commit introduces a check_closed_events function to
verify events against descriptions of each expected event, and refactors
check_closed_event in function of check_closed_events.
Add utility functions to ChannelManager for creating OfferBuilder,
and RefundBuilder such that derived keys are used for the signing
pubkey and payer id, respectively. This allows for stateless
verification of any InvoiceRequest and Invoice messages.
Later, blinded paths can be included in the returned builders.
Also tracks future payments using the given PaymentId such that the
corresponding Invoice is paid only once.
PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks
that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a
constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is
forgotten. However, this mechanism is insufficient for the Refund
scenario, where the Refund's expiration should be used instead.
Change AwaitingInvoice to store an absolute expiry instead. When
removing stale payments, pass the `SystemTime` in `std` and the highest
block time minus two hours in `no-std`.
