Commit graph

2368 commits

Author SHA1 Message Date
Matt Corallo
ec68f1326d Track a reference to scoring parameters in DirectedChannelLiquidity
This simplifies adding additional half lives in
DirectedChannelLiquidity by simply storing a reference to the full
parameter set rather than only the single current half-life.
2022-10-06 21:10:23 +00:00
Matt Corallo
6852ea9741 Calculate a new penalty based on historical channel liquidity range
Our current `ProbabilisticScorer` attempts to build a model of the
current liquidity across the payment channel network. This works
fine to ignore channels we *just* tried to pay through, but it
fails to remember patterns over longer time horizons.

Specifically, there are *many* channels within the network that are
very often either fully saturated in one direction, or are
regularly rebalanced and rarely saturated. While our model may
discover that, when it decays its offsets or if there is a
temporary change in liquidity, it effectively forgets the "normal"
state of the channel.

This causes substantially suboptimal routing in practice, and
avoiding discarding older knowledge when new datapoints come in is
a potential solution to this.

Here, we implement one such design, using the decaying buckets
added in the previous commit to calculate a probability of payment
success based on a weighted average of recent liquidity estimates
for a channel.

For each min/max liquidity bucket pair (where the min liquidity is
less than the max liquidity), we can calculate the probability that
a payment succeeds using our traditional `amount / capacity`
formula. From there, we weigh the probability by the number of
points in each bucket pair, calculating a total probability for the
payment, and assigning a penalty using the same log-probability
calculation used for the non-historical penalties.
2022-10-06 21:10:23 +00:00
Matt Corallo
c5eab6e11f Track history of where channel liquidities have been in the past
This introduces two new fields to the `ChannelLiquidity` struct -
`min_liquidity_offset_history` and `max_liquidity_offset_history`,
both an array of 8 `u16`s. Each entry represents the proportion of
time that we spent with the min or max liquidity offset in the
given 1/8th of the channel's liquidity range. ie the first bucket
in `min_liquidity_offset_history` represents the proportion of time
we've thought the channel's minimum liquidity is lower than 1/8th's
the channel's capacity.

Each bucket is stored, effectively, as a fixed-point number with
5 bits for the fractional part, which is incremented by one (ie 32)
each time we update our liquidity estimates and decide our
estimates are in that bucket. We then decay each bucket by
2047/2048.

Thus, memory of a payment sticks around for more than 8,000
data points, though the majority of that memory decays after 1,387
data points.
2022-10-06 21:10:23 +00:00
Matt Corallo
5d0deacc3d Correct the directionality of liquidity non-update messages
When we log liquidity updates, if we decline to update anything as
the new bounds are already within the old bounds, the
directionality of the log entries was reversed.

While we're at it, we also log the old values.
2022-10-06 17:54:28 +00:00
Matt Corallo
7544030bb6
Merge pull request #1106 from TheBlueMatt/2021-10-no-perm-err-broadcast
Do not broadcast commitment txn on Permanent mon update failure
2022-09-29 22:02:07 +00:00
Matt Corallo
52934e0fff Clarify ambiguous comment in persist methods 2022-09-29 20:27:53 +00:00
Matt Corallo
f961daef33 Rename APIError::MonitorUpdateFailed to MonitorUpdateInProgress
This much more accurately represents the error, indicating that a
monitor update is in progress asynchronously and may complete at a
later time.
2022-09-29 20:27:53 +00:00
Matt Corallo
fb0a481696 Rename handle_monitor_err!() handle_monitor_update_res! 2022-09-29 20:27:53 +00:00
Matt Corallo
721a858533 Rename Channel::monitor_update_failed to monitor_updating_paused 2022-09-29 20:27:53 +00:00
Matt Corallo
72416b951e Add a TODO for an important issue for making async mon updates safe
If we receive a monitor event from a forwarded-to channel which
contains a preimage for an HTLC, we have to propogate that preimage
back to the forwarded-from channel monitor. However, once we have
that update, we're running in a relatively unsafe state - we have
the preimage in memory, but if we were to crash the forwarded-to
channel monitor will not regenerate the update with the preimage
for us. If we haven't managed to write the monitor update to the
forwarded-from channel by that point, we've lost the preimage, and,
thus, money!
2022-09-29 20:27:53 +00:00
Matt Corallo
12fa0b11a6 Rework chain::Watch return types to make async updates less scary
When a `chain::Watch` `ChannelMonitor` update method is called, the
user has three options:
 (a) persist the monitor update immediately and return success,
 (b) fail to persist the monitor update immediately and return
     failure,
 (c) return a flag indicating the monitor update is in progress and
     will complete in the future.

