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
Jeffrey Czyz [Thu, 19 Oct 2023 22:49:13 +0000 (17:49 -0500)]
Check offer expiry when building invoice in no-std
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.
Jeffrey Czyz [Thu, 19 Oct 2023 19:38:16 +0000 (14:38 -0500)]
Absolute expiry or timer tick payment expiration
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.
Matt Corallo [Wed, 11 Oct 2023 14:01:28 +0000 (14:01 +0000)]
Immediately unblock channels on duplicate claims
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.
Matt Corallo [Wed, 11 Oct 2023 13:56:00 +0000 (13:56 +0000)]
Add an immediately-freeing `MonitorUpdateCompletionAction`.
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.
Elias Rohrer [Thu, 19 Oct 2023 15:00:50 +0000 (17:00 +0200)]
Don't apply PathFailure::ChannelUpdateMessage
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.
Jeffrey Czyz [Tue, 14 Feb 2023 03:54:37 +0000 (21:54 -0600)]
Stateless offer and refund builder utilities
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.
Jeffrey Czyz [Tue, 17 Oct 2023 14:59:39 +0000 (09:59 -0500)]
Await for invoices using an absolute expiry
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`.
When constructing onion messages to send initially (opposed to replying
to one from a handler), the user must construct an OnionMessagePath first
before calling OnionMessener::send_onion_message. Additionally, having a
reference to OnionMessener isn't always desirable. For instance, in an
upcoming commit, ChannelManager will implement OffersMessageHandler,
which OnionMessenger needs a reference to. If ChannelManager had a
reference to OnionMessenger, too, there would be a dependency cycle.
Instead, modify OffersMessageHandler and CustomOnionMessageHandler's
interfaces to include a method for releasing pending onion messages.
That way, ChannelManager may, for instance, construct and enqueue an
InvoiceRequest for sending without needing a reference to
OnionMessenger.
Additionally, OnionMessenger has responsibility for path finding just as
it does when replying to messages from a handler. It performs this when
extracting messages from the handlers before returning the next message
to send to a peer.
Rename CustomOnionMessageContents to OnionMessageContents and use it as
a trait bound on messages passed to OnionMessenger methods. This allows
using the trait in an upcoming commit as a bound on the contents of
PendingOnionMessage.
Also, make ParsedOnionMessageContent implement OnionMessageContents so
that Payload can be bounded by OnionMessageContents directly, but used
when either reading a ParsedOnionMessageContent or writing a specific
type of OnionMessageContents (e.g., OffersMessage).
In preparation for needing the name OnionMessageContents for a trait to
bound methods, rename it to ParsedOnionMessageContents. In the next
commit, it's use will be limited to reading only, and the new trait will
be a bound on method parameters instead.
OnionMessenger can send onion message responses from its handlers using
respond_with_onion_message, which finds a path to the destination and
enqueues the response for sending. Generalize this as it can be used not
only for responses but for initial sends as well.
OnionMessageProvider is a super-trait of OnionMessageHandler, but they
don't need to be used separately. Additionally, the former is misplaced
in the events module. Remove OnionMessageProvider and add it's only
method, next_onion_message_for_peer, into OnionMessageHandler.
Matt Corallo [Wed, 18 Oct 2023 15:22:26 +0000 (15:22 +0000)]
Fix race between outbound messages and peer disconnection
Previously, outbound messages held in `process_events` could race
with peer disconnection, allowing a message intended for a peer
before disconnection to be sent to the same peer after
disconnection.
The fix is simple - hold the peers read lock while we fetch
pending messages from peers (as we disconnect with the write lock).
Wilmer Paulino [Mon, 16 Oct 2023 20:29:06 +0000 (13:29 -0700)]
Release short_to_chan_info lock throughout forwarding_channel_not_found
Not doing so caused a lock order inversion between the locks
`ChannelManager::best_block` and `ChannelManager::short_to_chan_info`
after the addition of `test_trigger_lnd_force_close`.
It turns out that we were holding the `short_to_chan_info` for longer
than needed when processing HTLC forwards. We only need to acquire it to
quickly obtain channel info, and there aren't any other locks within
`forwarding_channel_not_found` that depend on it being held.
Wilmer Paulino [Fri, 13 Oct 2023 16:28:35 +0000 (09:28 -0700)]
Disconnect peer when force closing a funded channel with an error
We do this to ensure that the counterparty will always broadcast their
latest state when we broadcast ours. Usually, they'll do this with the
`error` message alone, but if they don't receive it or ignore it, then
we'll force them to broadcast by sending them a bogus
`channel_reestablish` upon reconnecting. Note that this doesn't apply to
unfunded channels as there is no commitment transaction to broadcast.
Wilmer Paulino [Wed, 11 Oct 2023 16:42:05 +0000 (09:42 -0700)]
Send bogus ChannelReestablish for unknown channels
Unfortunately, lnd doesn't force close on errors
(https://github.com/lightningnetwork/lnd/blob/abb1e3463f3a83bbb843d5c399869dbe930ad94f/htlcswitch/link.go#L2119).
One of the few ways to get an lnd counterparty to force close is by
replicating what they do when restoring static channel backups (SCBs).
They send an invalid `ChannelReestablish` with `0` commitment numbers
and an invalid `your_last_per_commitment_secret`.
Since we received a `ChannelReestablish` for a channel that doesn't
exist, we can assume it's likely the channel closed from our point of
view, but it remains open on the counterparty's side. By sending this
bogus `ChannelReestablish` message now as a response to theirs, we
trigger them to force close broadcasting their latest state. If the
closing transaction from our point of view remains unconfirmed, it'll
enter a race with the counterparty's to-be-broadcast latest commitment
transaction.
Jeffrey Czyz [Fri, 13 Oct 2023 22:01:19 +0000 (17:01 -0500)]
Use ChainHash instead of BlockHash as applicable
ChainHash is more appropriate for places where an arbitrary BlockHash is
not desirable. This type was introduced in later versions of the bitcoin
crate, thus BlockHash was used instead.
Using ChainHash also makes it easier to check if ChannelManager is
compatible with an Offer.
Matt Corallo [Thu, 12 Oct 2023 21:15:49 +0000 (21:15 +0000)]
Make test log lines somewhat more eye-scannable
When running tests, our log output should be reasonably readable
by developers, but currently it repeats the module twice (via the
module and file name), and then starts the log line at a variable
location.
Instead, we only print the module and then align the start of the
log lines so that the output is much more scannable.
Matt Corallo [Sat, 14 Oct 2023 18:41:34 +0000 (18:41 +0000)]
Reduce disk usage in CI
Recently github appears to have reduced the available free disk
space in actions runs, causing CI to fail with out of space errors.
Here we simply run `cargo clean` a few times in CI to reduce our
disk usage somewhat.
Vladimir Fomene [Mon, 2 Oct 2023 19:05:42 +0000 (22:05 +0300)]
fix: use the update_add_htlc's cltv_expiry for comparison
As noted in BOLT 4, we should be using the update_add_htlc's cltv_expiry,
not the CLTV expiry set by the sender in the onion for this comparison.
See here: https://github.com/lightning/bolts/blob/4dcc377209509b13cf89a4b91fde7d478f5b46d8/04-onion-routing.md?plain=1#L334
Matt Corallo [Mon, 9 Oct 2023 03:24:54 +0000 (03:24 +0000)]
Replace `lightning-block-sync` test that depended on `foo.com`
Our tests should generally not rely on internet access, and should
not rely on the behavior of any given remote server. However, one
of the `endpoint_tests` in `lightning-block-sync::http` relied on
`foo.com` resolving to a single socket address, which both might
change in the future and makes our tests fail without internet.
Matt Corallo [Thu, 5 Oct 2023 23:57:08 +0000 (23:57 +0000)]
Make clippy shut up about `PartialOrd` and `Ord` both impl'd
Clippy gets mad that we have an implementation of `ParialOrd` and
`Ord` separately, even though both are identical. Making
`ParitalOrd` call `Ord` makes clippy shut up.
Matt Corallo [Tue, 3 Oct 2023 04:12:28 +0000 (04:12 +0000)]
Make `InMemorySigner` parameter-fetching utilities return `Option`s
In the previous commit we fixed a bug where we were spuriously
(indirectly) `unwrap`ing the `channel_parameters` in
`InMemorySigner`. Here we make such bugs much less likely in the
future by having the utilities which do the `unwrap`ing internally
return `Option`s instead.
Matt Corallo [Sun, 1 Oct 2023 00:15:22 +0000 (00:15 +0000)]
Avoid unwrap'ing `channel_parameters` in to_counterparty signing
Previously, `StaticPaymentOutputDescriptor`s did not include
`channel_parameters` for the signer. As a result, when going to
spend old `StaticPaymentOutputDescriptor`s,
`InMemorySigner::sign_counterparty_payment_input` may be called
with `channel_parameters` set to `None`. This should be fine, but
in fa2a2efef47b5da48ac7a239f3d8a835a7f28164 we started relying on
it (indirectly via `channel_features`) for signing. This caused an
`unwrap` when spending old output descriptors.
This is fixed here by simply avoiding the unwrap and assuming old
`StaticPaymentOutputDescriptor`s represent non-anchor channels.
Matt Corallo [Thu, 28 Sep 2023 02:45:00 +0000 (02:45 +0000)]
Use `crate::prelude::*` to load `Vec`, rather than `crate::Vec`
This is kinda dumb, but the bindings get confused when referring
to `Vec` absolutely in a `use` statement, and there's no reason not
to load our prelude everywhere.
Matt Corallo [Wed, 27 Sep 2023 23:02:50 +0000 (23:02 +0000)]
Drop various bounds on types passed to `MonitorUpdatingPersister`
The new `MonitorUpdatingPersister` has a few redundant type bounds
(re-specified on functions after having been specified on the
struct itself), which we remove here.
Further, it requires a `Deref<FeeEstimator>` which is `Clone`able.
This is generally fine in rust, but annoying in bindings, so we
simply elide it in favor if a `&Deref<FeeEstimator>`.