In this commit, we extend the initial wallet creation set up case with
the goal of giving the user the ability to restore a prior wallet from
seed, or obtain the mnemonic for a newly generated wallet.
As the WalletUnlocker has been extended to allow passing a user source
of entropy, if this is detected, then we’ll use BIP39 to covert it into
an HD wallet seed. Otherwise, we’ll generate our own entropy, then
convert that into the wallet seed.
In order to make this change, we’ll now manually create the default
wallet ourselves. In the case that the user didn’t provide their own
seed, we’ll send the seed we generated back to the user. This will allow
frontends to display the newly generated seed to the end user.
In this commit, we modify our initial cert generation to *only* generate
and advertise cipher suites that purely use ECC. We do this is as
switching to ECC results in much faster startup time for a fresh
installation, and is also more modern crypto. # Please enter the commit
message for your changes. Lines starting
This commit adds wallet_best_block_timestamp to the gRPC interface.
This is done in order to allow clients to calculate progress while
lnd syncs to the blockchain. wallet_best_block_timestamp is exposed
via the GetInfo() rpc call. Additionally, IsSynced() returns the
WalletBestBlockTimestamp as the second value in the tuple
that is returned, providing additional detail when querying about the
status of the sync. The BtcWallet interface has also been updated
accordingly.
This commit was created to support the issue to
[Add progress bar for chain sync] (lightninglabs/lightning-app#10) in
lightning-app
In this commit, we modify our initialization of neutrino to also pass
in the custom dialer and name resolver function. With this change, if
lnd is configured to use Tor, then neutrino will as well. This means
that *both* the Bitcoin P2P as well as the Lightning P2P traffic will
be proxied over Tor.
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.
In this commit, we fix an existing bug that would result in some
payments getting “stuck”. This would happen if one side restarted
before the channel was fully locked in. In this case, since upon
re-connection, the link will get added to the switch with a *short
channel ID of zero*. If A then tries to make a multi-hop payment
through B, B will fail to forward the payment, as it’ll mistakenly
think that the payment originated from a local-subsystem as the channel
ID is zero. A short channel ID of zero is used to map local payments
back to their caller.
With fix this by allowing the funding manager to dynamically update the
short channel ID of a link after it discovers the short channel ID.
In this commit, we fix a second instance of reported “stuck” payments
by users.
In this commit, we remove a server shutdown statement that was executed
after we obtained the wallet’s password from the user over RPC. This
was unnecessary as we already close the listener below. Before this
commit, users would see a weird benign error message. With these code
deletion, the message disappears.
This commit reworks the macaroon authentication framework to use the
v2 macaroon format and bakery API. It also replaces the code in each
RPC method which calls the macaroon verifier with interceptors which
call the macaroon verifier instead. In addition, the operation
permissions are reworked to fit the new format of "allow" commands
(specifically, entity/operation permissions instead of method
permissions).
We no longer need to hand off new channels that come online as the
chainWatcher will be persistent, and always have an active signal for
the entire lifetime of the channel.
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 makes the value returned fomr NumRequiredConfs
and RequiredRemoteDelay used during the funding process scale
linearly with the channel size. This is done to ensure that
in cases there are more at stake in a channel, we have more
time to react to reorgs, or unilateral closes.
If the user explicitly specified values for these two at
startup, we return those instead, without doing the scaling.
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.
In this commit we ensure the behavior of lnd with the —noencryptwallet
command line option heaves as it did before user initiated wallet
encryption was implemented. We do this by modifying the
waitForWalletPassword method to instead return two pass phrases: one
public and one private. The default wallet public passphrase is then
restarted back to the value which was used stoically in the codebase
before the latest merged PR.
This commit makes use of the UnlockerService within lnd, waiting
for the user to provide a wallet encryption passord over RPC at
startup. When the passoword is received, startup continues as
normal, either using the passowrd to create the wallet for first
time use, or unlocking an existing wallet database.
This can be skipped by setting the --noencryptwallet flag, causing
the wallet database to be encypted using the default passoword.
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.
The fundingManager will register with the server to get notified
when the targetted peer comes online, in case of a failed send
of the fundingLocked message. This is necessary because if the
peer is not connected yet (or was disconnected while we were
waiting for the funding tx to confirm), we cannot continue the
the opening process before the peer successfully has received
the fundingLocked.
This commit modifies the way that we create the macaroon database, and
also create the initial macaroons themselves. Rather than creating a
new macaroon DB for each chain, we instead create a single instance for
all chains. Additionally, if the datadir has been modified, and the
macaroon paths haven’t been modified, the macaroons are now scoped to
those paths.
Persists the state of a channel opening process after funding
transaction is confirmed. This tracks the messages sent to
the peer such that the process can be continued in case of a
restart. Also introduces that the receiver side forgets about
channel if funding transaction is not confirmed in 48hrs.
Make the fundingmanager send an updated node announcement
each time it opens a new channel. This is to make sure
our node announcement is propagated in the network, since
peers will ignore our node announcements if we haven't
opened any channels yet.
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.
