To make it possible to replace the swapserverrpc module in the server,
we declare it as its own submodule. This allows the server to make
changes to its local protos (and replace loop's copy with the local
version), to use changes that are not yet merged to the client repo.
Protobuf does not allow naming conflicts for files within the same
process, because all proto messages register themselves in a global
registry.
This is problematic because the server's itests import the client's
looprpc package to make rpc queries to the loopd client, thus importing
duplicate common.proto and server.proto from the client's looprc package
(since they're both in there as well).
This change moves the server's proto files into their own directory so
that they are not imported when we want to use the client's files. We
cannot change the package name for the server, because that would be
a breaking change (the package name is included in URIS). Fortunately,
we have the go_package option which allows us to place generated files
in a different location.
We already have a Label field in the embedded SwapContract
field for loop in swaps. This commit removes an erroneously
added Label field in LoopInContract which may be a cause of
ambiguity when referencing this field.
This commit passes routehints all the way from when/if the user passes
them from the cli all the way to the backend loop server. If private is
used, this commit passes that boolean down to different stages, where it
is then converted into routehints.
main: add --private and --route_hints to quote
Adds --private and --route_hints flags to quote cli
Adding the --private flag informs loopd that the connected node is
considered private (all channels are marked private) and the loop in
server may have trouble routing the payment. To handle this, loopd will
construct some hophints that will be sent to the loopin server to help
route. This commit merely adds the flag to the cli.
In this commit, instead of importing SelectHopHints from lnd, we chose
to reimplement the functionality here, for the purpose of adding hop
hints in case the user informs us the client node is considered private.
In the future, we should modify the origin SelectHopHints to take
closures for all it's data sources, so we can use it's logic external
Add an implementation of our swap interface which can be used for
loop in, and fee estimation. For fee estimation, we always want to
calculate worst case loop in fees, so that autoloop never goes over
its budget. However, for loop in we can't estimate how much a
timeout would cost, because we must sweep the output (can't set
a limit like loop out), and fee estimation in a few hundred blocks
(when we'd sweep the timeout) is totally unreliable.
Instead, we use a high fee rate as our best-effort fee rate for
the future. We can also be confident that that loop in swaps will
succeed, since once the htlc is locked in, all that is required
is for the server to sweep.
In preparation of supporting multiple swap types, we move our swap
builder into a single place, so that we can check our `maySwap`
restriction per-swap (since we'll now have different checks for
different swap types.
To save ourselves from making multiple calls to the loop server for
the restrictions placed on each swap type, we still pass a single
set of restrictions in.
In preparation for adding loop in swaps, we relate liquidity rules
to a specific type of swap that we want to dispatch. This allows us
to use a single rule format for multiple swap types.
The current wording in this function is very specific to loop out.
In this commit, we refactor to use `target` and `reserve` rather
than inbound and outbound so that it can be used more generically.
With this PR we include the final version of the lnd v0.14.0-beta
release to ensure compatibility.
The rationale for choosing Loop version 0.15.1 instead of 0.16.0 is that
this doesn't add any major new features.
To allow code with more up-to-date dependencies to import loop, we
bump our lndclient version. The minimum loop version remains 11.1
since we're not using any new apis.
This makes two changes to handling of errors when configuration file
could not be loaded:
1. Only NotFound errors are considered OK - access errors and other FS
issues are now treated as fatal.
2. Failing to load config file specified explicitly via `--configfile`
option is alway a fatal error.
Rationale: If the configfile was specified explicitly then it indicates
the user really wishes to load it. While the user could want it to be
optionally loaded for extra configuration options, this can be
accomplished using an empty file.
If the config file was not specified explicitly then its' path was
computed from loop directory. If the file is inaccessible due to
permissions or other FS errors it's nearly certain other following
operations will fail as well. Failing early with a clear message is thus
beneficial.
This still leaves room for uncaught user error (e.g. mistakenly naming
config file inside loop dir as `loop.conf` instead of `loopd.conf`) but
it's greatly reduced and such error should be easier to identify.
(Indirectly) closes#412
