After #3513 we have a bit more encapsulation of channel logic in
channel.rs with channelmanager.rs needing a bit less knowledge of
which specific state a channel is in.
This continues that trend slightly when a peer reconnects.
After #3513 we have a bit more encapsulation of channel logic in
channel.rs with channelmanager.rs needing a bit less knowledge of
which specific state a channel is in.
This continues that trend slightly when a peer disconnects.
After #3513 we have a bit more encapsulation of channel logic in
channel.rs with channelmanager.rs needing a bit less knowledge of
which specific state a channel is in.
This continues that trend slightly when unblocking the signer.
Support more ergonomically sending payments to specific routes.
We removed the original version of this API because it was hard to work with,
but the concept of sending a payment to a specific route is still useful.
Previously, users were able to do this via manually matching the payment id in
their router, but that's cumbersome when we could just handle it internally.
Previously, we would prune tracked descriptors once we see a spend hit
`ANTI_REORG_DELAY = 6` confirmations. However, this could lead to a
scenario where lingering `ChannelMonitor`s waiting to be archived would
still regenerate and replay `Event::SpendableOutput`s, i.e., we would
re-add the same (now unspendable due to be actually being already spent)
outputs again after having intially pruned them.
Here, we therefore keep the tracked descriptors around for longer, in
particular at least `ARCHIVAL_DELAY_BLOCKS + ANTI_REORG_DELAY = 4038`
confirmations, at which point we assume the lingering monitors to have
been likely archived, and it's 'safe' for us to also forget about the
descriptors.
Now that ChannelPhase is encapsulated in Channel, phase transitions can
be moved from ChannelManager to Channel. Update the tx_complete phase
transition accordingly. This allows for simpler logic in ChannelManager
since the channel does not need to removed and then re-added into the
channel_by_id map.
Now that ChannelPhase is encapsulated in Channel, phase transitions can
be moved from ChannelManager to Channel. Update the funding_signed phase
transition accordingly. This allows for simpler logic in ChannelManager
since the channel does not need to removed and then readded into the
channel_by_id map.
When moving ChannelPhase logic from ChannelManager into Channel, it is
useful to error when a Channel is not in the expected state. Add a
ChannelError::SendError variant for this purpose, which results in
sending an error message without closing the channel.
When attempting a ChannelPhase transition, the variant-specific channel
struct needs to be taken by self in order to move its ChannelContext
into the struct for the new phase. Add a variant for an intermediate
state, allowing such actions.
Instead of exposing the Channel enum variants, make a Channel struct
that wraps a ChannelPhase enum. This allows updating a Channel's phase
without consuming it, which isn't possible when it is in a map without
removing the entry first (e.g., as is done in ChannelManager).
Here we bubble up the payment context into PendingHTLCRouting::ReceiveKeysend
and check it when receiving a spontaneous payment prior to generating a
claimable event. Prior to this patch, we would have accepted out-of-context
keysends sent over blinded paths taken from our BOLT 12 invoices.
As a side effect of this, our blinded keysend success test cases now fail, so
those tests are now removed. Their coverage is re-added in future commits when
we add support for async receive, meaning we're able to receive blinded
keysends in the correct payment context.
While we could avoid storing the payment context for the purposes of this
bugfix, we go ahead and store it now because it will be needed when support for
receiving async payments is added.
Prior to this patch, if we received an expired static invoice we would delay
surfacing the payment failure until after the recipient had come online and
sent the release_held_htlc OM, which could be a long time later. Now, we'll
detect that the invoice is expired as soon as it's received.
Needed to authenticate that the held_htlc_available message is being sent over
a reply path that we originally created and that isn't expired before we reply
with release_held_htlc. This context will be used in upcoming commits when we
add support for async receive.
Blinded HTLCs are always failed back with the same error, so DRY the test code
that fails them backwards. This util will also be used for async payments
testing in upcoming commits.
When an outbound payment fails while paying to a route, we need to remove the
session_privs for each failed path in the outbound payment.
Previously we were sometimes removing in pay_route_internal and sometimes in
handle_pay_route_err, so refactor this so we always remove in
handle_pay_route_err.
Previously, the `feerate_bump` method did not enforce the dust
threshold, which could result in us thinking we had raised the fee
rate without actually having done so. Instead,
`compute_package_output` blindly accepted the updated fee rate while
enforcing a non-dust output value, resulting in repeated broadcast
attempts of an identical transaction.
If we've signed the latest holder tx (i.e. we've force-closed and
broadcasted our state), there's not much reason to accept
counterparty-transaction-updating `ChannelMonitorUpdate`s, we
should make sure the `ChannelManager` fails the channel as soon as
possible.
This standardizes the failure cases to also match those added to
the previous commit, which makes things a bit more readable.
Fail inbound HTLCs if they expire within a certain number of blocks from
the current height. If we haven't seen the preimage for an HTLC by the
time the previous hop's timeout expires, we've lost that HTLC, so we
might as well fail it back instead of having our counterparty
force-close the channel.
Co-authored-by: Matt Corallo <git@bluematt.me>
This field was used to test that any HTLC failures didn't come
in after an HTLC was fulfilled (indicating, somewhat dubiously,
that there may be a bug causing us to fail when we shouldn't have).
In the next commit, we'll be failing HTLCs based on on-chain HTLC
expiry, but may ultimately receive the preimage thereafter. This
would make the `historical_inbound_htlc_fulfills` checks
potentially-brittle, so we just remove them as they have dubious
value.
In a coming commit we'll expire HTLCs backwards even if we haven't
yet claimed them on-chain based on their inbound edge being close
to causing a channel force-closure.
Here we track and expose the incoming edge's CLTV expiry in the
`HTLCSource`, giving `ChannelMonitor` access to it.
Co-authored-by: Matt Corallo <git@bluematt.me>
In a coming commit we'll expire HTLCs backwards even if we haven't
yet claimed them on-chain based on their inbound edge being close
to causing a channel force-closure.
Here we track the incoming edge's CLTV expiry in the
pending-routing state so that we can include it in the `HTLCSource`
in the next commit.
Co-authored-by: Matt Corallo <git@bluematt.me>
PR #3323 introduced some extra variables to avoid `rustfmt` making
a total mess of our code, but introduced a few that don't make
`rustfmt` do dumb things, which we remove here.
Note:
The `actions_blocking_raa_monitor_updates` list may contain stale entries
in the form of `(channel_id, [])`, which do not represent actual dangling actions.
To handle this, stale entries are ignored when accumulating pending actions
before clearing them. This ensures that the logic focuses only on relevant
actions and avoids unnecessary accumulation of already processed data.
