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.
In this commit, we ensure all paths to directories and files related to
LND are cleand and expanded before attempting to use them.
For example, in POSIX systems:
- ~/lnd.conf would be expanded to /home/user/lnd.conf
- $HOME/lnd.conf would be expanded to /home/user/lnd.conf
Since we're now able to create a base LND directory that no longer lives
under the OS specific application data directory, we modify
cleanAndExpandPath to replace the `~` in a path to the current user's
home directory, rather than the user's application data directory.
In this commit, we introduce a new flag `--lnddir` that allows us to
set a different base directory, other than the OS specific application
data directory, for all related lnd files and directories.
This commit adds the `tlsextraip` flag to the cli to add an
ip to the generated certificate. This is usefull when using
a loadbalancer to access the node.
This commit adds the `lnnet` package which contains an
implementation of the newly created LightningNet interface which
multiplexes the Dial and DNS-related functions to use net
by default and torsvc if a flag is specified. This modularization
makes for cleaner code.
This commit adds a new interface named NetInterface and two
implementations of it: RegularNet & TorProxyNet. These two structs
are used in config.go in an attempt to clean up the code and
abstract away the dialer and DNS functions.
This commit adds a new module named 'torsvc' which houses all Tor
functionality in an attempt to isolate it and make it reusable in
other projecs. Some additional tweaks were made to config.go and
to the bootstrapper.
This commit adds Tor support. Users can set the --TorSocks flag
to specify which port Tor's SOCKS5 proxy is listening on so that
lnd can connect to it. When this flag is set, ALL traffic gets
routed over Tor including DNS traffic. Special functions for
DNS lookups were added, and since Tor doesn't natively support
SRV requests, the proxySRV function routes connects us to
a DNS server via Tor and SRV requests can be issued directly
to the DNS server.
Co-authored-by: MeshCollider <dobsonsa68@gmail.com>
In this commit, we add an additional constraint to the RPC
configuration parsing. Before this commit, it was possible to start lnd
with either RPC server listening on an external interface *without*
authentication disabled. After this commit, if a user tries to start
the RPC server listening on an external interface without any sort of
RPC authentication, then the daemon will fail to start up.
This commit causes the configuration parser to accept the values of
RPCUser, RPCPass, and (for the bitcoind back-end) ZMQPath configured
in lnd.conf or on the command line ONLY when all are specified. It
causes the configuration parser to look in btcd.conf or bitcoin.conf
ONLY when none are specified, and causes an error to be returned when
only some are specified, as users have done so erroneously and the
lack of clear feedback has caused difficulties.
In this commit, we add 6 new integration tests to test the various
actions that may need to be performed when either side goes on-chain to
fully resolve HTLC’s. Many of the tests are mirrors of each other as
they test sweeping/resolving HTLC’s from both commitment transactions.
This commit removes the `peerport` and `rpcport` config options and
adds `listen`, `rpclisten`, and `restlisten` options to allow setting
one or multiple interfaces to listen on for incoming connections.
It also adds a `nolisten` option to allow disabling the listener for
incoming peer connections.
This commit factors out the btcd and ltcd options into their own sections
similar to neutrino, and adds a bitcoind section as well. Now, you specify
node options similarly to:
--ltcd.rpchost=...
or
--btcd.rpcuser=...
or
--bitcoind.zmqpath=...
For Bitcoin, you specify an alternate back-end to btcd as follows:
--bitcoin.node=bitcoind
or
--bitcoin.node=neutrino
You can also specify the default option:
--bitcoin.node=btcd
For Litecoin, only `btcd` mode is valid, and corresponds to the `ltcd`
section. For example:
--litecoin.node=btcd
--ltcd.rpchost=...
The new code also attempts to read the correct options and auth info
from bitcoin.conf just as it does from btcd.conf/ltcd.conf.
This commit moves the definition of DefaultNumChanConfs into
the chainConfig (such that it is set as e.g.
"--bitcoin.defaultchanconfs"), making it possible to set
individually for different chains.
It also adds the flag DefaultRemoteDelay to the chainConfig,
which can be used to set the CSV delay we will require the remote
to wait before retrieving its own funds in case of an
uncooperative close of the channel.
Both these are set 0 by default (if not specified by the user),
which in that case we will dynamically set the values, scaling
them according to the channel size.
This commit moves the forwarding policy rules for Bitcoin
and Litecoin, previously defined in the chainregistry, to
config.go, making them possible to define by the user.
We validate that the TimeLockDelta set is at least 4, the
other rules we let the user specify arbitrarily, even 0.
In this commit, we increase the default number of confirmations we
require for funding flows from 1 to 3. The value of 1 was rather
unstable on testnet due to the frequent multi-block re-orgs.
Additionally, a value of 3 ensures our funding transaction is
sufficiently buried before we deem is usable.
Early in the lifetime of the project here were a few files we either
copied entirely, or used as the basis for code within lnd. Before this
PR, this was not recognized by retaining the original copyright. With
this commit, we remedy that by explicitly noting the copyright in the
relevant files.
Fixes#423.
Run go fmt so config file is formatted correctly. Also rename
newVertex to NewVertex in pathfind_test and notifications_test
as it is now exported from the routing package.
Add option to set trickleDelay for AuthenticatedGossiper in
command line, with default value of 300 milliseconds. Pass this
value to newServer, which uses it when creating a new instance of
AuthenticatedGossiper. Also set this value to 300 milliseconds when
creating nodes in integration tests.
In this commit we add a new option to lnd, cpuprofile. With this option
we add additional telemetry hooks into and, allowing users to generate
CPU profiling files to measure hot spots within the daemon.
This commit adds a new debug mode for lnd
called hodlhtlc. This mode instructs a node
to refrain from settling incoming HTLCs for
which it is the exit node. We plan to use
this in testing to more precisely control
the states a node can take during
execution.
This commit adds a new config option to allow callers to optionally
disable connection bootstrapping. This may be desirable for several
reasons, but primary, we add this so we can keep our integration tests
under the same context as before bootstrapping existed.
