We use a wrapper around the MCF solver that takes care of finding the
best linearization parameters and fixing the flow values to meet the
htlc_min and htlc_max constraints.
We have reworked the current implementation and made it a bit more
similar to renepay's version.
Out of 50000 simulated payment situations distributed accross payment
amounts of 1e2, 1e3, 1e4, 1e5 and 1e6 sats, we find that 133 failed
cases in the master branch turn to success with the current changes,
while only 3 success cases in the master are not solved by the changes.
master
+-------+------+
| S | F |
+---+-------+------+
| S | 46329 | 133 |
changes +---+-------+------+
| F | 3 | 3535 |
+---+-------+------+
Out of the 133 cases that flipped from failure to success the failed
reasons were:
122 -> "Could not find route without excessive cost"
5 -> "We couldn't quite afford it"
5 -> "Amount *msat below minimum"
1 -> tripped an HTLC min check
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
by a small amount if the deliver amount is less than the requested
amount by X.
This step saves runtime by avoiding calling an extra MCF
and it helps us solve a small percentage of cases where the only
available routes have HTLCmin that is bigger than X.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Disable channels with HTLC min violations so that we don't hit them
twice when computing routes.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Try a new way to refine flows,
ie. reduce excess due to MCF accuracy and HTLC max constraints
after hop amounts are computed with fees included.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Added: clnrest can now return successful responses as xml, yaml, or form-encoded in addition to json defined in the 'Accept' header. The same goes for request types defined in the 'Content-type' header.
Changelog-Changed: wss-proxy.py was replaced by a rust version with support for multiple `wss-bind-addr`. If you install CLN from pre-compiled binaries you must remove the old wss-proxy directory first before installing CLN, usually
it is located in `/usr/local/libexec/c-lightning/plugins/wss-proxy`. If you compile from source `make` will take care of this automatically.
From the multiple arcs that derive from the same channel we consider
only those with the smallest cost such that the payment amount and HTLC
max can fit in their combined capacity, ie. we prune high cost arcs that
surely will never be used by the optimal solution.
This reduces the number of arcs in the graph approximately from 8 arcs
per channel to approximately 2 arcs per channel.
No pruning.
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 837928 849304 852856 853232 853328
Prune, limit the channel capacity by its HTLC max
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 255502 259314 260538 260676 260704
Prune, limit the channel capacity to the payment amount
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 209482 216270 228618 295450 432468
Prune, limit the channel capacity to the payment amount and its HTLC max
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 209480 212324 213242 215726 228018
This produces a slight speedup for MCF computations:
Amount (sats) | speedup
-----------------------
100 | 1.89
1000 | 1.77
10000 | 1.25
100000 | 1.25
1000000 | 1.18
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Added: askrene: an optimal single-path solver has been added, it can be called using the developer option --dev_algorithm=single-path or by adding the layer "auto.no_mpp_support"
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
The single path solver uses the same probability cost and fee cost
estimation of minflow. Single path routes computed this way are
suboptimal with respect to the MCF solution but still are optimal among
any other single path. Computationally is way faster than MCF, therefore
for some trivial payments it should be prefered.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Refactor MCF solver: remove structs linear_network and residual_network.
Prefer passing raw data to the helper functions.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
It was originally a wrapper for JSON param() results, but now it's a more
generic struct. So make it clear that the fields are not optional. This
means a manual assignment in the initial population of this struct, but
all the users are now far clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Move the feature tuning algorithm to mcf.c, ie. the loops for searching
a good mu and delay_feefactor to satisfy the problem constraints.
We are looking to set the stage for an execution logic that allows for
multiple choices of routing algorithms, mainly for experimenting without
breaking the default working code.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Add log information about the runtime of getroutes.
Changelog-None: askrene: add runtime of getroutes to the logs
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Before vs after:
- `forwards` indexed by `in_channel and in_htlc_id` (see lightning-listforwards(7))
- `forwards` indexed by `in_channel` and `in_htlc_id` (see lightning-listforwards(7))
And:
- `htlcs` indexed by `short_channel_id and id` (see lightning-listhtlcs(7))
- `htlcs` indexed by `short_channel_id` and `id` (see lightning-listhtlcs(7))
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We picked one node and iterated. This means we would only sent to 1,
not 2 nodes if we picked the last (common if there were only a few
peers). But it also means we would generally send to the same pair of
nodes, which isn't great for redundancy.
Rework to be more random.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They will in fact get truncated, and never restore. Large nodes should be using some real
backup strategy!
For this reason, we split "peer_backup" support into send vs store support, so we can
turn off send of our own without disabling storing/sending theirs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We already get the connected hook, so in there we can add to a hash
table of suitable peers. Rather than subscribe to disconnection, we
simply remove the peer if a sendcustommsg fails.
This does make after_send_scb_single() a bit more complex, since it
needs this specific node_id: we use a `struct info` per node and a
pointer to a shared "idx" reference counter.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
By keeping a local hash table, we won't have to look up every time.
We still write to the datastore when it changes, and we need to
initialize it at plugin start.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Change order of operations to ensure that askrene-inform-channel with
inform=constrained computes the correct upper bound on the liquidity:
upperBound = reserves + amount - 1
With the previous order of operations in the case amount=0 we would get:
upperBound = reserves
instead of
upperBound = reserves - 1
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
The result of splice_signed can fail for many reasons that are non-critical (already in mempool for instance).
Don’t abort channels in this case as that causes a force close.
We cannot add new parameters in the middle, since we accept parameters by JSON
array as well as by dicts. In fact, this broke tests, but due to unrelated
breakage in the GitHub "Automerge" functionality, it got applied as
556e38c838 ("askrene-bias-channel: bias call add
up.").
Also add tests, and a better Changelog line.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `askrene-bias-channel` now has a `relative` option to add, rather than replace, a channel bias.
The channel bias feature is not being used yet by any plugin, so this
hopefully doesn't break any working code.
When askrene-bias-channel is called the bias quantity is added on top of
any previous biased already present on that channel instead of
overwriting it.
Changelog-Changed: askrene-bias-channel: bias call add up.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Reported-by: daywalker90
Changelog-Deprecated: JSON-RPC: channel_state_changed notification field `old_state` value "unknown" (it will be omitted, instead)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
