This commit lets the watchtower automatically create hidden services
by giving it a pointer to a TorController. The server was also slightly
refactored so that it was not the sole owner of the TorController.
After renewing the certificate, the new certificate wasn't actually
loaded and used, causing the old one to be used until lnd was restarted.
This fixes that by reloading it after it has been written.
This commit makes lnd recreate its TLS certificate if the config's
tlsextradomains or tlsextraips changed. This is useful, since earlier
user would have to manually delete the files to trigger lnd to recreate
them.
To ensure users don't accidentally have their TLS certificate recreated,
we gate it behind a flag --tlsautorefresh that defaults to false.
Adds a global Authenticate method that can be used to get the
atuhentication options needed to call the grpc server.
Currently meant only for used with the mobile bindings, so we use the
admin macaroon.
Earlier we used emtpy grpc server options if custom listeners were set.
This was done to disable TLS. Now, we reuse the same server options as
for the regular listeners, in a move towards enabling TLS also here.
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.
Some time ago, we modified `lncli` to accept larger responses from the
server, up to 50MB. However, we failed to update the REST proxy, which
is in a sense, a client to the regular RPC server. As a result, users
can't currently hit the `/v1/graph` endpoint, as it'll fail with an
error.
In this PR, we update the proxy's dial options to allow it to receive
larger responses from the actual gRPC server. This is only a temporary
measure however, as we'll eventually want to expose some sort of
pagination for the end client.
The server was kept alive long after it stopped being used. This caused
problems for services using long-lived GRPC connections which might be
created before wallet unlocked. They got stuck connected to the wallet
unlock service needing a restart.
With the introduction of the WatchtowerClient RPC subserver, the lnd
configuration flag to specify private watchtowers for the client is no
longer needed and can lead to confusion upon users. Therefore, we remove
the flag completely, and only rely on the watchtower client being active
through a new --wtclient.active flag.
In this commit, we establish a new pattern to always log errors before
returning them to the higher level caller, which then prints the error
to stdout/stderr. Errors returned are usually lowercase, but we decide
not to apply this rule here as these errors should not be chained
forward.
A cleanup closure is not included when an error is returned, causing the
defer to execute and triggering the following panic:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x105da38]
goroutine 1 [running]:
github.com/lightningnetwork/lnd.Main(0x2083e40, 0xc0004f6db0)
/home/user/lnd/lnd.go:208 +0x2bfa
main.main()
/home/user/lnd/cmd/lnd/main.go:14 +0x26
This commit restructures the creation of various tls related object. It
also fixes a bug where wildcard IP addresses where only instantiated for
the main RPC server and not the WalletUnlocker service.
In this commit, we modify the server to serve the role as the agent
which will carry out the SCB restoration protocol if the Init/Unlock
methods include a set of channels to be recovered.
In this commit, we slightly refactor the startup of lnd when running
with a Neutrino light client backend. We'll now begin syncing our
backend as soon as lnd starts and passes all configuration checks. Since
this is all done before lnd's wallet setup, the light client will be
syncing in the background while the user notes/inputs their wallet seed.
This is done in order to provide a better UX from the point of the user,
such that most of the chain will already be synced by the time they get
to deposit funds into the wallet.
This commit moves the responsibility of managing the life cycle of the
autopilot from main to the autopilot Manager. It utilizes the recently
introduced autopilot Manager, and just sets up the necessary interfaces
for the Manager to properly set up the required subscriptions when
starting the agent.
In this commit, we modify the existing rpcServer to fully manage the
macaroons, gRPC server, and also seek out and create all sub-servers.
With this change, the RPC server gains more responsibility, as it
becomes the "root" server in the hierarchy of gRPC sub-servers.
In addition to creating each sub-server, it will also merge the set of
macaroon permissions for each sub-server, with the permissions of the
rest of the RPC infra. As a result, each sub-server is able to
independently specify what it needs w.r.t macaroon permissions and have
that taken care of by the RPC server. In order to achieve this, we need
to unify the creation of the RPC interceptors, and also fully manage the
gRPC server ourselves.
Some examples with various build configs:
```
⛰i make build
Building debug lnd and lncli.
go build -v -tags="dev" -o lnd-debug -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.5-beta-143-gb2069914c4b76109b7c59320dc48f8a5f30deb75-dirty" github.com/lightningnetwork/lnd
go build -v -tags="dev" -o lncli-debug -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.5-beta-143-gb2069914c4b76109b7c59320dc48f8a5f30deb75-dirty" github.com/lightningnetwork/lnd/cmd/lncli
⛰i ./lnd-debug --debuglevel=debug --signrpc.signermacaroonpath=~/sign.macaroon
unknown flag `signrpc.signermacaroonpath'
unknown flag `signrpc.signermacaroonpath'
⛰i make build tags=signerrpc
Building debug lnd and lncli.
go build -v -tags="dev signerrpc" -o lnd-debug -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.5-beta-143-gb2069914c4b76109b7c59320dc48f8a5f30deb75-dirty" github.com/lightningnetwork/lnd
go build -v -tags="dev signerrpc" -o lncli-debug -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.5-beta-143-gb2069914c4b76109b7c59320dc48f8a5f30deb75-dirty" github.com/lightningnetwork/lnd/cmd/lncli
⛰i ./lnd-debug --debuglevel=debug --signrpc.signermacaroonpath=~/sign.macaroon
2018-10-22 17:31:01.132 [INF] LTND: Version: 0.5.0-beta commit=v0.5-beta-143-gb2069914c4b76109b7c59320dc48f8a5f30deb75-dirty, build=development, logging=default
2018-10-22 17:31:01.133 [INF] LTND: Active chain: Bitcoin (network=simnet)
2018-10-22 17:31:01.140 [INF] CHDB: Checking for schema update: latest_version=6, db_version=6
2018-10-22 17:31:01.236 [INF] LTND: Primary chain is set to: bitcoin
2018-10-22 17:31:02.391 [INF] LNWL: Opened wallet
2018-10-22 17:31:03.315 [INF] LNWL: The wallet has been unlocked without a time limit
2018-10-22 17:31:03.315 [INF] LTND: LightningWallet opened
2018-10-22 17:31:03.319 [INF] LNWL: Catching up block hashes to height 3060, this will take a while...
2018-10-22 17:31:03.320 [INF] HSWC: Restoring in-memory circuit state from disk
2018-10-22 17:31:03.320 [INF] LNWL: Done catching up block hashes
2018-10-22 17:31:03.320 [INF] HSWC: Payment circuits loaded: num_pending=0, num_open=0
2018-10-22 17:31:03.322 [DBG] LTND: Populating dependencies for sub RPC server: Signrpc
```
As for the config, an example is:
```
[signrpc]
signrpc.signermacaroonpath=~/signer.macaroon
```
This PR adds the configuration needed to run LND with Litecoin on simnet. The change is minimal and has no impact for users that don't enable this mode. When using this configuration, the user is being warned that this mode is not officially supported.
In this commit, we ensure that we always set the wallet birthday. If the
user has provided a seed, or is creating a new one, then it will be
overwritten below. However, before this commit, if a user started with
the --noencryptwallet flag, then we would _always_ start to rescan from
genesis with the recent bug fix to ensure that we always start after the
birthday.
In this commit, we move the initialization of the server into the
funding manager itself. We do this as it's no longer the case that _any_
RPC needs to access the funding manager. In the past, this was the
only reason that the funding manager was instantiated outside of the
server: to be able to respond to queries _before_ the server was
started.
This change also fixes a bug as atm, the funding manager will try to
register for notifications _before_ the ChainNotifier itself has fully
started.
callbacks
The FindPeer and SendToPeer callbacks are no longer needed within the
fundingManager due to the previous commit allowing us to send messages
to peers directly.
In this commit, we fix a slight bug recently introduced by the addition
of the new signal package. As we now use a regular defer for many
actions, it may be possible that the logs aren't yet initialized (for
example, lnd -h), which can cause a panic if the shutdown procedure goes
to log before the logs have been initialized.
In this commit, we update the set of Tor flags to use sane defaults when
not specified. We also include some new flags related to the recent
onion services changes. This allows users to easily get set up on Tor by
only specifying the tor.active flag. If needed, the defaults can still
be overridden.
In this commit we add a new command line option (and a sane default) to
allow users to specify the *smallest* inbound channel that they'll
accept. Having a higher-ish limit lets users limit their channels, and
also avoid a series of very low value "spam" channels.
The new option is --minchansize, and expressed in satoshis. If we
receive an inbound channel request for a value smaller than this, then
we'll immediately reject it.
In this commit, we fix a minor bug in the prior versions of lnd. Before
this commit, if we received a new inbound connection for channel
creation, the channel was created, and then the peer disconnected, we
wouldn't automatically reconnect.
In this commit we fix this issue by overloading the WatchNewChannel
method to also accept the peer's ID so we can add it to the set of
persistent connections.
In this commit, we wrap up the prior ones and introduce config
settings, as well as proper generation for a new invoice-only macaroon.
All prior invoice path rules are also properly enforced of this new
invoice.macaroon.
