This commit adds a new command line option that allows clients to
specify a default value to use when responding to a new channel funding
request. In a future change, a pure mapping will be added, with the
command line option having higher precedence.
Support for regtest allows us to create integration tests to verify
interoperability with other implementations. This seems to work, and
allows to connect to `btcd` and indirectly to `bitcoind` so we can run
lnd on the same network as eclair and c-lightning.
For details about my integration framework check this repo:
cdecker/lightning-integration
The btclog package has been changed to defining its own logging
interface (rather than seelog's) and provides a default implementation
for callers to use.
There are two primary advantages to the new logger implementation.
First, all log messages are created before the call returns. Compared
to seelog, this prevents data races when mutable variables are logged.
Second, the new logger does not implement any kind of artifical rate
limiting (what seelog refers to as "adaptive logging"). Log messages
are outputted as soon as possible and the application will appear to
perform much better when watching standard output.
Because log rotation is not a feature of the btclog logging
implementation, it is handled by the main package by importing a file
rotation package that provides an io.Reader interface for creating
output to a rotating file output. The rotator has been configured
with the same defaults that btcd previously used in the seelog config
(10MB file limits with maximum of 3 rolls) but now compresses newly
created roll files. Due to the high compressibility of log text, the
compressed files typically reduce to around 15-30% of the original
10MB file.
This commit fixes a bit of a wart in the configuration file handling
wherein if the config file isn’t found, an error was printed to stderr.
At times, this would cause the testing framework to erroneously mark as
test as failed. Instead, we now keep a particular config file error,
and check that, printing to a warning log level.
This commit fixes a bug introduced by the new multi-chain features of
and which disallowed multiple nodes from beings started locally.
Previously if two local nodes were set to, the _same_ chain, then
they’d both share the same chain data directory which would prevent one
of the nodes from being able to start up properly.
This commit modifies the existing configuration to create instances
that are capable of housing configuration options for a particular
chain such as the rpcuser or rpcpass to distinct structures within
greater configuration. With this new change, it will now be possible
for lnd to be resident on either the litecoin testnets, with simple a
toggle in the main configuration.
The new configuration file will look like the following:
[Bitcoin]
bitcoin.active
bitcoin.testnet=1
bitcoin.rpcuser=kek
bitcoin.rpcuass=kek
Similarly, one would mirror a similar set up in order to be active on
the latest litecoin testnet.
Error `connection refused` was thrown when user tries to get "Alice" to
connect to "Bob" node due to port mismatch introduced in this change [1]
here.
This commit updates the port value to reflect the new change introduced in
[1].
Reference: [1]
72772ce4df
Chanes in this commit:
* Update references to old port value
* Omit specifying port during lncli connect
* Fix typo
A common pitfall with new users setting up lnd on test net has been
observed to be the initial RPC credential set up between btcd and lnd.
As of a recent version of btcd now performs automatic RPC credential
set up by generating a random rpcuser and rpcpass on start up.
We now take advantage of this by reading the RPC credentials (if
possible and running in simmer mode). As a result, it is now possible
to simply run: `lnd—testnet` assuming a fresh installation of bcd (with
a set btcd.conf).
Fixes#68.
This commit alters the configuration parsing a bit along with the
documentation to expect the RPCHost configuration paramter to also have
the target port specified. If the port isn’t included, then the default
btcd RPC port for that chain is used.
Additionally, within the integration testing framework, when creating
the lnd nodes, we now use the configuration from the btcd harness to
set the proper RPC host.
This commit revamps the way in bound and outbound connections are
handled within lnd. Instead of manually managing listening goroutines
and also outbound connections, all the duty is now assigned to the
connmgr, a new btcsuite package.
The connmgr now handles accepting inbound (brontide) connections and
communicates with the server to hand off new connections via a
callback. Additionally, any outbound connection attempt is now made
persistent by default, with the assumption that (for right now),
connections are only to be made to peers we wish to make connections
to. Finally, on start-up we now attempt to connection to all/any of our
direct channel counter parties in order to promote the availability of
our channels to the daemon itself and any RPC users.
This commit adds a new configuration parameter to the deamon:
‘DebugHTLC’. When true, all outgoing HTLC’s sent via the RPC interface
will be sent paying to a special rHash value which all lnd nodes also
with the flag activated know the preimage to. Therefore all payments
sent to a 1-hop node will immediately be settled by that node.
By default, this flag is false, it it only intended to be used to
exercise local changes to 1-hop behavior manually.
This commit adds an option to pass in a raw hex-encoded rpc cert via
lnd’s configuration file. Such a change allows for programmatically
creating lnd nodes which can connect to an existing btcd instance
without requiring a file for the rpc cert to be specified.
Additionally, this commit makes the creation of an integration testing
harness easier.
With this commit, support for changing the target network (testnet,
simnet, etc) has been finalized. Previously a command line option was
present to swap networks, but the RPC port wouldn’t automatically be
updated to reflect the network.
