This commit renames the confusing noencryptwallet
flag to noseedbackup, since this highlights the more
crucial information of the flags behavior to the user.
The description has also been capitalized to urge
the user think twice about what they're doing.
Due to recent changes to the BitcoindClient interface, we now require
the backing bitcoind to use different hosts for its ZMQ raw block and
raw transaction notifications. This was needed as the notification queue
maintained by the bitcoind node would sometimes overflow with
transactions and cause block notifications to be dropped/missed.
In this commit, we expand extractBitcoindRPCParams to account for this.
In the event that the default Tor DNS host wouldn't resolve, it would
prevent `lnd` from starting due to the failed lookup. This should fail
silently as it's only crucial during bootstrapping. However, if the user
has explicitly modified this, we should let them know of the error
immediately.
In this commit, we update all the lncfg methods used to properly pass in
a new resolver. This is required in order to ensure that we don't leak
our DNS queries if Tor mode is active.
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 to allow (ideally
routing nodes) to disable receiving up-to-date channel updates all
together. This may be desired as it'll allow routing nodes to save on
bandwidth as they don't need the channel updates to passively forward
HTLCs. In the scenario that they _do_ want to update their routing
policies, the first failed HTLC due to policy inconsistency will then
allow the routing node to propagate the new update to potential nodes
trying to route through it.
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.
lnd can't detect bitcoind configuration if the config file has spaces around the = character, e.g.:
```
zmqpubrawblock = tcp://127.0.0.1:28332
zmqpubrawtx = tcp://127.0.0.1:28332
rpcuser = rpcuser
```
I had to dig into the source code to understand what was wrong.
This patch solves this problem, bitcoind's config parsing source code can be seen at https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp
Fixed formatting for autopilot config params, as well as added check for
`MaxChannels` param which was presumably a mistaken copypaste from the
`MaxChannelSize' param.
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.
In this commit, we add two new configuration parameters to allow users
to specify the min and max size that the autopilot agent will create.
This is useful as now users can set the values to more or less the same
size, which will allow them to control the size of each created
channel.
Before this commit, if this wasn’t set, then the agent would try to
shove as much money into a channel up until the max chan size. This was
nice on testnet, but on main net, users will likely not want all their
funds to be in a single channel, and instead be distributed across many
channels. With things like AMP, have more channels becomes more
desirable.