(c) is rather harmless, and in some deployments should be expected
to be the return value for all monitor update calls, but currently
requires returning `Err(ChannelMonitorUpdateErr::TemporaryFailure)`
which isn't very descriptive and sounds scarier than it is.

Instead, here, we change the return type used to be a single enum
(rather than a Result) and rename `TemporaryFailure`
`UpdateInProgress`.
2022-09-29 20:27:53 +00:00
Elias Rohrer
5f386bedaf
Remove done TODO
The migration to `LockTime` was already done in
7e05623bef, which however did not also
remove the TODO.
2022-09-26 11:20:50 +02:00
Matt Corallo
1beb3bb421 Add a bindings-only version of Future::register_callback
While we could, in theory, add support to the bindings logic to map
`Box<dyn Trait>`, there isn't a whole lot of use doing so when its
incredibly trivial to do directly.

This adds a trivial wrapper around `Future::register_callback` that
is only built in bindings and which is linked in the
`register_callback` docs for visibility.
2022-09-23 21:12:04 +00:00
Matt Corallo
ba021f80c0 Rename MultiThreadedLockableScoreLock to MultiThreadedScoreLock
as the first is quite a mouthful, and the second isn't materially
less specific.
2022-09-23 15:57:48 +00:00
valentinewallace
5211bfd3f6
Merge pull request #1733 from TheBlueMatt/2022-09-downgrade-hashbrown
Downgrade `hashbrown` to meet MSRV
2022-09-22 12:48:39 -04:00
valentinewallace
c614a2755b
Merge pull request #1731 from valentinewallace/2022-09-router-test-utils-mod
Move router test utils into their own module
2022-09-22 11:51:47 -04:00
Matt Corallo
2e7d924d9b Downgrade hashbrown to meet MSRV
`hashbrown` depends on `ahash` which depends on `once_cell`. Sadly,
in https://github.com/matklad/once_cell/issues/201 the `once_cell`
maintainer decided they didn't want to do the work of having an
MSRV policy for `once_cell`, making `ahash`, and thus `hashbrown`
require the latest compiler. I've reached out to `ahash` to suggest
they drop the dependency (as they could trivially work around not
having it), but until then we simply downgrade `hashbrown`.

`rust-bitcoin` also requires an older `hashbrown` so we're actually
reducing our total `no-std` code here anyway.
2022-09-22 15:06:42 +00:00
Valentine Wallace
95a4173b66
Import util::test_utils as ::ln_test_utils in router
To disambiguate between util::test_utils and router::test_utils
2022-09-21 15:09:55 -04:00
Valentine Wallace
feabd61bfe
Rename routing::router::test_utils to ::bench_utils
To disambiguate it from routing::test_utils
2022-09-20 10:08:57 -04:00
Matt Corallo
af03788db0
Merge pull request #1656 from ViktorTigerstrom/2022-08-forward-htlcs-as-standalone-lock
Move `forward_htlcs` into standalone lock
2022-09-20 10:19:32 +00:00
Valentine Wallace
615b401f7b
Move router test utils into their own module
Useful for testing onion message pathfinding in upcoming PRs and any future
routing modules we add
2022-09-19 14:16:37 -04:00
Viktor Tigerström
fc12d43856 Add lock order docs to ChannelManager fields 2022-09-19 18:43:24 +02:00
Matt Corallo
56b07e52aa Add a MutexGuard wrapper for the bindings-only LockableScore
In the bindings, we don't directly export any `std` types. Instead,
we provide trivial wrappers around them which expose only a
bindings-compatible API (and which is code in-crate, where the
bindings generator can see it).

We never quite finished this for `MultiThreadedLockableScore` - due
to some limitations in the bindings generator and the way the
scores are used in `lightning-invoice`, the scoring API ended up
being further concretized in patches for the bindings. Luckily the
scoring interface has been rewritten somewhat, and it so happens
that we can now generate bindings with the upstream code.

The final piece of the puzzle is done here, where we add a struct
which wraps `MutexGuard` so that we can expose the lock for
`MultiThreadedLockableScore`.
2022-09-19 09:21:56 +00:00
Viktor Tigerström
3379f8c492 Remove forward_htlc after channel_state lock order
The `forward_htlc` was prior to this commit only held at the same time
as the `channel_state` lock during the write process of the
`ChannelManager`. This commit removes the lock order dependency, by
taking the `channel_state`lock temporarily during the write process.
2022-09-18 23:13:56 +02:00
Viktor Tigerström
e8854a9ce2 Remove unnecessary aquiring of the channel_state lock 2022-09-18 23:13:56 +02:00
Viktor Tigerström
df12df354e Move forward_htlcs into standalone lock
As we are eventually removing the `channel_state` lock, this commit
moves the `forward_htlcs` map out of the `channel_state` lock, to ease
that process.
2022-09-18 23:13:56 +02:00
Matt Corallo
070dd74602 Stop building with lockorder debugging in benchmarks
`cargo bench` sets `#[cfg(test)]` so our current checks for
enabling our lockorder debugging end up matching when we're trying
to build performance benchmarks.

This adds explicit checks to our debug_lockorder logic to filter
out `feature = "_bench_unstable"` builds.
2022-09-16 14:44:20 +00:00
Matt Corallo
313810ebdc Do not broadcast commitment txn on Permanent mon update failure
See doc updates for more info on the edge case this prevents, and
there isn't really a strong reason why we would need to broadcast
the latest state immediately. Specifically, in the case of HTLC
claims (the most important reason to ensure we have state on chain
if it cannot be persisted), we will still force-close if there are
HTLCs which need claiming and are going to expire.

Surprisingly, there were no tests which failed as a result of this
change, but a new one has been added.
2022-09-15 18:18:06 +00:00
Matt Corallo
9170804ca4 Assert that all defined features are in the known features set
Now that the features contexts track the full set of all known
features, rather than the set of supported features, all defined
features should be listed in the context definition macro.

This adds a compile-time assertion to check that all bits for known
features are set in the context known set.
2022-09-14 20:10:17 +00:00
Matt Corallo
b83e93c799 Stop tracking feature bits as known or required in features.rs
Now that the `*Features::known` constructor has been removed, there
is no reason to define feature bits as either optional required in
`features.rs` - that logic now belongs in the modules that are
responsible for the given features.

Instead, we only list all features in each context.
2022-09-14 20:10:17 +00:00
Matt Corallo
bec8bf10aa Remove the *Features::known constructor
As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we (finally) remove the `known` constructor entirely,
modifying tests in the `features` module as required.
2022-09-14 20:10:17 +00:00
Matt Corallo
b93fe327d2 Remove all remaining references to *Features::known
As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

In anticipation of removing the `known` constructor, this commit
removes all remaining references to it outside of features.rs.
2022-09-14 20:09:36 +00:00
Matt Corallo
32b5d843d9 Stop relying on *Features::known in channel{,manager}.rs
As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the channel modules.
2022-09-14 20:09:35 +00:00
Matt Corallo
c1d8cb9710 Stop relying on *Features::known in functional test utils
As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the
functional_test_utils module.
2022-09-14 20:09:35 +00:00
Matt Corallo
3b3713fdde Stop relying on the *Features::known method in functional tests
This diff is commit, like the last, stops relying on the `known`
feature set constructor, doing so entirely with import changes and
sed rules.
2022-09-14 20:09:35 +00:00
Matt Corallo
1a3273792b Stop relying on the *Features::known method in routing tests
As we move towards specify supported/required feature bits in the
module(s) where they are supported, the global `known` feature set
constructors no longer make sense.

