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.
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.
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: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 [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`.
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>
Matt Corallo [Fri, 18 Nov 2022 19:02:02 +0000 (19:02 +0000)]
Add additional testing in `montior_tests` for chain idempotency
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.
Matt Corallo [Fri, 18 Nov 2022 18:54:16 +0000 (18:54 +0000)]
Ensure `transactions_confirmed` is idempotent
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.
Matt Corallo [Mon, 21 Nov 2022 20:37:25 +0000 (20:37 +0000)]
Drop verbose log entries in BP when no network graph is provided
If no network graph is provided to the `BackgroundProcessor`, we
log every time the processor loop goes around (at least every
100ms, if not more) which fille up logs with useless indications
that we have no network graph.
Don't hold `per_peer_state` lock during chain monitor update
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.
Lock pending inbound and outbound payments to before `channel_state`
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.
Matt Corallo [Mon, 21 Nov 2022 18:43:48 +0000 (18:43 +0000)]
Remove the `post_handle_chan_restoration` macro
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.
jurvis [Thu, 17 Nov 2022 01:50:30 +0000 (17:50 -0800)]
Remove `paths` from `PaymentInfo` in `payment_cache`
In c70bd1f, we implemented tracking HTLCs by adding path information
for pending HTLCs to `InvoicePayer`’s `payment_cache` when receiving
specific events.
Since we can now track inflight HTLCs entirely within ChannelManager,
there is no longer a need for this to exist.
Matt Corallo [Fri, 18 Nov 2022 22:51:17 +0000 (22:51 +0000)]
Explicitly track the set of spendable transactions which confirm
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.
Matt Corallo [Thu, 10 Nov 2022 01:01:31 +0000 (01:01 +0000)]
Handle `transaction_unconfirmed` as a full reorg to the tx height
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.
Matt Corallo [Fri, 18 Nov 2022 18:49:16 +0000 (18:49 +0000)]
Fix one test still connecting invalid blocks
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.
BOLT 12 messages are limited to a range of TLV record types. Refactor
decode_tlv_stream into a decode_tlv_stream_range macro for limiting
which types are parsed. Requires a SeekReadable trait for rewinding when
a type outside of the range is seen. This allows for composing TLV
streams of different ranges.
Updates offer parsing accordingly and adds a test demonstrating failure
if a type outside of the range is included.
Jeffrey Czyz [Thu, 11 Aug 2022 21:51:06 +0000 (16:51 -0500)]
Offer parsing from bech32 strings
Add common bech32 parsing for BOLT 12 messages. The encoding is similar
to bech32 only without a checksum and with support for continuing
messages across multiple parts.
Messages implementing Bech32Encode are parsed into a TLV stream, which
is converted to the desired message content while performing semantic
checks. Checking after conversion allows for more elaborate checks of
data composed of multiple TLV records and for more meaningful error
messages.
The parsed bytes are also saved to allow creating messages with mirrored
data, even if TLV records are unknown.
Matt Corallo [Thu, 17 Nov 2022 17:52:31 +0000 (17:52 +0000)]
Convert the `handle_chan_restoration_locked` macro to a function
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
Matt Corallo [Thu, 17 Nov 2022 05:48:21 +0000 (05:48 +0000)]
Wait to free the holding cell during channel_reestablish handling
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
Matt Corallo [Thu, 17 Nov 2022 04:30:36 +0000 (04:30 +0000)]
Remove log assertions in `chanmon_update_fail_tests`
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
Elias Rohrer [Wed, 16 Nov 2022 09:54:25 +0000 (10:54 +0100)]
Mention `user_channel_id` rand. version req.
As it was previously omitted, we clarify here starting from which version users can expect the `user_channel_id` to be randomized for inbound channels.
Matt Corallo [Tue, 15 Nov 2022 00:46:22 +0000 (00:46 +0000)]
Accept feerate increases even if they aren't high enough for us
LND nodes have very broken fee estimators, causing them to suggest
feerates that don't even meet a current mempool minimum feerate
when fees go up over the course of hours. This can cause us to
reject their feerate estimates as they're not high enough, even
though their new feerate is higher than what we had already (which
is the feerate we'll use to broadcast a closing transaction). This
implies we force-close the channel and broadcast something with a
feerate lower than our counterparty was offering.
Here we simply accept such feerates as they are better than what we
had. We really should also close the channel, but only after we
get their signature on the new feerate. That should happen by
checking channel feerates every time we see a new block so is
orthogonal to this code.
Ultimately the fix is anchor outputs plus package-based relay in
Bitcoin Core, however we're still quite some ways from that, so
worth needlessly closing channels for now.
Matt Corallo [Tue, 15 Nov 2022 00:29:10 +0000 (00:29 +0000)]
Await `Future::poll` `Complete`d before unsetting notify-required
When we mark a future as complete, if the user is using the
`std::future::Future` impl to get notified, we shouldn't just
assume we have completed the `Future` when we call the `Waker`. A
`Future` may have been `drop`'d at that point (or may not be
`poll`'d again) even though we wake the `Waker`.
Because we now have a `callbacks_made` flag, we can fix this rather
trivially, simply not setting the flag until the `Future` is
`poll`'d `Complete`.
Matt Corallo [Tue, 15 Nov 2022 00:24:25 +0000 (00:24 +0000)]
Wipe `Notifier` `FutureState` when returning from a waiter.
When we return from one of the wait functions in `Notifier`, we
should also ensure that the next `Future` doesn't start in the
`complete` state, as we have already notified the user, as far as
we're concerned.
This is technically a regression from the previous commit, but as
it is a logically separate change it is in its own commit.
Matt Corallo [Mon, 14 Nov 2022 23:49:27 +0000 (23:49 +0000)]
Unset the needs-notify bit in a Notifier when a Future is fetched
If a `Notifier` gets `notify()`ed and the a `Future` is fetched,
even though the `Future` is marked completed from the start and
the user may pass callbacks which are called, we'll never wipe the
needs-notify bit in the `Notifier`.
The solution is to keep track of the `FutureState` in the returned
`Future` even though its `complete` from the start, adding a new
flag in the `FutureState` which indicates callbacks have been made
and checking that flag when waiting or returning a second `Future`.
Elias Rohrer [Mon, 24 Oct 2022 08:30:11 +0000 (10:30 +0200)]
Make `user_channel_id` a `u128`
We increase the `user_channel_id` type from `u64` to `u128`. In order to
maintain backwards compatibility, we have to de-/serialize it as two
separate `u64`s in `Event` as well as in the `Channel` itself.
Elias Rohrer [Fri, 21 Oct 2022 09:05:18 +0000 (11:05 +0200)]
Randomize `user_channel_id` for inbound channels
Previously, all inbound channels defaulted to a `user_channel_id` of 0,
which didn't allow for them being discerned on that basis. Here, we
simply randomize the identifier to fix this and enable the use of
`user_channel_id` as a true identifier for channels (assuming an equally
reasonable value is chosen for outbound channels and given upon
`create_channel()`).
projects / rust-lightning / log