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.
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.
Here we set start_time to 24 hours prior
if it's not provided on the CLI. The
effect of this is when you don't provide
a start_time:
CLI: -24h
RPC: Unix Epoch
Fixes https://github.com/lightningnetwork/lnd/issues/3357. When
start_time isn't specified, its default value is 0. This meant when
users explicitly specified a start_time of 0, we would incorrectly set
start_time to 24 hours in the past. Now, n0 means n0.
ListenerCfg allows passing custom listeners to the main method, to be
used for the wallet unlocker and rpc server. If these are set these will
be used instead of the regular RPC listeners.
This commit modifies paymentLifecycle so that it not only feeds
failures into mission control, but successes as well.
This allows for more accurate probability estimates. Previously,
the success probability for a successful pair and a pair with
no history was equal. There was no force that pushed towards
previously successful routes.
Previously mission control tracked failures on a per node, per channel basis.
This commit changes this to tracking on the level of directed node pairs. The goal
of moving to this coarser-grained level is to reduce the number of required
payment attempts without compromising payment reliability.
In this commit, we add two new cli commands: exportchanbackup and
restorechanbackup. These two commands allow users to export backups
(single or multi) for one or all channels, and also restore these
backups (single or multi) from a file to attempt to recover the
channels.
Additionally, we extend the `lncli create` call to also accept these
backups so users can have a single command to restore both their
on-chain and off-chain funds.
Increases the default window from 250 to 2.5k. Many
users have reported attempting recovery with the
default value only to find an empty wallet. This
change should help ensure that the first recovery
attempt succeeds for the majority of nodes that
have modest load. It might prudent to consider
increasing this value further in the future if
the issue persists or average node age increases.
In this commit, we add a new flag to the sendcoins command that allows
callers to sweep all funds out of the daemon's wallet. This CANNOT be
set at the same time that an amount is specified.
In this commit, we increase the gRPC block size from 4MB to 50MB.
Recently, the output of `lncli describegraph` has hit the block size cap
due to the expansion of the mainnet graph. Without this attempts to
fetch the graph returns an error of:
```
[lncli] rpc error: code = ResourceExhausted desc = grpc: received message larger than max (4246753 vs. 4194304)
```
With this commit, we give ourselves some breathing room. It's important
to note that the max message size limit is a _client side_ setting. As a
result, any developers driving `lnd` with gRPC will also need to raise
their block size limit as well if they wish to fetch the graph over
gRPC.
Returns a brief json summary of each utxo found by calling
ListUnspentWitness in the wallet. The two arguments are the
minimum and maximum number of conrfirmations (0=include
unconfirmed)
Move num_inactive_channels closer to num_active_channel,
best_header_timestamp closer to block_hash/block_height and version as
first item in the list.
Private and public channels which weren't announced yet are returned only
if the flag is set.
Note: this changes the default output of describegraph which used to
return all channels known to node.
Using AbandonChannel, a channel can be abandoned. This means
removing all state without any on-chain or off-chain action.
A close summary is the only thing that is stored in the db after
abandoning.
A specific close type Abandoned is added. Abandoned channels
can be retrieved via the ClosedChannels RPC.
