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.
ProbabilisticScorer tends to prefer longer routes to shorter ones. Make
the default scoring behavior include a customizable base penalty to
avoid longer routes.
`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.
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.
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.
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.
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.
This doesn't (appear) to change behavior, however if we have a
non-public node, we assign an A* heuristic of max-u32 fees, which
may result in us de-prioritizing the path in some rare cases around
multi-hop route hints which compete with public nodes.
When we added support for routing through a multi-hop invoice hint
we failed to remove an assertion that we always are able to fill
in features for each hop except the last one. However, when a
multi-hop invoice hint is used, we will not have features for any
of the hinted hops, causing us to panic.
Add other fields to log for PathBuildingHop
Use DebugStruct to print PathBuildingHop
Fix PathBuildingHop visibility
Add more useful fee print-outs
Remove Features<NodeContext> from hop print-out
Remove logging fields we don’t need
Add fields to log back to PathBuildingHop
The take-self-return-Self idiom in Rust is substantially less
usable than it is in Java, where its more common. Because we have
to take self by move, it prevents using the update methods to
actually update features, something we occasionally want to do.
See, eg, the change in lightning-invoice where we previously had
to copy and re-create an entire vec of fields just to update the
features field, which is nuts.
There are a few places where this makes things a little less clean,
but the tradeoff to enable more effecient and broader uses of the
update methods seems worth it.
The docs were hidden since a type alias should be used. However, the
alias docs don't contain much useful information and don't link to the
corresponding struct.
`cargo bench` sets `cfg(test)`, causing us to hit some test-only
code in the router when benchmarking, throwing off our benchmarks
substantially. Here we swap from the `unstable` feature to a more
clearly internal feature (`_bench_unstable`) and also checking for
it when enabling test-only code.
ProbabilisticScorer uses successful and unsuccessful payments to gain
more certainty of a channel's liquidity balance. Decay this knowledge
over time to indicate decreasing certainty about the liquidity balance.
Add a Score implementation based on "Optimally Reliable & Cheap Payment
Flows on the Lightning Network" by Rene Pickhardt and Stefan Richter[1].
Given the uncertainty of channel liquidity balances, probability
distributions are defined based on knowledge learned from successful and
unsuccessful attempts. Then the negative log of the success probability
is used to determine the cost of routing a specific HTLC amount through
a channel.
[1]: https://arxiv.org/abs/2107.05322
A channel's capacity may be inferred or learned and is used to make
routing decisions, including as a parameter to channel scoring. Define
an EffectiveCapacity for this purpose. Score::channel_penalty_msat takes
the effective capacity (less in-flight HTLCs for the same payment), and
never None. Thus, for hops given in an invoice, the effective capacity
is now considered (near) infinite if over a private channel or based on
learned information if over a public channel.
If a Score implementations needs the effective capacity when updating a
channel's score, i.e. in payment_path_failed or payment_path_successful,
it can access the channel's EffectiveCapacity via the NetworkGraph by
first looking up the channel and then specifying which direction is
desired using ChannelInfo::as_directed.
Scorers may have different performance characteristics after seeing
failed and successful paths. Seed the scorer with some random data
before executing the benchmark in order to exercise such behavior.