Here we stop relying on the `known` method in the `routing` module,
which was only used in tests.
2022-09-14 20:09:35 +00:00
Matt Corallo
6b1f867eaa List supported/required feature bits explicitly in ChannelManager
Historically, LDK has considered the "set of known/supported
feature bits" to be an LDK-level thing. Increasingly this doesn't
make sense - different message handlers may provide or require
different feature sets.

In a previous PR, we began the process of transitioning with
feature bits sent to peers being sourced from the attached message
handler.

This commit makes further progress by moving the concept of which
feature bits are supported by our ChannelManager into
channelmanager.rs itself, via the new `provided_*_features`
methods, rather than in features.rs via the `known_channel_features`
and `known` methods.
2022-09-14 20:08:54 +00:00
Matt Corallo
464391c245 Fix compile warning in fuzzing introduced in cd0d19c005 2022-09-14 00:49:21 +00:00
Matt Corallo
71f4749e1c
Merge pull request #1685 from wpaulino/anchors-prep 2022-09-13 21:09:25 +00:00
valentinewallace
d2a9ae0b8e
Merge pull request #1717 from TheBlueMatt/2022-09-req-features-in-handlers
Move checking of specific require peer feature bits to handlers
2022-09-13 16:17:57 -04:00
Wilmer Paulino
f3a5a72346
Update anchors test vectors to zero HTLC transaction fee variant
Each test featuring HTLCs had a minimum and maximum feerate case. This
is no longer necessary for the zero HTLC transaction anchors variant as
the commitment feerate does not impact whether HTLCs can be trimmed or
not, only the dust limit does.
2022-09-13 10:58:39 -07:00
Wilmer Paulino
af2ff9b5b9
Account for zero fee HTLC transaction within dust limit calculation
With the zero fee HTLC transaction anchors variant, HTLCs can no longer
be trimmed due to their amount being too low to have a mempool valid
HTLC transaction. Now they can only be trimmed based on the dust limit
of each party within the channel.
2022-09-13 10:58:36 -07:00
Wilmer Paulino
cd0d19c005
Update HTLC script detection to check for anchor output variants 2022-09-13 10:58:32 -07:00
Wilmer Paulino
a447965b80
Use zero fee HTLC transactions for anchor channels
This is based on the assumption that we only support the zero HTLC
transaction fee variant of anchor channels.
2022-09-13 10:58:29 -07:00
Wilmer Paulino
5aae0ab721
Exclude HTLC transactions from broadcast on anchor channels
HTLC transactions from anchor channels are constrained by a CSV of 1
block, so broadcasting them along with the unconfirmed commitment
tranasction will result in them being immediately rejected as premature.
2022-09-13 10:58:24 -07:00
Wilmer Paulino
62236c70d8
Avoid commitment broadcast upon detected funding spend
There's no need to broadcast our local commitment transaction if we've
already seen a confirmed one as it'll be immediately rejected as a
duplicate/conflict.

This will also help prevent dispatching spurious events for bumping
commitment and HTLC transactions through anchor outputs (once
implemented in future work) and the dispatch for said events follows the
same flow as our usual commitment broadcast.
2022-09-13 10:58:20 -07:00
Wilmer Paulino
2f4a1f7f79
Use proper sighash flag for remote HTLCs with anchor outputs 2022-09-13 10:58:14 -07:00
valentinewallace
a82fb62856
Merge pull request #1703 from TheBlueMatt/2022-09-badonion-first-check
Correctly handle BADONION onion errors
2022-09-13 13:47:23 -04:00
Matt Corallo
f725c5a90a Add now-missing unwraps on test calls to peer_connected. 2022-09-13 16:59:30 +00:00
Matt Corallo
bbb590b551 Move checking of specific require peer feature bits to handlers
As we remove the concept of a global "known/supported" feature set
in LDK, we should also remove the concept of a global "required"
feature set. This does so by moving the checks for specific
required features into handlers.

Specifically, it allows the handler `peer_connected` method to
return an `Err` if the peer should be disconnected. Only one such
required feature bit is currently set - `static_remote_key`, which
is required in `ChannelManager`.
2022-09-13 16:59:30 +00:00