In this commit, we modify the parsing of user provided outpoints to
ensure that we catch a nil (empty) output early. Otherwise, passing a
set of incorrect arguments would cause `lnd` to crash.
This RPC exposes the recently added BumpFee functionality to the
UtxoSweeper in order to allow users of the RPC to manually bump fees of
low fee inputs/transactions.
This commit exposes the three main parameters that influence mission
control and path finding to the user as command line or config file
flags. It allows for fine-tuning for optimal results.
Previously every payment had its own local mission control state which
was in effect only for that payment. In this commit most of the local
state is removed and payments all tap into the global mission control
probability estimator.
Furthermore the decay time of pruned edges and nodes is extended, so
that observations about the network can better benefit future payment
processes.
Last, the probability function is transformed from a binary output to a
gradual curve, allowing for a better trade off between candidate routes.
This PR replaces the previously used edge and node ignore lists in path
finding by a probability based system. It modifies path finding so that
it not only compares routes on fee and time lock, but also takes route
success probability into account.
Allowing routes to be compared based on success probability is achieved
by introducing a 'virtual' cost of a payment attempt and using that to
translate probability into another cost factor.
This commit upgrades the protobuf version. Compared to the previous
v1.2.0 it generates smaller diffs in generated code. This change was
introduced in:
fffb0f7828
This fixes a bug where the RHashStr field on the PaymentHash request for
SubscribeSingleInvoice was being ignored. This replaces the PaymentHash
message for the SubscribeSingleInvoice request with a new message called
SubscribeSingleInvoiceRequest that contains only the RHash field.
This commit modifies the invoice registry to handle invoices for which
the preimage is not known yet (hodl invoices). In that case, the
resolution channel passed in from links and resolvers is stored until we
either learn the preimage or want to cancel the htlc.
This commit moves the query routes backend logic from the main
rpc server into the sub server. It is another step towards splitting up
the main rpc server code.
In addition to this, a unit test is added to verify rpc parameter
parsing.
Now that QueryRoutes gained the ability to route from any source node
and takes in edge and node black lists, all pieces are in place to have
users implemented their own k-shortests path algorithm. Or any other algorithm
they might wish to use and currently can't.
This commit marks the num_routes field as deprecated as a preparation
for removing k-shortest for lnd.
This commit allows the execution of QueryRoutes to be controlled using
lists of black-listed edges and nodes. Any path returned will not pass
through the edges and/or nodes on the list.
In this commit, we add two new address types to `NewAddressRequest`.
These address types will allow the caller to retrieve the last _unused_
address, rather than always rotating to the next address in the
keychain.
In this commit, we rename the new `MaxHtlc` field to `MaxHtlcMsat`. We
do this in order to adhere to the new practice to suffix each amount
related field with their proper unit.
In this commit, we implement the full RouterServer as specified by the
newly added sub-service as defined in router.proto. This new sub-server
has its own macaroon state (but overlapping permissions which can be
combined with the current admin.macaroon), and gives users a simplified
interface for a gRPC service that is able to simply send payment. Much
of the error reporting atm, is a place holder, and a follow up commit
will put up the infrastructure for a proper set of errors.
This commit is a step to split the lnwallet package. It puts the Input
interface and implementations in a separate package along with all their
dependencies from lnwallet.
Update is necessary to get protoc to generate files in the right
directory when using modules outside the gopath. The old version of this
dependency did not support paths=source_relative.
This commit also fixes a build error in lnd_test.go because of a
slight difference in generated code.
This commit adds a new service lnrpc/autopilot, that is to be used to
communicate with the running autopilot. Currently a RPC for getting the
status of the agent is included, as well as enabling/disabling at
runtime.
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)
In this commit, we implement the newly defiend WalletKitServer gRPC
service. We use the same template w.r.t build tags as the existing
signrpc service.
In this commit, we add a new sub-RPC server to the existing set of gRPC
servers. This new sub-RPC server is the WalletKit. It's a utility
toolkit that contains method which allow clients to perform common
interactions with a wallet such as getting a new address, or sending a
transaction. It also includes some supplementary actions such as fee
estimation.
One thing to note in the RPC file is that we _import_ the existing
signer.proto file in order to get at some existing proto definitions
which are useful in our use case.
In this commit, we add the ComputeInputScript which will allow callers
to obtain witnesses for all outputs under control of the wallet. This
allows external scripting of things like coin join, etc.
In this commit, we add the glue infrastructure to make the sub RPC
server system work properly. Our high level goal is the following: using
only the lnrpc package (with no visibility into the sub RPC servers),
the RPC server is able to find, create, run, and manage the entire set
of present and future sub RPC servers. In order to achieve this, we use
the reflect package and build tags heavily to permit a loosely coupled
configuration parsing system for the sub RPC servers.
We start with a new `subRpcServerConfigs` struct which is _always_
present. This struct has its own group, and will house a series of
sub-configs, one for each sub RPC server. Each sub-config is actually
gated behind a build flag, and can be used to allow users on the command
line or in the config to specify arguments related to the sub-server. If
the config isn't present, then we don't attempt to parse it at all, if
it is, then that means the RPC server has been registered, and we should
parse the contents of its config.
The `subRpcServerConfigs` struct has two main methods:
`PopulateDependancies` and `FetchConfig`. The `PopulateDependancies` is
used to dynamically locate and set the config fields for each new
sub-server. As the config may not actually have any fields (if the build
flag is off), we use the reflect pacakge to determine if things are
compiled in or not, then if so, we dynamically set each of the config
parameters. The `PopulateDependancies` method implements the
`lnrpc.SubServerConfigDispatcher` interface. Our goal is to allow sub
servers to look up their actual config in this main config struct. We
achieve this by using reflect to look up the target field _as if it were
a key in a map_. If the field is found, then we check if it has any
actual attributes (it won't if the build flag is off), if it is, then we
return it as we expect it to be populated already.
