Matt Corallo [Sat, 1 Jun 2024 22:45:04 +0000 (22:45 +0000)]
Use `NodeCounters` `NodeId`s as the blinded path intro references
The router's `introduction_node_id_cache` is used to cache the
`NodeId`s of blinded path introduction points so that we don't
have to look them up every time we go around the main router loop.
When using it, if the introduction point isn't a public node we
then look up the introduction in our first-hops map.
In either case, we have to end up with a reference to a `NodeId`
that outlives our `dist` map.
Here we consolidate both the initial cache building and the
first-hops map lookup to one place, storing only a reference to a
`NodeId` either in the `NetworkGraph` or in the new `NodeCounters`
to get the required lifetime without needing to reference into the
first-hops map.
We then take this opportunity to avoid `clone`ing the first-hops
map entries as we now no longer reference into it.
Matt Corallo [Sat, 1 Jun 2024 18:19:45 +0000 (18:19 +0000)]
Drop `private_hop_key_cache` in favor of `NodeCounters`
With the new `NodeCounters` have have a all the `NodeId`s we'll
need during routing, so there's no need to keep the
`private_hop_key_cache` which existed to provide references to
`NodeId`s which are needed during routing.
Matt Corallo [Tue, 19 Mar 2024 19:29:06 +0000 (19:29 +0000)]
Add a new `NodeCounters` utility to track counters when routing
In the next commit we'll stop using `NodeId`s to look up nodes when
routing, instead using the new per-node counters. Here we take the
first step, adding a local struct which tracks temporary counters
for route hints/source/destination nodes.
Because we must ensure we have a 1-to-1 mapping from node ids to
`node_counter`s, even across first-hop and last-hop hints, we have
to be careful to check the network graph first, then a new
`private_node_id_to_node_counter` map to ensure we only ever end up
with one counter per node id.
Matt Corallo [Thu, 7 Dec 2023 04:32:06 +0000 (04:32 +0000)]
Store the source and destination `node_counter`s in `ChannelInfo`
In the next commit, we'll use the new `node_counter`s to remove a
`HashMap` from the router, using a `Vec` to store all our per-node
information. In order to make finding entries in that `Vec` cheap,
here we store the source and destintaion `node_counter`s in
`ChannelInfo`, givind us the counters for both ends of a channel
without doing a second `HashMap` lookup.
Matt Corallo [Thu, 7 Dec 2023 04:12:04 +0000 (04:12 +0000)]
Track a `counter` for each node in our network graph
These counters are simply a unique number describing each node.
They have no specific meaning, but start at 0 and count up, with
counters being reused after a node has been deleted.
Alec Chen [Thu, 30 May 2024 22:09:56 +0000 (17:09 -0500)]
Get per commitment point everywhere else with HolderCommitmentPoint
This includes when building TxCreationKeys, as well as for open_channel
and accept_channel messages. Note: this is only for places where we are
retrieving the current per commitment point, which excludes
channel_reestablish.
Matt Corallo [Sun, 5 May 2024 23:22:23 +0000 (23:22 +0000)]
Force-close channels if their feerate gets stale without any update
For quite some time, LDK has force-closed channels if the peer
sends us a feerate update which is below our `FeeEstimator`'s
concept of a channel lower-bound. This is intended to ensure that
channel feerates are always sufficient to get our commitment
transaction confirmed on-chain if we do need to force-close.
However, we've never checked our channel feerate regularly - if a
peer is offline (or just uninterested in updating the channel
feerate) and the prevailing feerates on-chain go up, we'll simply
ignore it and allow our commitment transaction to sit around with a
feerate too low to get confirmed.
Here we rectify this oversight by force-closing channels with stale
feerates, checking after each block. However, because fee
estimators are often buggy and force-closures piss off users, we
only do so rather conservatively. Specifically, we only force-close
if a channel's feerate is below the minimum `FeeEstimator`-provided
minimum across the last day.
Further, because fee estimators are often especially buggy on
startup (and because peers haven't had a chance to update the
channel feerates yet), we don't force-close channels until we have
a full day of feerate lower-bound history.
This should reduce the incidence of force-closures substantially,
but it is expected this will still increase force-closures somewhat
substantially depending on the users' `FeeEstimator`.
Matt Corallo [Fri, 31 May 2024 17:42:49 +0000 (17:42 +0000)]
Skip fee reads in `full_stack_target` when connecting many blocks
When we connect 100 blocks in a row, requiring the fuzz input to
contain 100 fee estimator results is uneccessary, so add a bool
that lets us skip those reads.
Matt Corallo [Sun, 5 May 2024 23:21:13 +0000 (23:21 +0000)]
Add a new `ClosureReason::PeerFeerateTooLow`
Closure due to feerate disagreements are a specific closure reason
which admins can understand and tune their config (in the form of
their `FeeEstimator`) to avoid, so having a separate
`ClosureReason` for it is useful.
Matt Corallo [Sun, 5 May 2024 23:52:08 +0000 (23:52 +0000)]
Use `ChannelError::close` constructor when building a close variant
In the next commit we'll add a second field to
`ChannelError::Close` so here we prep by converting existing calls
to the constructor function, which is almost a full-file sed.
Elias Rohrer [Thu, 6 Jun 2024 07:18:04 +0000 (09:18 +0200)]
Make `confirmables` `Deref`
.. the bindings branch needed a small patch as it doesn't support `dyn`
traits. Here, we opt to use `Deref` in the hopes this works with
bindings, rendering the patch unnecessary.
Jeffrey Czyz [Tue, 4 Jun 2024 23:48:07 +0000 (18:48 -0500)]
Exclude disconnected peers from BlindedPath
When calling MessageRouter::create_blinded_path, ChannelManager was
including disconnected peers. Filter peers such that only connected ones
are included. Otherwise, the resulting BlindedPath may not work.
Jeffrey Czyz [Tue, 28 May 2024 23:43:45 +0000 (18:43 -0500)]
Use compact blinded paths for short-lived offers
When an offer is short-lived, the likelihood of a channel used in a
compact blinded path going away is low. Require passing the absolute
expiry of an offer to ChannelManager::create_offer_builder so that it
can be used to determine whether or not compact blinded path should be
used.
Use the same criteria for creating blinded paths for refunds as well.
Jeffrey Czyz [Wed, 22 May 2024 21:35:57 +0000 (16:35 -0500)]
Don't use compact blinded paths for reply paths
There's no need to save space when creating reply paths since they are
part of onion messages rather than in QR codes. Use normal blinded paths
for these instead as they are less likely to become invalid in case of
channel closure.
Jeffrey Czyz [Wed, 22 May 2024 20:32:32 +0000 (15:32 -0500)]
Refactor MessageRouter::create_blinded_paths
Using compact blinded paths isn't always necessary or desirable. For
instance, reply paths are communicated via onion messages where space
isn't a premium unlike in QR codes. Additionally, long-lived paths could
become invalid if the channel associated with the SCID is closed.
Refactor MessageRouter::create_blinded_paths into two methods: one for
compact blinded paths and one for normal blinded paths.
Jeffrey Czyz [Wed, 22 May 2024 19:43:05 +0000 (14:43 -0500)]
Move DefaultMessageRouter::create_blinded_paths
An upcoming change to the MessageRouter trait will require reusing
DefaultMessageRouter::create_blinded_paths. Move the code to a utility
function so facilitate this.
Matt Corallo [Tue, 4 Jun 2024 14:46:15 +0000 (14:46 +0000)]
Move serialization of `channel_state` fields to `channel_state.rs`
1f616c0058f77e074c429fa7fb8b2f4594cdb9ad moved a handful of structs
to the new `channel_state.rs` but forgot to move their
serialization logic with them, which is corrected here.
Matt Corallo [Tue, 4 Jun 2024 01:06:54 +0000 (01:06 +0000)]
Move the public channel state API into a new module
Our "what is the channel's current state" structs have slowly
grown to be rather nontrivial, and now include eight structs with
many fields. Thus, it makes sense to pull them out of
`ln::channelmanager` and into their own module.
This also makes things easier for the C bindings which don't
support `pub use` from a private module.
G8XSU [Fri, 31 May 2024 22:26:57 +0000 (15:26 -0700)]
Watch all outputs irrespective of claimable outpoints.
This removes dependency of watched_outputs from
per_commitment_claimable_outpoints, it is required since we will
no longer have direct access to per_commitment_claimable_outpoints
once we start publishing PersistClaimInfo as part of #3049.
Matt Corallo [Fri, 10 May 2024 21:28:50 +0000 (21:28 +0000)]
Drop `EventsProvider` bounds on `OnionMessageHandler`s
This never really made a lot of sense from an API perspective, but
was required to avoid handing the background processor an explicit
`OnionMessegner`, which we are now doing. Thus, we can simply drop
these bounds as unnecessary.
Matt Corallo [Fri, 10 May 2024 21:07:08 +0000 (21:07 +0000)]
Switch to using the `OnionMessenger` directly in BP
When `OnionMessenger` first developed a timer and events interface,
we accessed the `OnionMessenger` indirectly via the `PeerManager`.
While this is a fairly awkward interface, it avoided a large pile
of generics on the background processor interfaces. However, since
we now have an `AOnionMessenger` trait, this concern is no longer
significant. Further, because we now want to use the built-in
`OnionMessenger` async event processing method, we really need a
direct referene to the `OnionMessenger` in the background
processor, which we add here optionally.
Matt Corallo [Fri, 10 May 2024 20:52:10 +0000 (20:52 +0000)]
Add a parallel async event handler to `OnionMessenger`
This adds an `OnionMessenger::process_pending_events_async`
mirroring the same in `ChannelManager`. However, unlike the one in
`ChannelManager`, this processes the events in parallel by spawning
all futures and using the new `MultiFuturePoller`.
Because `OnionMessenger` just generates a stream of messages to
store/fetch, we first process all the events to store new messages,
`await` them, then process all the events to fetch stored messages,
ensuring reordering shouldn't result in lost messages (unless we
race with a peer disconnection, which could happen anyway).
Matt Corallo [Mon, 3 Jun 2024 18:28:45 +0000 (18:28 +0000)]
Store `OnionMessenger` events in different `Vec`s
In the next commit, `OnionMessenger` events are handled in parallel
using rust async. When we do that, we'll want to handle
`OnionMessageIntercepted` events prior to
`OnionMessagePeerConnected` ones.
While we'd generally prefer to handle all events in the order they
were generated, if we want to handle them in parallel, we don't
want a `OnionMessageIntercepted` event to start being processed,
then handle an `OnionMessagePeerConnected` prior to the first
completing. This could cause us to store a freshly-intercepted
message for a peer in a DB that was just wiped because the peer
is now connected.
This does run the risk of processing a `OnionMessagePeerConnected`
event prior to an `OnionMessageIntercepted` event (because a peer
connected, then disconnected, then we received a message for that
peer all before any events were handled), that is somewhat less
likely and discarding a message in a rare race is better than
leaving a message lying around undelivered.
Thus, here, we store `OnionMessenger` events in separate `Vec`s
which we can pull from in message-type-order.
Matt Corallo [Tue, 12 Mar 2024 14:29:45 +0000 (14:29 +0000)]
Log available liquidity on each channel when starting routefinding
One of the most common first-steps in troubleshooting routefinding
issues is we ask for the local channel state to determine what the
available HTLC bounds are. While we log first-hop channel details
when we decline to use them, this doesn't tell us if we have
missing channels, and thus here we log all first-hop channels at
the start.
We also take this opportunity to log the limits that were violated
any time we log that we're not using a channel, rather than only
when its a first-hop.
shaavan [Thu, 23 May 2024 06:10:12 +0000 (11:40 +0530)]
Refactor TestCustomMessageHandler
- Introduce a new struct for keeping expectations organized.
- Add a boolean field to track whether a response is expected,
and hence whether a `reply_path` should be included with the response.
- Update Ping and Pong roles for bidirectional communication.
- Introduce panic for when there is no responder and we were expecting
to include a `reply_path`.
- Refactor `handle_custom_message` code.