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.
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.
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.
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>
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>
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>
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>
No htlcs are intercepted yet, that will be added in upcoming commit(s)
Co-authored-by: John Cantrell <johncantrell97@gmail.com>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
At the end of our `monitor_tests`, which test `ChannelMonitor`
`SpendableOutputs` and claimable `Balance`s, add new checks that
ensure that, if we're using the new
`ConnectStyle::HighlyRedundantTransactionsFirstSkippingBlocks`, we
can replay the full chain without getting redundant events or
`Balance`s.
In many complexity-reduced implementations of chain syncing using
esplora `transactions_confirmed` may be called redundantly for
transactions which were already confirmed. To ensure this is
idempotent we add two new `ConnectionStyle`s in our tests which
(a) call `transactions_confirmed` twice for each call, ensuring
simple idempotency is ensured and (b) call `transactions_confirmed`
once for each historical block every time we're connecting a new
block, ensuring we're fully idempotent even if every call is
repeated constantly.
In order to actually behave correctly this requires a simple
already-confirmed check in `ChannelMonitor`, which is included.
For Windows build only, the
`TestPersister::chain_sync_monitor_persistences` lock has a lock order
before the `ChannelManager::per_peer_state` lock. This fix ensures that
the `per_peer_state` lock isn't held before the
`TestPersister::chain_sync_monitor_persistences` lock is acquired.
As the `channel_state` lock will be removed, we prepare for that by
flipping the lock order for `pending_inbound_payments` and
`pending_outbound_payments` locks to before the `channel_state` lock.
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
In `ChannelMonitor`s, when a transaction containing a spend of a
revoked remote output reaches 6 confs, we may have no other
tracking of that txid remaining. Thus, if we see that transaction
again (because a user duplicatively confirms it), we'll generate a
redundant spendable output event for it.
Here we simply explicitly track all txids of transactions which
confirm with a spendable output, allowing us to check this
condition in the next commit.
In `ChannelMonitor`, if we see a `transaction_unconfirmed` for a
transaction we last saw in a block at height X, we shouldn't
*only* remove the `onchain_events_awaiting_threshold_conf` entry
for the given tx but rather for all transactions that we last saw
at height >= X.
This avoids any potential `onchain_events_awaiting_threshold_conf`
inconsistencies due to the order in whcih users mark transactions
unconfirmed (which the `chain::Confirm` docs do not currently set
any requirements on).
This also matches the `OnchainTxHandler` behavior, which does the
same lookup.
In the next commit we'll add some checks that redundant
transactions aren't confirmed in different blocks, which would
cause test_htlc_ignore_latest_remote_commitment to fail. Here we
fix it to avoid the issue.
