Probabilities are no longer returned for querymc calls. To still provide
some insight into the mission control internals, this commit adds a new
rpc that calculates a success probability estimate for a specific node
pair and amount.
With a separate proto message, it becomes possible to also return the
pair data for a single pair. This prepares for the new mc probability
querying rpc.
This prepares for decoupling the result interpretation of a single
payment attempt from the information stored in mission control memory
on the history of a node pair. A planned follow-up where we store both
the last success and last failure requires this decoupling.
This commit changes mission control to partially base the estimated
probability for untried connections on historical results obtained in
previous payment attempts. This incentivizes routing nodes to keep all
of their channels in good shape.
Probability estimates are amount dependent. Previously we assumed an
amount, but that starts to make less sense when we make probability more
dependent on amounts in the future.
This commit modifies the interpretation of node-level failures.
Previously only the failing node was marked. With this commit, also the
incoming and outgoing connections involved in the route are marked as
failed.
The change prepares for the removal of node-level failures in mission
control probability estimation.
This commit changes the in-memory structure of the mission control
state. It prepares for calculation of a node probability. For this we
need to be able to efficiently look up the last results for all channels
of a node.
Earlier GetCFilter could return a nil-error along with a nil-filter in
cases where we failed to fetch the filter. We would just ignore the
block causing us to miss potential crucial information.
Now that GetCFilter will return an error in cases where the fetch
failed, the filter will never be nil (even for blocks with only coinbase
transactions), and we'll instead return an error.
We also increase the number of retries for the filter from the default 2
to 5.
This sets the `jstype` option to `JS_STRING` for all `chan_id` fields
in the proto rpc definition. `chan_id` is a 64 bit integer, which is
not natively supported by javascript's floating-point `number` with
only 52 bit precision. Nevertheless, by default protobuf will use the
`number` type for 64 bit integer fields in javascript, which can cause
loss of precision problems with `chan_id`. Explicitly setting the type
for javascript as a string will prevent these issues, and should not
interfere with its use as an identifier.
Because the BestBlock method of ChainIO is not exposed through any
RPC we want to get rid of it so we can use the sweeper outside of
lnd too. Since the chain notifier now also delivers the current best
block we don't need the BestBlock method any more.
The previous limit of 1008 proved to be low, given that almost 50% of
the network still advertises CLTV deltas of 144 blocks, possibly
resulting in routes with many hops failing.
With the introduction of the max CLTV limit parameter, nodes are able to
reject HTLCs that exceed it. This should also be applied to path
finding, otherwise HTLCs crafted by the same node that exceed it never
left the switch. This wasn't a big deal since the previous max CLTV
limit was ~5000 blocks. Once it was lowered to 1008, the issue became
more apparent. Therefore, all of our path finding attempts now have a
restriction of said limit in in order to properly carry out HTLCs to the
network.
