Use util methods in `Peer` to decide when to forward
This consolidates our various checks on peer buffer space into the
`Peer` impl itself, making the thresholds at which we stop taking
various actions on a peer more readable as a whole.
This commit was primarily authored by `Valentine Wallace
<vwallace@protonmail.com>` with some amendments by `Matt Corallo
<git@bluematt.me>`.
Matt Corallo [Sun, 7 Aug 2022 19:02:33 +0000 (19:02 +0000)]
Update libfuzzer-sys to new upstream inclusion method
Dunno why they changed it, but the old "depend directly on git"
thing that cargo-fuzz used forever is now deprecated that that
repo is archived, they've now moved to another repo and publish
properly on crates.io.
Fix possible incomplete read bug on onion packet decode
Pre-existing to this PR, we were reading next packet bytes with io::Read::read,
which is not guaranteed to read all the bytes we need, only guaranteed to read
*some* bytes.
We fix this to be read_exact, which is guaranteed to read all the next hop
packet bytes.
This required adapting `onion_utils::decode_next_hop` to work for both payments
and onion messages.
Currently we just print out the path_id of any onion messages we receive. In
the future, these received onion messages will be redirected to their
respective handlers: i.e. an invoice_request will go to an InvoiceHandler,
custom onion messages will go to a custom handler, etc.
This adds several utilities in service of then adding
OnionMessenger::send_onion_message, which can send to either an unblinded
pubkey or a blinded route. Sending custom TLVs and sending an onion message
containing a reply path are not yet supported.
We also need to split the construct_keys_callback macro into two macros to
avoid an unused assignment warning.
This method will help us avoid retrieving our node secret, something we want to
get rid of entirely. It will be used in upcoming commits when decoding the
onion message packet, and in future PRs to help us get rid of
KeysInterface::get_node_secret usages across the codebase
Add onion_message::Packet and adapt construct_onion_packet_with_init_noise for it
We need to add a new Packet struct because onion message packet hop_data fields
can be of variable length, whereas regular payment packets are always 1366
bytes.
Add config support for 'their_channel_reserve_proportional_millionths' [#1498]
It is proportion of the channel value to configure as the
`their_channel_reserve_satoshis` for both outbound and inbound channels.
It decides the minimum balance that the other node has to maintain on their
side, at all times.
Don't return `channel_state` from `decode_update_add_htlc_onion`
Currently `decode_update_add_htlc_onion` returns the `channel_state`
lock to ensure that `internal_update_add_htlc` holds a single
`channel_state` lock in when the entire function execution. This is
unnecessary, and since we are moving the channel storage to the
`per_peer_state`, this no longer achieves the goal it was intended for.
We therefore avoid returning the `channel_state` from
`decode_update_add_htlc_onion`, and just retake the lock in
`internal_update_add_htlc` instead.
Add onion messages module + enable the construction of blinded routes
Blinded routes can be provided as destinations for onion messages, when the
recipient prefers to remain anonymous.
We also add supporting utilities for constructing blinded path keys, and
control TLVs structs representing blinded payloads prior to being
encoded/encrypted. These utilities and struct will be re-used in upcoming
commits for sending and receiving/forwarding onion messages.
Finally, add utilities for reading the padding from an onion message's
encrypted TLVs without an intermediate Vec.
Matt Corallo [Wed, 27 Jul 2022 03:53:47 +0000 (03:53 +0000)]
Expose `ChannelMonitor::get_counterparty_node_id`
This fixes an oversight in ac842ed9dd7a36a4a26eb6b856d80ab04eecf750
namely that it left users unable to implement their own
`ChainMonitor` from outside of the `rust-lightning` crate.
Matt Corallo [Thu, 21 Jul 2022 17:47:19 +0000 (17:47 +0000)]
Rename amount penalty to `liquidity_penalty_amount_multiplier_msat`
This makes our `ProbabilisticScorer` field names more consistent,
as we add more types of penalties, referring to a penalty as only
the "amount penalty" no longer makes sense - we not have several
amount multiplier penalties.
Matt Corallo [Thu, 14 Jul 2022 01:06:10 +0000 (01:06 +0000)]
Add a per-amount base penalty in the `ProbabilisticScorer`
There's not much reason to not have a per-hop-per-amount penalty in
the `ProbabilisticScorer` to go along with the per-hop penalty to
let it scale up to larger amounts, so we add one here.
Notably, we use a divisor of 2^30 instead of 2^20 (like the
equivalent liquidity penalty) as it allows for more flexibility,
and there's not really any reason to worry about us not being able
to create high enough penalties.
Matt Corallo [Thu, 21 Jul 2022 21:38:00 +0000 (21:38 +0000)]
Avoid blanket implementing FeeEstimator for Deref<FeeEstimator>
This simplifies things for bindings (and, to some extent,
downstream users) by exploiting the fact that we can always "clone"
a reference to a struct by dereferencing and then creating a new
reference.
Matt Corallo [Wed, 13 Jul 2022 16:52:27 +0000 (16:52 +0000)]
Use a separate (non-trait) fee-estimation fn in LowerBoundedEstimator
This should make it somewhat more difficult to accidentally use a
straight fee estimator when we actually want a
LowerBoundedFeeEstimator by not having the types be exchangeable at
all.
Matt Corallo [Fri, 22 Jul 2022 00:32:17 +0000 (00:32 +0000)]
Remove scary disconenct warnings on PeerManager new connection fns
In 4703d4e72565ddfd150b9368ea036f4973fd7590 we changed
PeerManager::socket_disconnected to no longer require that sockets
which the PeerManager decided to disconnect not be disconnected.
However, we forgot to remove the scary warnings on the
`new_{inbound,outbound}_connection` functions which warned of the
old behavior.
We add `HTLCHandlingFailedConditions` to express the failure parameters,
that will be enforced by a new macro, `expect_pending_htlcs_forwardable_conditions`.
Adds a HTLCHandlingFailed that expresses failure by our node to process
a specific HTLC. A HTLCDestination enum is defined to express the
possible cases that causes the handling to fail.
Matt Corallo [Tue, 12 Apr 2022 17:32:35 +0000 (17:32 +0000)]
Expand lockorder testing to look at mutexes, not specific instances
Our existing lockorder inversion checks look at specific instances
of mutexes rather than the general mutex itself. This changes that
behavior to look at the instruction pointer at which a mutex was
created and treat all mutexes which were created at the same
location as equivalent.
This allows us to detect lockorder inversions which occur across
tests, though it does substantially reduce parallelism during test
runs.
Matt Corallo [Fri, 15 Jul 2022 16:18:42 +0000 (16:18 +0000)]
Construct all ChannelMonitor mutexes in the same function
When we add lockorder detection based on mutex construction site
rather than mutex instance in the next commit, ChannelMonitor's
PartialEq implementation causes spurious failures. This is caused
by the lockorder detection logic considering the ChannelMonitor
inner mutex to be two distinct mutexes - one when monitors are
deserialized and one when monitors are created fresh. Instead, we
attempt to tell the lockorder detection logic that they are the
same by ensuring they're constructed in the same place - in this
case a util method.
Matt Corallo [Tue, 12 Jul 2022 21:13:30 +0000 (21:13 +0000)]
Reduce default max_channel_saturation_power_of_half to 2 (max 1/4)
Saturating a channel beyond 1/4 of its capacity seems like a more
reasonable threshold for avoiding a path than 1/2, especially given
we should still be willing to send a payment with a lower
saturation limit if it comes to that.
This requires an (obvious) change to some router tests, but also
requires a change to the `fake_network_test`, opting to simply
remove some over-limit test code there - `fake_network_test` was
our first ever functional test, and while it worked great to ensure
LDK worked at all on day one, we now have a rather large breadth
of functional tests, and a broad "does it work at all" test is no
longer all that useful.
Matt Corallo [Tue, 12 Jul 2022 20:35:36 +0000 (20:35 +0000)]
Make route path selection optimize strictly for `cost / amount`
Currently, after we've selected a number of candidate paths, we
construct a route from a random set of paths repeatedly, and then
select the route with the lowest total cost. In the vast majority
of cases this ends up doing a bunch of additional work in order to
select the path(s) with the total lowest cost, with some vague
attempt at randomization that doesn't actually work.
Instead, here, we simply sort available paths by `cost / amount`
and select the top paths. This ends up in practice having the same
end result with substantially less complexity. In some rare cases
it gets a better result, which also would have been achieved
through more random trials. This implies there may in such cases be
a potential privacy loss, but not a substantial one, given our path
selection is ultimately mostly deterministic in many cases (or, if
it is not, then privacy is achieved through randomization at the
scorer level).
Matt Corallo [Tue, 12 Jul 2022 20:30:00 +0000 (20:30 +0000)]
Fix tracking of collected value across pathfinding iterations
If we end up "paying" for an `htlc_minimum_msat` with fees, we
increment `already_collected_value_msat` by more than the amount
of the path that we collected (who's `value_contribution_msat` is
higher than the total payment amount, despite having been reduced
down to the payment amount).
This throws off our total value collection target, though in the
coming commit(s) it would also throw off our path selection
calculations.
Matt Corallo [Thu, 7 Jul 2022 17:37:22 +0000 (17:37 +0000)]
Change default "impossibility penalty" to one Bitcoin
In general we should avoid taking paths that we are confident will
not work as much possible, but we should be willing to try each
payment at least once, even if its over a channel that failed
recently. A full Bitcoin penalty for such a channel seems
reasonable - lightning fees are unlikely to ever reach that point
so such channels will be scored much worse than any other potential
path, while still being below `u64::max_value()`.
Matt Corallo [Wed, 6 Jul 2022 21:05:54 +0000 (21:05 +0000)]
Make the `ProbabilisticScorer` impossibility penalty configurable
When we consider sending an HTLC over a given channel impossible
due to our current knowledge of the channel's liquidity, we
currently always assign a penalty of `u64::max_value()`. However,
because we now refuse to retry a payment along the same path in
the router itself, we can now make this value configurable. This
allows users to have a relatively high knowledge decay interval
without the side-effect of refusing to try the only available path
in cases where a channel is intermittently available.
Matt Corallo [Wed, 6 Jul 2022 19:17:40 +0000 (19:17 +0000)]
Track channels which a given payment part failed to traverse
When an HTLC fails, we currently rely on the scorer learning the
failed channel and assigning an infinite (`u64::max_value()`)
penalty to the channel so as to avoid retrying over the exact same
path (if there's only one available path). This is common when
trying to pay a mobile client behind an LSP if the mobile client is
currently offline.
This leads to the scorer being overly conservative in some cases -
returning `u64::max_value()` when a given path hasn't been tried
for a given payment may not be the best decision, even if that
channel failed 50 minutes ago.
By tracking channels which failed on a payment part level and
explicitly refusing to route over them we can relax the
requirements on the scorer, allowing it to make different decisions
on how to treat channels that failed relatively recently without
causing payments to retry the same path forever.
This does have the drawback that it could allow two separate part
of a payment to traverse the same path even though that path just
failed, however this should only occur if the payment is going to
fail anyway, at least as long as the scorer is properly learning.
Jeffrey Czyz [Tue, 14 Jun 2022 23:05:25 +0000 (18:05 -0500)]
Look-up functions for ReadOnlyNetworkGraph
ReadOnlyNetworkGraph uses BTreeMap to store its nodes and channels, but
these data structures are not supported by C bindings. Expose look-up
functions on these maps in lieu of such support.
Matt Corallo [Wed, 13 Jul 2022 19:33:25 +0000 (19:33 +0000)]
Rip out dependabot - its worse than useless - its annoying
Dependabot has a ton of issues with its rust integration that makes
it wholly useless, and very annoying:
* It has no concept of MSRV, opening PRs that are not going to pass
CI.
* It has no concept of patch-level - if we depend on tokio 1.X,
that means any version of tokio > 1.X, but dependabot insists on
opening a PR to "update us" to tokio 1.X + 1, even though it
doesn't impact what version of our users use (and often violates
MSRV).
* It has no concept of dependencies that rely on each other,
causing it to open a PR to update us to bitcoin_hashes X + 1,
even though we're still depending on rust-bitcoin Y which
depends on bitcoin_hashes X, causing build failure.
* It hogs CI resources, getting CI run twice, once for the branch
once for the PR.
* It creates branches directly on the rust-lightning repo, making
it look like the work is somehow connected to the
lightningdevkit project, even though it isn't, and spamming the
local clones of project contributors.
At the end of the day, dependabot has never meaningfully
contributed to notifying us of an important dependency, and,
really, we don't have enough dependencies for it to matter.
Matt Corallo [Tue, 12 Apr 2022 17:28:15 +0000 (17:28 +0000)]
Fix some test theoretical lock inversions
In the next commit we add lockorder testing based on the line each
mutex was created on rather than the particular mutex instance.
This causes some additional test failure because of lockorder
inversions for the same mutex across different tests, which is
fixed here.
Matt Corallo [Fri, 8 Jul 2022 19:48:00 +0000 (19:48 +0000)]
Relax the channel saturation limit if we can't find enough paths
In order to avoid failing to find paths due to the new channel
saturation limit, if we fail to find enough paths, we simply
disable the saturation limit for further path finding iterations.
Because we can now increase the maximum sent over a given channel
during routefinding, we may now generate redundant paths for the
same payment. Because this is wasteful in the network, we add an
additional pass during routefinding to merge redundant paths.
Note that two tests which previously attempted to send exactly the
available liquidity over a channel which charged an absolute fee
need updating - in those cases the router will first collect a path
that is saturation-limited, then attempt to collect a second path
without a saturation limit while stil honoring the existing
utilized capacity on the channel, causing failure as the absolute
fee must be included.
Matt Corallo [Fri, 8 Jul 2022 18:26:06 +0000 (18:26 +0000)]
Avoid saturating channels before we split payments
Currently we only opt to split a payment into an MPP if we have
completely and totally used a channel's available capacity (up to
the announced htlc_max or on-chain capacity, whichever is lower).
This is obviously destined to fail as channels are unlikely to have
their full capacity available.
Here we do the minimum viable fix by simply limiting channels to
only using up to a configurable power-of-1/2. We default this new
configuration knob to 1 (1/2 of the channel) so as to avoid a
substantial change but in the future we may consider changing this
to 2 (1/4) or even 3 (1/8).
Duncan Dean [Wed, 29 Jun 2022 12:59:07 +0000 (14:59 +0200)]
Add LowerBoundedFeeEstimator to set FeeEstimator min rates
`LowerBoundedFeeEstimator` is a wrapper for `Deref`s to `FeeEstimator`s
that limits the get_est_sat_per_1000_weight() method to no less than 253
sats/kW.
Matt Corallo [Fri, 8 Jul 2022 01:16:05 +0000 (01:16 +0000)]
Avoid panicking on wallclock time going backwards across restart
Because we serialize `Instant`s using wallclock time in
`ProbabilisticScorer`, if time goes backwards across restarts we
may end up with `Instant`s in the future, which causes rustc prior
to 1.60 to panic when calculating durations. Here we simply avoid
this by setting the time to `now` if we get a time in the future.
As the map values are no longer only `channel_id`s, but also a
`counterparty_node_id`s, the map is renamed to better correspond to
whats actually stored in the map.
projects / rust-lightning / log