Matt Corallo [Mon, 30 Oct 2023 21:11:53 +0000 (21:11 +0000)]
wip fuzz coverage
Chris Waterson [Wed, 25 Oct 2023 21:38:54 +0000 (14:38 -0700)]
Split update_holder_per_commitment
Split `update_holder_per_commitment` into two parts:
1. `update_holder_per_commitment_point`, which we call to retrieve a new
commitment point.
2. `update_holder_commitment_secret`, which we call when we're ready to
release the commitment secret.
This delays releasing the secret until we actually need it for the
revoke-and-ack.
By doing this, we restore the signer check to its original condition, as well.
Chris Waterson [Wed, 25 Oct 2023 18:13:23 +0000 (11:13 -0700)]
Use the per-commitment point from the trusted_tx
Chris Waterson [Fri, 20 Oct 2023 15:52:01 +0000 (08:52 -0700)]
Don't persist commitment point/secret
Turns out we don't have to persist the point or secret if we just call
`update_holder_per_commitment` after we read the channel.
Chris Waterson [Wed, 18 Oct 2023 20:55:46 +0000 (13:55 -0700)]
Clean up trailing whitespace.
Chris Waterson [Wed, 18 Oct 2023 18:57:00 +0000 (11:57 -0700)]
Don't persist individual flags
Chris Waterson [Tue, 17 Oct 2023 03:05:21 +0000 (20:05 -0700)]
Fix channel_ready
Make sure that we send a `channel_ready` once we complete funding. Add logging
around each of places where we change the `signer_pending_*` status. Even more
better tests.
Chris Waterson [Tue, 17 Oct 2023 01:02:00 +0000 (18:02 -0700)]
Don't assert on count; assert on message
Chris Waterson [Tue, 17 Oct 2023 00:46:16 +0000 (17:46 -0700)]
Revert rename
Chris Waterson [Tue, 10 Oct 2023 03:13:19 +0000 (20:13 -0700)]
Add tests for peer reconnection
This intersperses peer reconnection in the middle of a payment flow with an
asynchronous signer to verify that things function correctly.
Chris Waterson [Sat, 7 Oct 2023 15:54:07 +0000 (08:54 -0700)]
Support async get_per_commitment_point, release_commitment_secret
Apologies in advance for the hair-ball. Mostly just wanted to get a 50,000 foot
overview to see if things were headed in the right direction. If things look
okay, I can take a step back and chop this into more modestly-sized PRs.
In general, this PR adds state to the context to allow a `ChannelSigner`
implementation to respond asynchronously to the `get_per_commitment_point`,
`release_commitment_secret`, and `sign_counterparty_commitment` methods, which
are the main signer methods that are called during channel setup and normal
operation.
These changes seem to work as advertised during normal channel operation
(creation and payment exchange), and do not obviously fail during channel
re-establishment or across node restart. That said, there are a lot more test
scenarios to evaluate here.
The details are below.
Adds the RevokeAndAck and RAACommitemnt ordering to the `SignerResumeUpdates`
struct that is returned from `signer_maybe_unblocked`.
Adds `signer_maybe_unblocked` for both inbound and outbound unfunded channel
states. We need these now because `get_per_commitment_point` is asynchronous
-- and necessary for us to proceed out of the unfunded state into normal
operation. Adds appropriate `SignerResumeUpdates` classes for both inbound and
outbound unfunded states.
Maintains `cur_holder_commitment_point` and `prev_holder_commitment_secret` on
the channel context. By making these part of the context state, we can access
them at any point we need them without requiring a signer call to
regenerate. These are updated appropriately throughout the channel state
machine by calling a new context method `update_holder_per_commitment`.
Add several flags to indicate messages that may now be pending the remote
signer unblocking:
- `signer_pending_revoke_and_ack`, set when we're waiting to send the
revoke-and-ack to the counterparty. This might _not_ just be us waiting on
the signer; for example, if the commitment order requires sending the RAA
after the commitment update, then even though we _might_ be able to generate
the RAA (e.g., because we have the secret), we will not do so while the
commitment update is pending (e.g., because we're missing the latest point
or do not have a signed counterparty commitment).
- `signer_pending_channel_ready`, set when we're waiting to send the
channel-ready to the counterparty.
- `signer_pending_commitment_point`, set when we're waiting for the signer to
return us the commitment point for the current state.
- `signer_pending_released_secret`, set when we're waiting for the signer to
release the commitment secret for the previous state.
This state (current commitment point, previous secret, flags) is persisted in
the channel monitor, and restored when the channel is unpickled.
When a monitor update completes, we may still be pending results from the
remote signer. If that is the case, we ensure that we correctly maintain the
above state flags before the channel state is resumed. For example, if the
_monitor_ is pending a commitment signed, but we were not able to retrieve the
commitment update from the signer, then we ensure that
`signer_pending_commitment_update` is set.
When unblocking the signer, we need to ensure that we honor message ordering
constraints. For the commitment update and revoke-and-ack, ensure that we can
honor the context's current `resend_order`. For example, assume we must send
the RAA before the CU, and could potentially send a CU because we have the
commitment point and a signed counterparty commitment transaction. _But_, we
have not yet received the previous state's commitment secret. In this case, we
ensure that no messages are emitted until the commitment secret is released,
at which point the signer-unblocked call will emit both messages.
A similar situation exists with the `channel_ready` message and the
`funding_signed` / `funding_created` messages at channel startup: we make sure
that we don't emit `channel_ready` before the funding message.
There is at least one unsolved problem here: during channel re-establishment,
we need to request an _arbitrary_ commitment point from the signer in order to
verify that the counterparty's giving us a legitimate secret. For the time
being, I've simply commented out this check; however, this is not a viable
solution. There are a few options to consider here:
1. We could require that an asynchronous signer _cache_ the previous
commitment points, so that any such request must necessarily succeed
synchronously.
2. We could attempt to factor this method as to admit an asynchronous response
that would restart the channel re-establish once the commitment point has
been provided by the signer and the counterparty's secret can be verified.
The former places some additional burden on a remote signer (albeit minimal)
and seems reasonable to me.
As for testing...
For testing asynchronous channel signing, replaces the simple boolean
("everything is on, or everything is off") with flags that let us toggle
different signing methods on and off. This lets us (sort of) simulate the
signer returning responses in an arbitrary order.
Adds a fully-exploded "send a one-hop payment" test to the async test
suite. At each step, simulate the async signer being unavailable, and then
unblocking. Vary the order to check all possible orderings of
`get_per_commitment_point`, `release_commitment_secret`, and
`sign_counterparty_commitment` being provided by the signer.
But there is a lot more to be done here. Many of the odd-ball cases in the PR
_aren't_ covered by unit tests and were instead uncovered by running the code
in situ with an LND counterparty. So there are a lot more tests to write here.
Chris Waterson [Mon, 16 Oct 2023 22:58:21 +0000 (15:58 -0700)]
Get chan_id from create_announced_chan_between_nodes
Chris Waterson [Mon, 16 Oct 2023 22:54:29 +0000 (15:54 -0700)]
Terser asserts
Get rid of temporaries; replace multiline checks.
Chris Waterson [Mon, 16 Oct 2023 22:52:44 +0000 (15:52 -0700)]
Add logging whenever we set or clear signer pending state
Add trace-level logging when we change the state of a `signer_pending_*`
variable.
Chris Waterson [Mon, 16 Oct 2023 22:45:14 +0000 (15:45 -0700)]
Fix comment location
Actually put the comment in the right place i.e. _before_ we start updating
our local state! :)
Chris Waterson [Tue, 10 Oct 2023 21:45:44 +0000 (14:45 -0700)]
Don't return a `channel_ready` event if funding is pending
Per discussion, make it so that `check_get_channel_ready` returns `None` if
we're still pending a signature on a funding message.
Chris Waterson [Sun, 24 Sep 2023 14:34:08 +0000 (07:34 -0700)]
Fix inbound zero-conf
When we receive an inbound zero-conf channel, we need to defer sending the
`channel_ready` message until *after* we've sent the `funding_signed`
message. We won't be able to produce the `funding_signed` message until the
signer has produced the counterparty commitment signature.
Chris Waterson [Wed, 6 Sep 2023 23:10:42 +0000 (16:10 -0700)]
Add test for peer disconnect and async signing
This adds a test that disconnects and reconnects the peers with a commitment
signature pending.
Chris Waterson [Wed, 6 Sep 2023 22:05:53 +0000 (15:05 -0700)]
Add test for async signing for commitment_signed
This adds a test (and fixes the implementation!) to check that we correctly
resume processing after awaiting an asynchronous signature for a
`commitment_signed` event.
Chris Waterson [Wed, 6 Sep 2023 20:08:50 +0000 (13:08 -0700)]
Add basic async signer tests
This adds a new `async_signer_tests` module and populates it with some simple
checks for asynchronous handling of `funding_created` and `funding_signed`.
Chris Waterson [Wed, 6 Sep 2023 18:38:34 +0000 (11:38 -0700)]
Add support for retrieving and suspending the channel signer
This adds a `get_signer` method to the context so that a test can get ahold of
the channel signer. Adds a `set_available` method on the `TestChannelSigner`
to allow a test to enable and disable the signer: when disabled some of the
signer's methods will return `Err` which will typically activate the error
handling case. Adds a `set_channel_signer_available` function on the test
`Node` class to make it easy to enable and disable a specific signer.
Fix fuzz test
Chris Waterson [Wed, 6 Sep 2023 17:52:51 +0000 (10:52 -0700)]
Remove unused temporaries.
Matt Corallo [Tue, 5 Sep 2023 22:21:04 +0000 (22:21 +0000)]
Handle retrying sign_counterparty_commitment inb funding failures
If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).
This commit adds retrying of inbound funding_created signing
failures, regenerating the `FundingSigned` message, attempting to
re-sign, and sending it to our peers if we succeed.
Matt Corallo [Tue, 5 Sep 2023 22:10:34 +0000 (22:10 +0000)]
Handle retrying sign_counterparty_commitment outb funding failures
If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).
This commit adds retrying of outbound funding_created signing
failures, regenerating the `FundingCreated` message, attempting to
re-sign, and sending it to our peers if we succeed.
Matt Corallo [Tue, 5 Sep 2023 22:06:53 +0000 (22:06 +0000)]
Handle retrying sign_counterparty_commitment failures
If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).
This commit adds initial retrying of failures, specifically
regenerating commitment updates, attempting to re-sign the
`CommitmentSigned` message, and sending it to our peers if we
succed.
Matt Corallo [Tue, 5 Sep 2023 21:13:07 +0000 (21:13 +0000)]
Handle sign_counterparty_commitment failing during inb funding
If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).
Here we add initial handling of sign_counterparty_commitment
failing during inbound channel funding, setting a flag in
`ChannelContext` which indicates we should retry sending the
`funding_signed` later. We don't yet add any ability to do that
retry.
Matt Corallo [Tue, 5 Sep 2023 21:06:22 +0000 (21:06 +0000)]
Handle sign_counterparty_commitment failing during outb funding
If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).
Here we add initial handling of sign_counterparty_commitment
failing during outbound channel funding, setting a new flag in
`ChannelContext` which indicates we should retry sending the
`funding_created` later. We don't yet add any ability to do that
retry.
Matt Corallo [Tue, 5 Sep 2023 20:46:28 +0000 (20:46 +0000)]
Handling for sign_counterparty_commitment failing during normal op
If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending later, rather than force-closing the
channel (which probably won't even work if the signer is missing).
Here we add initial handling of sign_counterparty_commitment
failing during normal channel operation, setting a new flag in
`ChannelContext` which indicates we should retry sending the
commitment update later. We don't yet add any ability to do that
retry.
Matt Corallo [Tue, 24 Oct 2023 01:26:30 +0000 (01:26 +0000)]
Merge pull request #2678 from TheBlueMatt/2023-10-0.0.118
Cut 0.0.118
Matt Corallo [Fri, 20 Oct 2023 23:44:49 +0000 (23:44 +0000)]
Bump crate versions to lightning 0.0.118, invoice 0.26
Matt Corallo [Fri, 20 Oct 2023 20:46:30 +0000 (20:46 +0000)]
0.0.118 release notes
Matt Corallo [Mon, 23 Oct 2023 22:58:15 +0000 (22:58 +0000)]
Merge pull request #2679 from TheBlueMatt/2023-10-116-bindings-1
Small bindings tweaks for 0.0.118
Matt Corallo [Mon, 23 Oct 2023 19:50:12 +0000 (19:50 +0000)]
Fix CI on rustc 1.50 and below
rustc doesn't allow `--features` with `-p`, so we simply skip the
steps that rely on it.
Matt Corallo [Mon, 23 Oct 2023 18:55:17 +0000 (18:55 +0000)]
Use a tuple, not a struct, for `PendingOnionMessage` in bindings
Bindings aren't currently able to handle a struct with a generic
which is actually exposed - we map all structs concretely to a
single type, whereas having fluctuating types on a struct requires
mapping the inner field to a trait first.
Since this isn't super practical, we make `PendingOnionMessage` a
tuple in bindings, rather than a struct.
Matt Corallo [Mon, 23 Oct 2023 19:16:29 +0000 (19:16 +0000)]
Merge pull request #2676 from TheBlueMatt/2023-10-various-followups
Various Followups to 2039 and 2674
Matt Corallo [Mon, 23 Oct 2023 16:49:49 +0000 (16:49 +0000)]
Add relevant no-export tags to functions returning builders
Because we can't map move semantics in most languages, we also
can't map our current builders. Thus, we have to mark them
no-export.
Matt Corallo [Mon, 23 Oct 2023 16:50:05 +0000 (16:50 +0000)]
Drop an unnecessary no-export on ParsedOnionMessageContents
Matt Corallo [Sat, 21 Oct 2023 02:42:48 +0000 (02:42 +0000)]
Do not compile the `Simple*` type aliases in `c_bindings` at all
Because the bindings changes now require further changes to our
type definitions, avoiding building the `Simple*` type aliases
entirely makes the patchset there simpler.
Matt Corallo [Sat, 21 Oct 2023 01:08:38 +0000 (01:08 +0000)]
Fix (and test) the `c_bindings` build flag
Rather than only building with the `c_bindings` flag in certain
crates, we go ahead and test all crates with the flag in CI here.
Matt Corallo [Fri, 20 Oct 2023 18:19:57 +0000 (18:19 +0000)]
Remove some additional excess words in `ConfirmationTarget` docs
Matt Corallo [Fri, 20 Oct 2023 18:11:56 +0000 (18:11 +0000)]
Remove a redundant sentence in `ConfirmationTarget` docs
... and correct direction which causes force-closure in another
sentence.
Matt Corallo [Fri, 20 Oct 2023 18:09:39 +0000 (18:09 +0000)]
Drop unused `use` import.
Matt Corallo [Fri, 20 Oct 2023 17:38:19 +0000 (17:38 +0000)]
Avoid a redundant allocation in `InvoiceError` handling in one case
... by passing an owned `String`, rather than taking an `&str` and
`to_owned()`ing it.
Matt Corallo [Fri, 20 Oct 2023 17:34:12 +0000 (17:34 +0000)]
Use `Default::default()` for scoring params in tests
In
26c1639ab69d6780c97a118f09e42cb42304088a we switched to using
`Default::default()` to initialize `()` for scoring parameters in
tests. A number of `()`s slipped back in recently, which we replace
here.
Matt Corallo [Fri, 20 Oct 2023 22:55:08 +0000 (22:55 +0000)]
Merge pull request #2667 from wpaulino/random-htlc-holder-sigs-non-anchors
Use sign_holder_htlc_transaction to sign non-anchors holder HTLCs
Matt Corallo [Fri, 20 Oct 2023 22:54:08 +0000 (22:54 +0000)]
Merge pull request #2674 from wpaulino/consider-anchor-outputs-value-balances
Consider anchor outputs value throughout balance checks and computations
Wilmer Paulino [Mon, 16 Oct 2023 19:21:52 +0000 (12:21 -0700)]
Move HTLCDescriptor to sign module
Now that `HTLCDescriptor` is no longer specific to anchors, it doesn't
make sense for it to live in the `bump_transaction` module anymore.
Wilmer Paulino [Fri, 13 Oct 2023 21:09:37 +0000 (14:09 -0700)]
Don't sign holder HTLCs along with holder commitments
`sign_holder_commitment_and_htlcs` never really made sense. Unlike
`sign_counterparty_commitment`, the signatures for holder HTLC
transactions may be required much later than the commitment
transaction's. While it was nice for us to only reach the signer once to
obtain all holder signatures, it's not really ideal anymore as we want
our signatures to be random and not reused.
We no longer return all holder HTLC signatures and instead defer to
obtaining them via `EcdsaChannelSigner::sign_holder_htlc_transaction`.
Wilmer Paulino [Fri, 13 Oct 2023 20:58:59 +0000 (13:58 -0700)]
Remove caching of holder HTLC signatures
Since we want our holder HTLC signatures to be randomly generated and
not reused, our existing caches are useless now, so we opt to remove
them.
Wilmer Paulino [Fri, 13 Oct 2023 20:52:23 +0000 (13:52 -0700)]
Use sign_holder_htlc_transaction to sign non-anchors holder HTLCs
We want to ensure we use fresh random signatures to prevent certain
classes of transaction replacement attacks at the bitcoin P2P layer.
This was already covered for commitment transactions and zero fee holder
HTLC transactions, but was missing for holder HTLC transactions on
non-anchors channels.
We can easily do this by reusing the existing
`EcdsaChannelSigner::sign_holder_htlc_transaction` method and
circumventing the existing `holder_htlc_sigs/prev_holder_htlc_sigs`
caches, which will be removed in a later commit anyway.
Matt Corallo [Fri, 20 Oct 2023 17:31:42 +0000 (17:31 +0000)]
Apply a default max fee rather than none when paying for BOLT12
If the user declines to specify a `max_total_routing_fee_msat` in
the new BOLT12 payment methods, rather than defaulting to no limit
on the fee we pay at all, we should default to our "usual default",
ie the one calculated in
`RouteParameters::from_payment_params_and_value`.
We do this here, as well as documenting the behavior on the payment
methods.
Wilmer Paulino [Thu, 19 Oct 2023 16:29:21 +0000 (09:29 -0700)]
Only account for fee spike buffer multiple on non-anchor channels
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.
Wilmer Paulino [Thu, 19 Oct 2023 16:27:57 +0000 (09:27 -0700)]
Consider anchor outputs value on channel open
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".
Wilmer Paulino [Thu, 19 Oct 2023 16:27:30 +0000 (09:27 -0700)]
Consider anchor outputs value on inbound HTLCs
This could lead us to accept HTLCs that would put the sender below
their reserve, which must never happen.
Wilmer Paulino [Thu, 19 Oct 2023 16:25:23 +0000 (09:25 -0700)]
Consider anchor outputs value in get_available_balances
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.
Wilmer Paulino [Thu, 19 Oct 2023 16:22:50 +0000 (09:22 -0700)]
Run chanmon_consistency_test with anchor outputs channels
Wilmer Paulino [Fri, 13 Oct 2023 20:47:45 +0000 (13:47 -0700)]
Provide missing derivation parameters to OnchainTxHandler
`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.
Wilmer Paulino [Fri, 13 Oct 2023 20:49:50 +0000 (13:49 -0700)]
Support signing non-anchors HTLCs with HTLCDescriptor
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.
Matt Corallo [Fri, 20 Oct 2023 17:37:17 +0000 (17:37 +0000)]
Merge pull request #2660 from benthecarman/flexible-fee-rate
More flexible fee rate estimates
benthecarman [Thu, 12 Oct 2023 20:43:30 +0000 (15:43 -0500)]
More flexible fee rate estimates
Matt Corallo [Fri, 20 Oct 2023 16:40:17 +0000 (16:40 +0000)]
Merge pull request #2039 from jkczyz/2023-02-offer-flow
BOLT 12 Offers message flow
Matt Corallo [Fri, 20 Oct 2023 15:57:43 +0000 (15:57 +0000)]
Merge pull request #2670 from yanganto/socket-addr-to-string
Impl `Display` for SocketAddress
Jeffrey Czyz [Fri, 20 Oct 2023 01:32:00 +0000 (20:32 -0500)]
Fix PaymentConstraints::max_cltv_expiry docs
Jeffrey Czyz [Thu, 19 Oct 2023 23:02:58 +0000 (18:02 -0500)]
Fix build warnings
Jeffrey Czyz [Thu, 19 Oct 2023 21:36:02 +0000 (16:36 -0500)]
Expand request_refund_payment docs for limitations
Jeffrey Czyz [Thu, 19 Oct 2023 20:50:19 +0000 (15:50 -0500)]
Onion message routing to immediate peers.
DefaultMessageRouter always fails. Update it so that it can route to a
directly connected peer. This is needed for an Offers minimum viable
product.
Jeffrey Czyz [Thu, 19 Oct 2023 14:45:30 +0000 (09:45 -0500)]
Add privacy section to pay_for_offer docs
Jeffrey Czyz [Thu, 19 Oct 2023 14:37:47 +0000 (09:37 -0500)]
Organize create_refund and pay_for_offer docs
Jeffrey Czyz [Thu, 19 Oct 2023 14:16:08 +0000 (09:16 -0500)]
Document InvoiceRequestFailed in ChannelManager
Jeffrey Czyz [Thu, 12 Oct 2023 21:10:51 +0000 (16:10 -0500)]
Revert "Config-guard Event::InvoiceRequestFailed"
This reverts commit
c7219e46831751c52026932294c33fce24121d84.
Jeffrey Czyz [Tue, 6 Jun 2023 17:00:54 +0000 (12:00 -0500)]
Use ChannelManager as OffersMessageHandler
Jeffrey Czyz [Fri, 1 Sep 2023 19:04:27 +0000 (14:04 -0500)]
OffersMessageHandler impl for ChannelManager
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.
Jeffrey Czyz [Fri, 1 Sep 2023 14:40:34 +0000 (09:40 -0500)]
Grammar fix in docs
Jeffrey Czyz [Fri, 1 Sep 2023 14:38:44 +0000 (09:38 -0500)]
BOLT12 invoice_feature methods for ChannelManager
Jeffrey Czyz [Fri, 1 Sep 2023 14:22:43 +0000 (09:22 -0500)]
Qualify BOLT11 ChannelManager invoice_features
Jeffrey Czyz [Fri, 15 Sep 2023 18:40:41 +0000 (13:40 -0500)]
Utility for creating and sending Bolt12Invoices
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.
Jeffrey Czyz [Thu, 14 Sep 2023 18:32:51 +0000 (13:32 -0500)]
Utility for paying for an Offer
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.
Jeffrey Czyz [Thu, 14 Sep 2023 19:50:56 +0000 (14:50 -0500)]
Store OffersMessages for later sending
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.
Jeffrey Czyz [Thu, 19 Oct 2023 13:45:25 +0000 (08:45 -0500)]
Expand docs on failing expired outbound payments
Antonio Yang [Wed, 18 Oct 2023 10:36:03 +0000 (18:36 +0800)]
impl Display for SocketAddress
Elias Rohrer [Fri, 20 Oct 2023 07:52:29 +0000 (09:52 +0200)]
Merge pull request #2636 from slanesuke/impl-ToSocketAddrs-for-Hostname
Impl ToSocketAddrs for SocketAddress
Matt Corallo [Thu, 19 Oct 2023 21:49:02 +0000 (21:49 +0000)]
Merge pull request #2666 from tnull/2023-10-observable-update
Matt Corallo [Thu, 19 Oct 2023 17:53:46 +0000 (17:53 +0000)]
Merge pull request #2661 from TheBlueMatt/2023-10-dup-claim-chan-hang
Immediately unblock channels on duplicate claims
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.
Matt Corallo [Thu, 12 Oct 2023 22:26:07 +0000 (22:26 +0000)]
Indicate to `claim_funds_internal` that we're replaying on startup
While we'd previously avoided this, this is sadly now required in
the next commit.
Matt Corallo [Wed, 11 Oct 2023 01:39:26 +0000 (01:39 +0000)]
Log when we prepare to block a channel's next `revoke_and_ack`
This may help in debugging blocking actions in the future.
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.
Elias Rohrer [Fri, 13 Oct 2023 09:30:15 +0000 (11:30 +0200)]
Allow to verify channel updates without applying them
We introduce a new `NetworkGraph::verify_channel_update` method that
allows to check whether an update would be applied by `update_channel`.
Matt Corallo [Thu, 19 Oct 2023 02:41:48 +0000 (02:41 +0000)]
Merge pull request #2578 from jkczyz/2023-09-offer-utilities
BOLT 12 Offers utilities
slanesuke [Sat, 30 Sep 2023 23:05:00 +0000 (17:05 -0600)]
Impl ToSocketAddrs for SocketAddress
Jeffrey Czyz [Wed, 18 Oct 2023 23:24:07 +0000 (18:24 -0500)]
Clean up peel_onion name, parameters, and docs
For consistency with other functions and doc cleanliness.
Jeffrey Czyz [Fri, 3 Mar 2023 15:38:45 +0000 (09:38 -0600)]
Include a one-hop blinded path in Offer and Refund
While this doesn't add much privacy over not including any blinded
paths, it allows us to exercise code for receiving on blinded paths.
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`.
Jeffrey Czyz [Tue, 17 Oct 2023 15:47:48 +0000 (10:47 -0500)]
Remove outdated docs
Jeffrey Czyz [Mon, 11 Sep 2023 22:40:43 +0000 (17:40 -0500)]
Allow sending onion messages to 1-hop blinded path
This allows for specifying the introduction node as the message
recipient.
Jeffrey Czyz [Thu, 14 Sep 2023 02:19:50 +0000 (21:19 -0500)]
Enqueue onion messages in handlers
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.