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.
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 overhauls the way that lnd is created with the goal of
ensuring the chain backends are fully synced up before the daemon
itself starts. The rpcServer has been slightly decoupled from the
server itself s.t we can start the rpcServer independently of the
server. This is required as we’ll now wait (unless we’re in simnet
mode) for the chain to fully sync up before we even _start_ any of the
server’s goroutines.
This commit finishes up the implementation of newChainControlFromConfig
in order to properly initiate the members of the chainControl struct
when the new light client mode (neutrino). With this lnd is now able to
switch over to either mode with a simple configuration change.
This commit adds the FeeEstimator interface, which can be used for
future fee calculation implementations. Currently, there is only the
StaticFeeEstimator implementation, which returns the same fee rate for
any transaction.
This commit modifies the initialization logic within lnd.go to
recognize which chain was selected by the user and to set the
parameters accordingly. With this commit, lnd is now able to switch
between chains within nothing more than a toggle of config paramters!
This commit modifies the fundingManager config to use the a SignMesage
function rather than two distinct functions for singing one half the
channel announcement proofs. This change unifies the signing of
messages under a single abstraction: the MessageSigner interface.
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 unexports the SyncVerions PR, in favor of making it private
and moving it into the .Open() method. With this change, callers no
longer need worry about ensuring the database version is up to sync
before usage, as it will happen automatically once the database is
opened.
This commit also unexports some additional variables within the package
that don’t need be consumed by the public, and exports the
DbVersionNumber attribute on the meta struct. Finally some minor
formatting fixes have neen carried out to ensure the new code more
closely matches the style of the rest of the codebase.
This commit fixes a build error for go 1.6.3. Before go 1.7, the
context package was under the experimental go packages, therefore to
maintain compatibility across our currently supported versions, we must
use the ‘/x/net’ import path.
This commit adds a REST interface to the existing gRPC server by
employing a simple http proxy auto-generated from the existing protobuf
files. Currently full-support for any streaming RPC’s are currently
untested. In addition to auto-generating a REST proxy server, a
swagger.json is also generated which allows for gRPC-like native
objects with higher-level clients, and also for auto-generated
documentation.
Due to limitations with accepting raw byte strings as parameters, some
RPC’s have been modified to take both raw-bytes and string arguments.
Additionally a new RPC has been added ‘NewWitnessAddress’ since the
proxy doesn’t currently support enum-based arguments.
Currently the proxy server is embedded within the daemon as an active
HTTP server, however we may want to package the proxy server as a
separate binary in the future. Similarly, we may want to add additional
configuration information which controls the optional inclusion of the
REST proxy.
Atm, just like the current gRPC interface, the REST API is fully
unauthenticated. Before moving to an initial alpha release after making
the necessary changes to meet the spec drafted in Milan, authentication
of the RPC interfaces will be addressed.
This commit introduces the concept of a manually initiated “force”
closer within the channel state machine. A force closure is a closure
initiated by a local subsystem which broadcasts the current commitment
state directly on-chain rather than attempting to cooperatively
negotiate a closure with the remote party.
A force closure returns a ForceCloseSummary which includes all the
details required for claiming all rightfully owned outputs within the
broadcast commitment transaction.
Additionally two new publicly exported channels are introduced, one
which is closed due a locally initiated force closure, and the other
which is closed once we detect that the remote party has executed a
unilateral closure by broadcasting their version of the commitment
transaction.
This commit modifies the daemon’s initialization within the `lndMain`
method to create an instance of the current default ChainNotifier
outside of the LightningWallet.
At this point, since there are no other implementations of the
ChainNotifier, the current concrete implementation BtcdNotifier is used
by default. In the future, once other ChainNotifier implementations are
in place, config parsing should be fed into a factory function which
creates the proper ChainNotifier implementation.
Finally, several imports have been updated to reflect the change in
package name.
This commit modifies the internal workflow for opening or closing a
channel in order to create a path in which RPC clients can receive
updates. Updates are now communicated via channels from the goroutines
spawned by the RPC server to process the request, and the sub-system
within the daemon that actually executes the request.
With this change clients can now receive updates that the request is
pending (final message has been sent to the target client), or that the
request has been completed. Confirmation related updates have not yet
been implemented as that will require some changes to the ChainNotifier
interface.
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.
This commit adds a new nested main function “lndMain”, within the
packages’s normal main function. This nesting is required in order to
properly execute all queued defer statements in the case of a forced
exit.
To try uspv, do ./lnd -spv
The remote node is hardcoded in shell.go. If you aren't
running a full node on localhost, specify where to connect to.
Nearby nodes will be much faster but random testnet nodes on the
internet should also work.
