Jeffrey Czyz [Fri, 9 Dec 2022 20:45:56 +0000 (14:45 -0600)]
Check entire TLV stream instead of by field
This causes a compilation error if a new field is added but missed in
the tests.
Jeffrey Czyz [Mon, 28 Nov 2022 16:20:07 +0000 (11:20 -0500)]
Add BOLT 12 merkle root test for `invoice_request`
A BOLT 12 test vector uses an `invoice_request` message that has a
currency, which aren't supported, so using OfferBuilder::build_unchecked
is required to avoid a panic.
Jeffrey Czyz [Wed, 16 Nov 2022 22:13:52 +0000 (16:13 -0600)]
Invoice request parsing tests
Tests for checking invoice_request message semantics when parsing bytes
as defined by BOLT 12.
Jeffrey Czyz [Fri, 11 Nov 2022 03:12:58 +0000 (21:12 -0600)]
Invoice request building tests
Tests for checking invoice_request message semantics when building as
defined by BOLT 12.
Jeffrey Czyz [Wed, 31 Aug 2022 15:19:44 +0000 (10:19 -0500)]
Builder for creating invoice requests
Add a builder for creating invoice requests for an offer given a
payer_id. Other settings may be optional depending on the offer and
duplicative settings will override previous settings. Building produces
a semantically valid `invoice_request` message for the offer, which then
can be signed for the payer_id.
Jeffrey Czyz [Tue, 23 Aug 2022 22:31:46 +0000 (17:31 -0500)]
Invoice request raw byte encoding and decoding
When reading an offer, an `invoice_request` message is sent over the
wire. Implement Writeable for encoding the message and TryFrom for
decoding it by defining in terms of TLV streams. These streams represent
content for the payer metadata (0), reflected `offer` (1-79),
`invoice_request` (80-159), and signature (240).
Jeffrey Czyz [Tue, 9 Aug 2022 22:37:02 +0000 (17:37 -0500)]
Merkle root hash computation
Offers uses a merkle root hash construction for signature calculation
and verification. Add a submodule implementing this so that it can be
used when parsing and signing invoice_request and invoice messages.
Jeffrey Czyz [Fri, 24 Jun 2022 21:18:29 +0000 (16:18 -0500)]
Schnorr Signature serialization
BOLT 12 uses Schnorr signatures for signing offers messages, which need
to be serialized.
Jeffrey Czyz [Mon, 19 Sep 2022 21:57:46 +0000 (16:57 -0500)]
Invoice request message interface and data format
Define an interface for BOLT 12 `invoice_request` messages. The
underlying format consists of the original bytes and the parsed
contents.
The bytes are later needed when constructing an `invoice` message. This
is because it must mirror all the `offer` and `invoice_request` TLV
records, including unknown ones, which aren't represented in the
contents.
The contents will be used in `invoice` messages to avoid duplication.
Some fields while required in a typical user-pays-merchant flow may not
be necessary in the merchant-pays-user flow (e.g., refund, ATM).
Matt Corallo [Tue, 6 Dec 2022 21:19:29 +0000 (21:19 +0000)]
Add second TODO when claiming to mirror the existing TODO on claim fail
Matt Corallo [Tue, 6 Dec 2022 21:13:35 +0000 (21:13 +0000)]
Drop unused link in `claim_funds`
Matt Corallo [Wed, 30 Nov 2022 21:48:46 +0000 (21:48 +0000)]
Drop now-unused `ClaimFundsFromHop` enum and replace with an `Err`
Matt Corallo [Tue, 6 Dec 2022 21:01:50 +0000 (21:01 +0000)]
Handle claim result event generation in claim_funds_from_hop
Currently `claim_funds` and `claim_funds_internal` call
`claim_funds_from_hop` and then surface and `Event` to the user
informing them of the forwarded/claimed payment based on it's
result. In both places we assume that a claim "completed" even if
a monitor update is being done async.
Instead, here we push that event generation through a
`MonitorUpdateCompletionAction` and a call to
`handle_monitor_update_completion_action`. This will allow us to
hold the event(s) until async monitor updates complete in the
future.
Matt Corallo [Wed, 30 Nov 2022 05:47:16 +0000 (05:47 +0000)]
Don't hold `channel_state` lock for entire duration of claim_funds
When `claim_funds` has to claim multiple HTLCs as a part of a
single MPP payment, it currently does so holding the
`channel_state` lock for the entire duration of the claim loop.
Here we swap that for taking the lock once for each HTLC. This
allows us to be more flexible with locks going forward, and
ultimately isn't a huge change - if our counterparty intends to
force-close a channel, us choosing to ignore it by holding the
`channel_state` lock for the duration of the claim isn't going to
result in a commitment update, it will just result in the preimage
already being in the `ChannelMonitor`.
Matt Corallo [Tue, 6 Dec 2022 20:46:02 +0000 (20:46 +0000)]
Handle closed-chan HTLC claims in `claim_funds_from_hop`
Currently `claim_funds` does all HTLC claims in one `channel_state`
lock, ensuring that we always make claims from channels which are
open. It can thus avoid ever having to generate a
`ChannelMonitorUpdate` containing a preimage for a closed channel,
which we only do in `claim_funds_internal` (for forwarded payments).
In the next commit we'll change the locking of
`claim_funds_from_hop` so that `claim_funds` is no longer under a
single lock but takes a lock for each claim. This allows us to be
more flexible with locks going forward, and ultimately isn't a huge
change - if our counterparty intends to force-close a channel, us
choosing to ignore it by holding the `channel_state` lock for the
duration of the claim isn't going to result in a commitment update,
it will just result in the preimage already being in the
`ChannelMonitor`.
Matt Corallo [Wed, 30 Nov 2022 18:37:12 +0000 (18:37 +0000)]
Add support for handling "actions" after a monitor update completes
This adds a new enum, `MonitorUpdateCompletionAction` and a method
to execute the "actions". They are intended to be done once a
(potentially-async) `ChannelMonitorUpdate` persistence completes,
however this behavior will be implemented in a future PR. For now,
this adds the relevant infrastructure which will allow us to
prepare `claim_funds` for better monitor async handling.
Matt Corallo [Tue, 6 Dec 2022 18:33:52 +0000 (18:33 +0000)]
Store pending claims awaiting monitor update in a separate map
In the next commits we'll move to generating `PaymentClaimed`
events while handling `ChannelMonitorUpdate`s rather than directly
in line. Thus, as a prerequisite, here we move to storing the info
required to generate the `PaymentClaimed` event in a separate map.
Note that while this does introduce a new map which is written as
an even value which users cannot opt out of, the map is only filled
in when users use the asynchronous `ChannelMonitor` updates and
after a future PR. As these are still considered beta, breaking
downgrades for such users is considered acceptable in the future PR
(which will likely be one LDK version later).
Matt Corallo [Wed, 7 Dec 2022 23:17:31 +0000 (23:17 +0000)]
Slightly clarify comment on safety of only processing HTLCs once
Matt Corallo [Wed, 7 Dec 2022 00:41:07 +0000 (00:41 +0000)]
Ensure `Event::BumpTransaction` is forwards-compatible
`Event`s with an odd type are ignored by older versions of LDK,
however they rely on the `write_tlv_fields` call to know how many
bytes to read and discard. We were missing that call in our writing
of `Event::BumpTransaction`, which we add here.
Matt Corallo [Wed, 7 Dec 2022 00:40:38 +0000 (00:40 +0000)]
Use `Witness::push_bitcoin_signature` where relevant
Matt Corallo [Wed, 7 Dec 2022 00:40:17 +0000 (00:40 +0000)]
Drop excess mut on `OnchainTxHandler::generate_external_htlc_claim`
Matt Corallo [Wed, 7 Dec 2022 00:30:43 +0000 (00:30 +0000)]
DRY the comparison blocks in `update_claims_view_from_matched_txn`
In `update_claims_view_from_matched_txn` we have two different
tx-equivalence checks which do the same thing - both check that the
tx which appeared on chain spent all of the outpoints which we
intended to spend in a given package. While one is more effecient
than the other (but only usable in a subset of cases), the
difference between O(N) and O(N^2) when N is 1-5 is trivial.
Still, it is possible we hit this code with just shy of 900 HTLC
outputs in a channel, and a transaction with a ton of inputs.
While having to spin through a few million entries if our
counterparty wastes a full block isn't really a big deal, we go
ahead and use a sorted vec and binary searches because its trivial.
Matt Corallo [Wed, 7 Dec 2022 00:29:11 +0000 (00:29 +0000)]
Use `PackageId` rather than `Txid` in `OnchainEvent::Claim`
In
19daccf7fb5ea81c8d235c1628a91efe0aa07b96, a `PackageId` type was
added to differentiate between an opaque Id for packages and the
`Txid` type which was being used for that purpose. It, however,
failed to also replace the single inner field in
`OnchainEvent::Claim` which was also a package ID. We do so here.
Wilmer Paulino [Wed, 7 Dec 2022 18:30:25 +0000 (10:30 -0800)]
Use even types for opt_anchors
This prevents downgrading to older versions of LDK that are not capable
of supporting anchor channels when the field is serialized (i.e.,
opt_anchors is `Some`).
Matt Corallo [Wed, 7 Dec 2022 17:52:04 +0000 (17:52 +0000)]
Merge pull request #1863 from TheBlueMatt/2022-11-holding-cell-batch-update
Lean on the holding cell when batch-forwarding/failing HTLCs
Matt Corallo [Wed, 7 Dec 2022 05:51:27 +0000 (05:51 +0000)]
Merge pull request #1825 from wpaulino/anchors-bump-htlc-resolution-event
Introduce new BumpTransactionEvent variant HTLCResolution
Wilmer Paulino [Wed, 30 Nov 2022 22:05:02 +0000 (14:05 -0800)]
Extend BaseSign with HTLC output signing support for external claims
Wilmer Paulino [Wed, 31 Aug 2022 19:03:35 +0000 (12:03 -0700)]
Yield BumpHTLCResolution events
Wilmer Paulino [Wed, 30 Nov 2022 22:03:45 +0000 (14:03 -0800)]
Expose HTLC transaction construction helpers
Wilmer Paulino [Tue, 22 Nov 2022 01:22:06 +0000 (17:22 -0800)]
Rename set_equality within update_claims_view_from_matched_txn
Wilmer Paulino [Wed, 30 Nov 2022 22:03:26 +0000 (14:03 -0800)]
Generate ClaimEvent for HolderHTLCOutput inputs from anchor channels
Wilmer Paulino [Mon, 28 Nov 2022 15:47:44 +0000 (07:47 -0800)]
Introduce internal package ID to track pending claims
Now that our txids will no longer be stable for package claims that
require external funds to be allocated, we transition to a 32-byte array
identifier to remain compatible with them.
Wilmer Paulino [Wed, 31 Aug 2022 18:56:59 +0000 (11:56 -0700)]
Support HolderHTLCOutput inputs from anchor channels
Wilmer Paulino [Wed, 13 Jul 2022 17:27:45 +0000 (10:27 -0700)]
Specify amount units in HolderHTLCOutput
This is only a name change, there is no change in behavior.
Wilmer Paulino [Tue, 22 Nov 2022 01:11:09 +0000 (17:11 -0800)]
Update HTLC transaction detection from revoked counterparty commitments
Previously, this method assumed that all HTLC transactions have 1 input
and 1 output, with the sole input having a witness of 5 elements. This
will no longer be the case for HTLC transactions on channels with
anchors outputs since additional inputs and outputs can be attached to
them to allow fee bumping.
Wilmer Paulino [Thu, 25 Aug 2022 20:09:29 +0000 (13:09 -0700)]
Track HTLC resolving transaction to determine input index
Matt Corallo [Tue, 6 Dec 2022 22:46:04 +0000 (22:46 +0000)]
Merge pull request #1895 from TheBlueMatt/2022-12-fix-missing-data
Fix some onion errors and assert their length is correct
Matt Corallo [Fri, 2 Dec 2022 21:12:47 +0000 (21:12 +0000)]
Correctly handle any `UPDATE` errors to phandom invoices
If we try to send any onion error with the `UPDATE` flag in
response to a phantom receipt, we should always swap it for
something generic that doesn't require a `channel_update` in it.
Here we use `temporary_node_failure`.
Test provided by Valentine Wallace <vwallace@protonmail.com>
Matt Corallo [Thu, 1 Dec 2022 23:30:04 +0000 (23:30 +0000)]
Replace `build_first_hop_failure_packet` with `HTLCFailReason`
This ensures we always hit our new debug assertions while building
failure packets in the immediately-fail pipeline while processing
an inbound HTLC.
Matt Corallo [Thu, 1 Dec 2022 23:39:28 +0000 (23:39 +0000)]
Use `temporary_node_failure` for a phantom HTLC with bogus CLTV
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.
Fixes #1879
Matt Corallo [Thu, 1 Dec 2022 20:31:52 +0000 (20:31 +0000)]
Assert that all onion error messages are correct len in tests
When we're constructing an HTLCFailReason, we should check that we
set the data to at least the correct length for the given failure
code, which we do here.
Matt Corallo [Thu, 1 Dec 2022 20:30:45 +0000 (20:30 +0000)]
Correctly include the `sha256_hash_of_onion` field in BADONION errs
The spec mandates that we copy the `sha256_hash_of_onion` field
from the `UpdateFailMalformedHTLC` message into the error message
we send back to the sender, however we simply ignored it. Here we
copy it into the message correctly.
Matt Corallo [Thu, 1 Dec 2022 20:25:33 +0000 (20:25 +0000)]
Drop the stale `final_expiry_too_soon` error code
This replaces `final_expiry_too_soon` with
`incorrect_or_unknown_payment` as was done in
https://github.com/lightning/bolts/pull/608. Note that the
rationale for this (that it may expose whether you are the final
recipient for the payment or not) does not currently apply to us -
we don't apply different final CLTV values to different payments.
However, we might in the future, and this will make us slightly
more consistent with other nodes.
Matt Corallo [Thu, 1 Dec 2022 19:28:32 +0000 (19:28 +0000)]
Encapsulate `HTLCFailReason` to not expose struct variants
Now that `HTLCFailReason` is opaque and in `onion_utils`, we should
encapsulate it so that `ChannelManager` can no longer directly
access its inner fields.
Matt Corallo [Thu, 1 Dec 2022 19:20:19 +0000 (19:20 +0000)]
Move `HTLCFailReason` to `onion_utils`
Now that it's entirely abstracted, there's no reason for
`HTLCFailReason` to be in `channelmanager`, it's really an
onion-level abstraction.
Matt Corallo [Tue, 6 Dec 2022 19:07:09 +0000 (19:07 +0000)]
Merge pull request #1902 from tnull/2022-12-payment-received-renaming-follow-up
Also rename variables referring to `PaymentClaimable`
Matt Corallo [Tue, 6 Dec 2022 18:51:49 +0000 (18:51 +0000)]
Move `claimable_htlcs` to a struct for more fields in the same mutex
Matt Corallo [Mon, 28 Nov 2022 23:51:55 +0000 (23:51 +0000)]
Correct confusing docs on `Channel` methods
The methods return `Ok(())` always, they just happen to never
return in the case of a duplicate claim if debug assertions are
enabled.
Matt Corallo [Mon, 21 Nov 2022 01:13:52 +0000 (01:13 +0000)]
Lean on the holding cell for commitments when updating fees
Like the previous commit, here we update the update_fee+commit
logic to simply push the fee update into the holding cell and then
use the standard holding-cell-freeing codepaths to actually send
the commitment update. This removes a substantial amount of code,
reducing redundant codepaths and keeping channel state machine
logic in channel.rs.
Matt Corallo [Mon, 21 Nov 2022 01:22:51 +0000 (01:22 +0000)]
Free the holding cells during background timer ticks
We currently free the channel holding cells in
`get_and_clear_pending_msg_events`, blocking outbound messages
while we do so. This is fine, but may block the message pipeline
longer than we need to. In the next commit we'll push
timer-originating channel fee updates out through the holding cell
pipeline, leaning more on that freeing in the future.
Thus, to avoid a regression in message time, here we clear the
holding cell after processing all timer events. This also avoids
needing to change tests in the next commit.
Matt Corallo [Sat, 19 Nov 2022 00:00:28 +0000 (00:00 +0000)]
Lean on the holding cell when batch-forwarding/failing HTLCs
When we batch HTLC updates, we currently do the explicit queueing
plus the commitment generation in the `ChannelManager`. This is a
bit strange as its ultimately really a `Channel` responsibility to
generate commitments at the correct time, with the abstraction
leaking into `ChannelManager` with the `send_htlc` and
`get_update_fail_htlc` method docs having clear comments about
how `send_commitment` MUST be called prior to calling other
`Channel` methods.
Luckily `Channel` already has an update queue - the holding cell.
Thus, we can trivially rewrite the batch update logic as inserting
the desired updates into the holding cell and then asking all
channels to clear their holding cells.
Matt Corallo [Tue, 6 Dec 2022 18:13:49 +0000 (18:13 +0000)]
Merge pull request #1867 from wpaulino/remove-signer-persistence
Re-derive signers instead of persisting them
Elias Rohrer [Tue, 6 Dec 2022 09:47:07 +0000 (10:47 +0100)]
Rename variables referring to `PaymentClaimable`
Matt Corallo [Mon, 5 Dec 2022 22:54:08 +0000 (22:54 +0000)]
Merge pull request #1857 from TheBlueMatt/2022-11-reload-htlc
Fail HTLCs which were removed from a channel but not persisted
Matt Corallo [Wed, 16 Nov 2022 02:20:03 +0000 (02:20 +0000)]
Fail HTLCs which were removed from a channel but not persisted
When a channel is force-closed, if a `ChannelMonitor` update is
completed but a `ChannelManager` persist has not yet happened,
HTLCs which were removed in the latest (persisted) `ChannelMonitor`
update will not be failed even though they do not appear in the
commitment transaction which went on chain. This is because the
`ChannelManager` thinks the `ChannelMonitor` is responsible for
them (as it is stale), but the `ChannelMonitor` has no knowledge of
the HTLC at all (as it is not stale).
The fix for this is relatively simple - we need to check for this
specific case and fail back such HTLCs when deserializing a
`ChannelManager`
Matt Corallo [Thu, 17 Nov 2022 05:55:45 +0000 (05:55 +0000)]
Avoid attempting to forward to a closed chan on stale-data reload
If, after forwarding a payment to our counterparty, we restart with
a ChannelMonitor update having been persisted, but the
corresponding ChannelManager update was not persisted, we'll still
have the forwarded HTLC in the `forward_htlcs` map on start. This
will cause us to generate a (spurious) `PendingHTLCsForwardable`
event. However, when we go to forward said HTLC, we'll notice the
channel has been closed and leave it up to the `ChannelMontior` to
finalize the HTLC.
This is all fine today - we won't lose any funds, we'll just
generate an excess forwardable event and then fail to forward.
However, in the future when we allow for forward-time channel
changes this could break. Thus, its worth adding tests for this
behavior today, and, while we're at it, removing the spurious
forwardable HTLCs event.
Matt Corallo [Tue, 15 Nov 2022 23:35:31 +0000 (23:35 +0000)]
Expose the full set of outbound HTLCs from a `ChannelMonitor`
This expands the outbound-HTLC-listing support in `ChannelMonitor`
to include not only the set of outbound HTLCs which have not yet
been resolved but to also include the full set of HTLCs which the
`ChannelMonitor` is currently able to to or has already finalized.
This will be used in the next commit to fail-back HTLCs which were
removed from a channel in the ChannelMonitor but not in a Channel.
Using the existing `get_pending_outbound_htlcs` for this purpose is
subtly broken - if the channel is already closed, an HTLC fail may
have completed on chain and is no longer "pending" to the monitor,
but the fail event is still in the monitor waiting to be handed
back to the `ChannelMonitor` when polled.
Wilmer Paulino [Thu, 1 Dec 2022 22:45:46 +0000 (14:45 -0800)]
Remove unnecessary byte_utils helpers
Now that to_be_bytes is available under our current MSRV of 1.41, we
can use it instead of our own version.
Wilmer Paulino [Tue, 29 Nov 2022 17:06:31 +0000 (09:06 -0800)]
Drop Clone requirement from Sign
Now that we opt to always re-derive channel secrets whenever required,
we can drop the Clone requirement from Sign.
Wilmer Paulino [Mon, 21 Nov 2022 21:34:22 +0000 (13:34 -0800)]
Avoid use of OnlyReadsKeysInterface
Since `ChannelMonitor`s will now re-derive signers rather than
persisting them, we can no longer use the OnlyReadsKeysInterface
concrete implementation.
Wilmer Paulino [Mon, 21 Nov 2022 20:49:05 +0000 (12:49 -0800)]
Re-derive signers upon deserializing OnchainTxHandler
Similar to the previous commit, we introduce a new serialization version
that doesn't store a monitor's signer. Since the monitor already knows
of a channel's `channel_keys_id`, there's no need to store any new data
to re-derive all private key material for said channel.
Wilmer Paulino [Mon, 21 Nov 2022 20:47:41 +0000 (12:47 -0800)]
Re-derive signers upon deserializing Channel
To do so, we introduce a new serialization version that doesn't store a
channel's signer, and instead stores its signer's `channel_keys_id`.
This is a unique identifier that can be provided to our `KeysInterface`
to re-derive all private key material for said channel.
We choose to not upgrade the minimum compatible serialization version
until a later time, which will also remove any signer serialization
logic on implementations of `KeysInterface` and `Sign`.
Wilmer Paulino [Tue, 29 Nov 2022 17:05:47 +0000 (09:05 -0800)]
Rename KeysInterface ready_channel to provide_channel_parameters
Now that ready_channel is also called on startup upon deserializing
channels, we opt to rename it to a more indicative name.
We also derive `PartialEq` on ChannelTransactionParameters to allow
implementations to determine whether `provide_channel_parameters` calls
are idempotent after the channel parameters have already been provided.
Wilmer Paulino [Mon, 21 Nov 2022 20:45:30 +0000 (12:45 -0800)]
Split KeysInterface::get_channel_signer into two
`get_channel_signer` previously had two different responsibilites:
generating unique `channel_keys_id` and using said ID to derive channel
keys. We decide to split it into two methods `generate_channel_keys_id`
and `derive_channel_signer`, such that we can use the latter to fulfill
our goal of re-deriving signers instead of persisting them. There's no
point in storing data that can be easily re-derived.
Matt Corallo [Sun, 4 Dec 2022 19:31:52 +0000 (19:31 +0000)]
Merge pull request #1891 from tnull/2022-12-rename-payment-events
Rename `PaymentReceived` to `PaymentClaimable`
Elias Rohrer [Sat, 3 Dec 2022 06:06:22 +0000 (07:06 +0100)]
Update docs and add pending changelog
Matt Corallo [Sat, 3 Dec 2022 19:01:15 +0000 (19:01 +0000)]
Merge pull request #1887 from TheBlueMatt/2022-11-definitely-valid
Remove cryptographically unreachable error conditions
Jeffrey Czyz [Mon, 28 Nov 2022 17:58:39 +0000 (12:58 -0500)]
Remove unused mut from OfferBuilder::amount_msats
Seen when removing `#[allow(unused)]` from `offers` module.
Jeffrey Czyz [Fri, 2 Dec 2022 23:26:27 +0000 (15:26 -0800)]
Reduce visibility for offer auxiliary types
Matt Corallo [Thu, 1 Dec 2022 21:51:39 +0000 (21:51 +0000)]
Merge pull request #1893 from valentinewallace/2022-12-jit-forwards-followup
HTLC JIT channel interception followup + minor cleanups
Matt Corallo [Thu, 1 Dec 2022 19:18:16 +0000 (19:18 +0000)]
Construct from-message `HTLCFailReason` via a constructor method
Matt Corallo [Thu, 1 Dec 2022 19:14:43 +0000 (19:14 +0000)]
Fix `impl_writeable_tlv_based_enum` to not require `DecodeError`
`impl_writeable_tlv_based_enum` shouldn't be assuming that
`DecodeError` is in scope, which we address here.
Matt Corallo [Thu, 1 Dec 2022 19:08:53 +0000 (19:08 +0000)]
Decode `HTLCFailReason`s in a util method on the enum
Matt Corallo [Thu, 1 Dec 2022 18:56:17 +0000 (18:56 +0000)]
Encode HTLC failure packets in a util method on `HTLCFailReason`
Matt Corallo [Thu, 1 Dec 2022 18:03:35 +0000 (18:03 +0000)]
Merge pull request #1880 from tcharding/11-29-move-lock-outside-loop
Do not lock while looping `htlcs_to_fail`
Elias Rohrer [Thu, 1 Dec 2022 08:34:34 +0000 (09:34 +0100)]
Rename `PaymentReceived` to `PaymentClaimable`
Valentine Wallace [Thu, 1 Dec 2022 06:08:55 +0000 (01:08 -0500)]
Rename APIError::RouteError to ::InvalidRoute
Soon we're going to need to return an error when ChannelManager is unable to
find a route, so we'll need a way to distinguish between that and the user
supplying an invalid route.
Valentine Wallace [Fri, 28 Oct 2022 15:26:40 +0000 (11:26 -0400)]
Fix weird import format in persist
Valentine Wallace [Thu, 1 Dec 2022 05:16:31 +0000 (00:16 -0500)]
HTLC intercept test: swap hardcoded value for const
Valentine Wallace [Thu, 1 Dec 2022 05:13:53 +0000 (00:13 -0500)]
Test for unknown HTLC intercept id error
Valentine Wallace [Thu, 1 Dec 2022 05:12:29 +0000 (00:12 -0500)]
Clean up HTLC intercept errors
ChannelUnavailable is a better fit for errors regarding unavailable channels
than APIMisuseError.
Also log bytes in errors as hex instead of decimal.
Matt Corallo [Thu, 1 Dec 2022 04:24:10 +0000 (04:24 +0000)]
Merge pull request #1862 from valentinewallace/2022-11-chanman-retries-prep
Prepare for Payment Retries in `ChannelManager`
Tobin C. Harding [Tue, 29 Nov 2022 01:24:12 +0000 (12:24 +1100)]
Do not lock while looping htlcs_to_fail
Currently we loop over `htlcs_to_fail` locking `channel_state` for each
element only to call `get_htlc_inbound_temp_fail_err_and_data` with the
same inputs on each iteration. This is unnecessary, we can refactor and
call `get_htlc_inbound_temp_fail_err_and_data` outside of the loop.
Tobin C. Harding [Tue, 29 Nov 2022 00:59:59 +0000 (11:59 +1100)]
Make fail_htlc_backwards_internal borrow parameters
Currently `fail_htlc_backwards_internal` takes ownership of its source
and reason parameters however they are not consumed so we can borrow them.
Includes refactoring to use local variables before the function call.
Tobin C. Harding [Tue, 29 Nov 2022 00:41:14 +0000 (11:41 +1100)]
Add constructors to HTLCFailReason
We create `HTLCFailReason` inline in function calls in a bunch of places
in the `channelmanager` module, we can make the code more terse with no
loss of clarity by implementing a couple of constructor methods.
Matt Corallo [Thu, 1 Dec 2022 00:04:14 +0000 (00:04 +0000)]
Merge pull request #1835 from valentinewallace/2022-11-jit-chan-htlc-intercept
Intercept HTLC forwards for JIT channels
Matt Corallo [Wed, 30 Nov 2022 22:43:29 +0000 (22:43 +0000)]
Remove unreachable `Err` cases when constructing `TxCreationKeys`
Matt Corallo [Wed, 30 Nov 2022 22:34:11 +0000 (22:34 +0000)]
Remove unreachable `Err` cases on `derive_*_revocation_key`
The `derive_{public,private}_revocation_key` methods hash the two
input keys and then multiply the two input keys by hashed values
before adding them together. Because addition can fail if the tweak
is the inverse of the secret key this method currently returns a
`Result`.
However, it is not cryptographically possible to reach the error
case - in order to create an issue, the point-multiplied-by-hash
values must be the inverse of each other, however each point
commits the SHA-256 hash of both keys together. Thus, because
changing either key changes the hashes (and the ultimate points
added together) in an unpredictable way, there should be no way to
construct such points.
Matt Corallo [Wed, 30 Nov 2022 22:21:24 +0000 (22:21 +0000)]
Remove unreachable `Err` cases on `derive_{public,private}_key`
The `derive_{public,private}_key` methods hash the two input keys
and then add them to the input public key. Because addition can
fail if the tweak is the inverse of the secret key this method
currently returns a `Result`.
However, it is not cryptographically possible to reach the error
case - in order to create an issue, the SHA-256 hash of the
`base_point` (and other data) must be the inverse of the
`base_point`('s secret key). Because changing the `base_point`
changes the hash in an unpredictable way, there should be no way to
construct such a `base_point`.
Valentine Wallace [Mon, 21 Nov 2022 22:07:44 +0000 (17:07 -0500)]
Move DefaultRouter to router module
Valentine Wallace [Mon, 21 Nov 2022 20:51:28 +0000 (15:51 -0500)]
Move ScorerAccountingForInFlightHtlcs to router + make public
We move it to router instead of scoring because it pairs with the InFlightHtlcs
struct in router and is useful for custom Router trait implementations
Matt Corallo [Wed, 30 Nov 2022 18:56:15 +0000 (18:56 +0000)]
Merge pull request #1839 from ariard/2022-11-increase-visibility-helpers
Chan_utils helpers visibility relaxation
Valentine Wallace [Wed, 23 Nov 2022 00:15:56 +0000 (19:15 -0500)]
Don't forward HTLC intercepts over unestablished channels
Valentine Wallace [Mon, 14 Nov 2022 20:05:37 +0000 (15:05 -0500)]
Automatically fail intercepts back on timeout
Valentine Wallace [Mon, 14 Nov 2022 18:36:52 +0000 (13:36 -0500)]
Add config knob for forwarding intercept payments
Valentine Wallace [Mon, 7 Nov 2022 16:16:49 +0000 (11:16 -0500)]
Allow failing back intercepted HTLCs
Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Valentine Wallace [Sun, 6 Nov 2022 21:06:44 +0000 (16:06 -0500)]
Utils for forwarding intercepted htlcs + getting intercept scids
See ChannelManager::forward_intercepted_htlc and
ChannelManager::get_intercept_scid for details
Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Valentine Wallace [Fri, 4 Nov 2022 20:23:47 +0000 (16:23 -0400)]
Generate HTLCIntercepted event upon interceptable forward
And store the pending intercepted HTLC in pending_intercepted_htlcs
Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Valentine Wallace [Fri, 4 Nov 2022 18:25:41 +0000 (14:25 -0400)]
Add HTLCIntercepted event
Used in upcoming commit(s) so users can intercept forwarded HTLCs
Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Valentine Wallace [Fri, 4 Nov 2022 15:54:57 +0000 (11:54 -0400)]
Add fake scid namespace for intercepted HTLCs
This is useful for LSPs who wish to create a just-in-time channel for end users
receiving a lightning payment. These fake scids will be encoded into route
hints in end user invoices, and signal to LDK to create an event triggering the
JIT channel, after which the payment will be received.
Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>