Jeffrey Czyz [Mon, 14 Feb 2022 21:31:59 +0000 (15:31 -0600)]
Immutable BlockSource interface
Querying a BlockSource is a logically immutable operation. Use non-mut
references in its interface to reflect this, which allows for users to
hold multiple references if desired.
Jeffrey Czyz [Thu, 31 Mar 2022 13:13:10 +0000 (08:13 -0500)]
Add an amount penalty to ProbabilisticScorer
The cost of large payments tends to be dominated by the channel fees. To
avoid this, add an amount penalty to ProbabilisticScorer with a user
configurable multiplier. The multiplier is applied for every 2^20th of
the amount weighted by the negative log10 of the channel's success
probability for the payment.
Jeffrey Czyz [Thu, 31 Mar 2022 02:20:58 +0000 (21:20 -0500)]
Avoid retrying over recently failed channels
In ProbabilisticScorer, the channel liquidity balance is reduced
whenever a payment fails at the corresponding channel. The payment may
still be retried through the channel, however, because the liquidity
penalty is capped. Use u64::max_value instead in this situation to avoid
retrying over the same path. This effectively makes u64::max_value the
penalty for amounts exceeding the upper bound, as well.
As an edge case, avoid using u64::max_value on attempts where the amount
is equal to the effective capacity, which may be the HTLC maximum when
the channel capacity is unknown.
Matt Corallo [Thu, 24 Mar 2022 18:38:43 +0000 (18:38 +0000)]
Don't consider a path as having hit HTLC-min if it isn't sufficient
During the first pass of path finding, we seek a single path with the
exact payment amount, and only seek additional paths if (a) no single
path can carry the entire balance of the payment or (b) we found a good
path, but along the way we found candidate paths with the potential to
result in a lower total fee. This commit fixes the behavior of (b) -- we
were previously considering some paths to be candidates for a lower fee
when in fact they never would have worked. This caused us to re-run
Dijkstra's when it might not have been beneficial.
Jurvis Tan [Tue, 22 Mar 2022 03:13:14 +0000 (20:13 -0700)]
Add NetworkGraph persistence
Instead of creating a separate trait for persisting NetworkGraph, use and rename the existing ChannelManagerPersister to handle them both. persist_graph is then called on removal of stale channels and on exit.
Matt Corallo [Tue, 15 Mar 2022 23:53:01 +0000 (23:53 +0000)]
Drop the `Writeable::encode_with_len` method in non-test buidls
There's not a lot of reason to keep it given its used in one place
outside of tests, and this lets us clean up some of the byte_utils
calls that are still lying around.
Matt Corallo [Tue, 8 Mar 2022 21:55:02 +0000 (21:55 +0000)]
Use the correct SCID when failing HTLCs to aliased channels
When we fail an HTLC which was destined for a channel that the HTLC
sender didn't know the real SCID for, we should ensure we continue
to use the alias in the channel_update we provide them. Otherwise
we will leak the channel's real SCID to HTLC senders.
Matt Corallo [Fri, 4 Mar 2022 20:20:19 +0000 (20:20 +0000)]
Make all callsites to `get_channel_update_for_unicast` fallible
This reduces unwraps in channelmanager by a good bit, providing
robustness for the upcoming 0conf changes which allow SCIDs to be
missing after a channel is in use, making
`get_channel_update_for_unicast` more fallible.
This also serves as a useful refactor for the next commit,
consolidating the channel_update creation sites which are changed
in the next commit.
Matt Corallo [Thu, 17 Feb 2022 22:13:54 +0000 (22:13 +0000)]
Negotiate `scid_alias` for private channels based on a new config
Because negotiating `scid_alias` for all of our channels will cause
us to create channels which LDK versions prior to 0.0.106 do not
understand, we disable `scid_alias` negotiation by default.
Matt Corallo [Tue, 1 Feb 2022 17:23:52 +0000 (17:23 +0000)]
Add support for the SCIDAlias feature bit in incoming channels
This does not, however, ever send the scid_alias feature bit for
outgoing channels, as that would cause the immediately prior
version of LDK to be unable to read channel data.
Matt Corallo [Wed, 16 Feb 2022 04:21:29 +0000 (04:21 +0000)]
Expose chan type in `Event::OpenChannelRequest` & `ChannelDetails`
As we add new supported channel types, inbound channels which use
new features may cause backwards-compatibility issues for clients.
If a new channel is opened using new features while a client still
wishes to ensure support for downgrading to a previous version of
LDK, that new channel may cause the `ChannelManager` to fail
deserialization due to unsupported feature flags.
By exposing the channel type flags to the user in channel requests,
users wishing to support downgrading to previous versions of LDK
can reject channels which use channel features which previous
versions of LDK do not understand.
Matt Corallo [Sun, 27 Mar 2022 17:11:22 +0000 (17:11 +0000)]
Bump `check_commits` CI job rustc to 1.57
1.51 (and other earlier versions of `rustc`) appear to refuse to
accept our documentation links due to a bogus failure to resolve
`ChannelTypeFeatures::supports_scid_privacy`.
Jeffrey Czyz [Thu, 24 Mar 2022 23:21:29 +0000 (18:21 -0500)]
Fix overflow in ProbabilisticScorer
When a routing hint is given in an invoice, the effective capacity of
the channel is assumed to be infinite (i.e., u64::max_value) if the hop
is private. Adding 1 to this in the success probability calculation will
cause an overflow and ultimately an `index out of bounds panic` in
log10_times_1024. This was not an issue with using log10 because the use
of f64 would give infinite which casts to 0 for u64.
Jeffrey Czyz [Tue, 22 Mar 2022 00:11:48 +0000 (19:11 -0500)]
Add a base penalty to ProbabilisticScorer
ProbabilisticScorer tends to prefer longer routes to shorter ones. Make
the default scoring behavior include a customizable base penalty to
avoid longer routes.
Matt Corallo [Wed, 23 Mar 2022 22:10:15 +0000 (22:10 +0000)]
Skip `channel_update` signature checks if we have a newer state
`channel_update` messages already have their signatures checked
with the network graph write lock held, so there's no reason to
check the signatures before doing other quicker checks first,
including checking if we're already aware of a newer update for the
channel.
This reduces common-case CPU usage as `channel_update`s are sent
rather liberally over the p2p network to gossip them.
Matt Corallo [Fri, 18 Mar 2022 23:19:51 +0000 (23:19 +0000)]
Avoid needless MPP on multiple channels to the same first-hop
When we have many channels to the same first-hop, many of which do
not have sufficient balance to make the requested payment, but when
some do, instead of simply using the available channel balance we
may switch to MPP, potentially with many, many paths.
Instead, we should seek to use the smallest channel which can
easily handle the requested payment, which we do here by sorting
the first_hops in our router before beginning the graph search.
Note that the "real" fix for this should be to instead decide which
channel to use at HTLC-send time, as most other nodes do during
relay, but this provides a minimal fix without needing to do the
rather-large work of refactoring our HTLC send+relay pipelines.
Issues with overly-aggressive MPP on many channels were reported by
Cash App.
Matt Corallo [Fri, 18 Mar 2022 03:28:25 +0000 (03:28 +0000)]
Tag some type aliases with `(C-not exported)`
Type aliases are now more robustly being exported in the C bindings
generator, which requires ensuring we don't include some type
aliases which make no sense in bindings.
Matt Corallo [Thu, 17 Mar 2022 22:14:43 +0000 (22:14 +0000)]
Send a `gossip_timestamp_filter` on connect to enable gossip sync
On connection, if our peer supports gossip queries, and we never
send a `gossip_timestamp_filter`, our peer is supposed to never
send us gossip outside of explicit queries. Thus, we'll end up
always having stale gossip information after the first few
connections we make to peers.
The solution is to send a dummy `gossip_timestamp_filter`
immediately after connecting to peers.
Its somewhat strange to have a trait method which is named after
the intended action, rather than the action that occurred, leaving
it up to the implementor what action they want to take.
Matt Corallo [Thu, 10 Mar 2022 21:07:37 +0000 (21:07 +0000)]
Make routing benchmark robust against path changes
If the scoring in the routing benchmark causes us to take a
different path from the original scan, we may end up deciding that
the only path to a node has a too-high total CLTV delta, causing us
to panic in the benchmarking phase.
Here we simply check for that possibility and remove paths that
fail post-scoring.
Filter the route hints in `create_phantom_invoice` based on the
following criteria:
* Only one channel for every counterparty node per phantom
payment-receiving node in the invoice
* Always select the channel with the highest inbound capacity
* For each payment-receiving node, filter out channels with a lower
inbound capacity than the invoice amount, if any channel exists with
enough capacity to cover the invoice amount
* If any public channels exists for a payment-receiving node, push a
single RouteHintHop with the phantom route and let the sender find the
path to the payment-receiving node through the public channels.
Filter the route hints in `create_invoice_from_channelmanager` based on
the following criteria:
* Only one channel per counterparty node
* Always select the channel with the highest inbound capacity
* Filter out channels with a lower inbound capacity than the invoice
amount, if any channel exists with enough capacity to cover the invoice
amount
* If any public channel exists, the invoice route_hints should be empty,
and the sender will need to find the path to the payment-receiving node
by looking at the public channels instead
Matt Corallo [Sun, 13 Mar 2022 21:35:46 +0000 (21:35 +0000)]
Generate a funding_locked on relevant transactions_confirmed calls
Previously, if we were offline when a funding transaction was
locked in, and then we came back online, calling
`best_block_updated` once followed by `transactions_confirmed`,
we'd not generate a funding_locked until the next
`best_block_updated`.
We address this by re-calling `best_block_updated` in
`transactions_confirmed`, similar to how `ChannelMonitor` works.
Matt Corallo [Tue, 1 Feb 2022 17:37:28 +0000 (17:37 +0000)]
Support receiving multiple funding_locked messages
As a part of adding SCID aliases to channels, we now have to accept
otherwise-redundant funding_locked messages which serve only to
update the SCID alias. Previously, we'd failt he channel as such
an update used to be bogus.
Matt Corallo [Tue, 15 Feb 2022 23:27:07 +0000 (23:27 +0000)]
Provide our peers with SCID aliases and forward payments with them
This creates an SCID alias for all of our outbound channels, which
we send to our counterparties as a part of the `funding_locked`
message and then recognize in any HTLC forwarding instructions.
Note that we generate an SCID alias for all channels, including
already open ones, even though we currently have no way of
communicating to our peers the SCID alias for already-open
channels.
Matt Corallo [Tue, 1 Feb 2022 17:37:16 +0000 (17:37 +0000)]
Track SCID aliases from our counterparty and use them in invoices
New `funding_locked` messages can include SCID aliases which our
counterparty will recognize as "ours" for the purposes of relaying
transactions to us. This avoids telling the world about our
on-chain transactions every time we want to receive a payment, and
will allow for receiving payments before the funding transaction
appears on-chain.
Here we store the new SCID aliases and use them in invoices instead
of he "standard" SCIDs.
Matt Corallo [Tue, 1 Feb 2022 23:42:05 +0000 (23:42 +0000)]
Clean up the `handle_monitor_err!()` macro argument forms somewhat
`handle_monitor_err!()` has a number of different forms depending
on which messages and actions were outstanding when the monitor
updating first failed. Instead of matching by argument count, its
much more readable to put an explicit string in the arguments to
make it easy to scan for the called form.
Matt Corallo [Wed, 9 Mar 2022 18:15:30 +0000 (18:15 +0000)]
Make lightning-block-sync's init module slightly more generic
Users who want to use lightning-block-sync's init module would
be reasonable in wanting to use it in a multithreaded environment,
however because it takes a list of listeners as dyn chain::Listen
without any Send or Sync bound they fail in doing so.
Here we make the type bounds on `chain::Listen` generic across
`chain::Listen + ?Sized`, which the existing bound of `&dyn
chain::Listen` satisfies. Thus, this is strictly less restrictive
and allows for the use of `&dyn chain::Listen + Send + Sync`.
dependabot[bot] [Wed, 9 Mar 2022 17:38:53 +0000 (17:38 +0000)]
Update regex requirement from 0.1.80 to 0.2.11 in /lightning
Updates the requirements on [regex](https://github.com/rust-lang/regex) to permit the latest version.
- [Release notes](https://github.com/rust-lang/regex/releases)
- [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rust-lang/regex/compare/0.1.80...0.2.11)
Jeffrey Czyz [Fri, 4 Mar 2022 07:59:44 +0000 (23:59 -0800)]
Check for no-std compatibility across dependencies
To ensure no-std is honored across dependencies, add a crate depending
on lightning crates supporting no-std. This should ensure any
regressions are caught. Otherwise, cargo doesn't seem to catch some
incompatibilities (e.g., f64::log10 unavailable in core) and seemingly
across other dependencies as describe here: