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.
In this commit we remove all instances of the macaroon authentication
service from the UnlockerService struct. We do this, as in the future,
the macaroons themselves will be encrypted using the user’s passphrase,
therefore we wouldn’t be able to _verify_ the macaroon unless the
wallet itself was encrypted.
In this commit we fix an existing bug within the msgConsumer grouting
of the chanMsgStream that could result in a partial deadlock, as the
readHandler would no longer be able to add messages to the message
queue. The primary cause of this issue would be if we got an update for
a channel that “we don’t know of”. The main loop would continue,
leaving the mutex unlocked. We would then try to re-lock at the top of
the loop, leading to a deadlock.
We avoid this situation by properly unlocking the condition variable as
soon as we’re done modifying the condition itself.
lncli create:
This command is used to set up a wallet encryption password for
use with lnd at first time use. It will ask fot the user to
confirm the chosen password, then do a call to the lnd RPC method
CreateWallet with the chosen password.
lncli unlock:
This command is used to unlock the wallet of a running lnd instance.
It calls the RPC method UnlockWallet with the provided password.
Both methods makes use of the terminal.ReadPassword method, to
securely read a password from user input without making it
replayable in the terminal.
This commit adds the --noencryptwallet flag to integration test
nodes, causing them to be operational during the tests without
having to provide a password over rpc.
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.
This let the caller of newChainControlFromConfig set the password
to be used when creating or unlocking the wallet database. The
provided password is used both as private and public password.
The walletunlocker package contains the UnlockerService, which
implements the lnrpc.WalletUnlocker interface. This service is
used for receiving a password from the user over RPC, and doing
simple validity checks like making sure the user is not trying
to create a new wallet if one already exists, and that in case
the wallet exists, the provided password is correct.
The service will the pass the passwords over the CreatePasswords
or UnlockPasswords channels, for use within lnd.go.
This commit adds the service WalletUnlocker, which is to be used
for creating a wallet password at first time startup, and unlocking
the wallet. The service exposes the RPC methods CreateWallet and
UnlockWallet.
The fee estimation for funding transactions now properly accounts for
different types of UTXOs spent, whereas previously it assumed all
inputs were spending native P2WKH outputs.
In this commit, we add a new method shouldRequestGraphSync which the
server will use in order to determine if we should request a full
channel graph sync from a newly connected remote peer. Atm, we’ll only
request a full sync iff, we have less than two peers. This is only the
initial basic logic, as we’ll later extend this to be more
comprehensive.
With this change, we’ll no longer be blasted by full channel graph
dumps for _each_ new connection after we deem that we’ve been
sufficiently bootstrapped to the network.
In this commit we add the set of local features advertised as a
parameter to the newPeer function. With this change, the server will be
able to programmatically determine _which_ bits should be set on a
connection basis, rather than re-using the same global set of bits for
each peer.
This is a rewrite of feature vectors in lnwire. This has a few
benefits:
1) a simpler interface
2) separate structs for a plain set of feature bits and a feature
vector with associated feature names
their respective feature sets
3) loosened requirements that bits MUST be assigned in pairs
4) fix endianness of encoding/decoding
In this commit, from the PoV of the SendPayment method we now delegate
all path finding+verification to missionControl. This change doesn’t
materially affect anything, it simply expands the abstraction to make
way for future features that more heavily utilize mission control.
This commit fixes a slight bug in the announcement processing logic
within the AuthenticatedGossiper. Before this commit, it was possible
for us to ignore one of our now announcements due to it being
pre-mature, rendering (atm) the channel unusable by the ChannelRouter
itself. To fix this, we know only check for a pre mature announcement
iff the message is coming from a remote node.
In light of the recent commit which added a new set of logging in the
debug verbosity and the commit which added exporting logs from test
execution to Travis, we’ve now bumped up the logging level to debug.
With this new set of logging infrastructure, we should be able to
quickly debug any issues or flakes in the integration tests running on
CI.
This commit fills in an existing logging gap by adding a new set of
message summaries that is shown for the debug logging level.
Before this commit, if a user wanted to get a close up feel for what
lnd was doing under the covers, they had to use the trace logging
level. Trace can be very verbose, so we now provide a debug logging
level with message “summaries”. The summaries may not contain all the
data in the message, hut have been crafted in order to provide
sufficient detail at a glance.
This commit updates the glide files to point to the latest btcd build
which has had stall detection temporary disabled in order to ensure
smooth neutrino syncs without the false positives currently present in
stall detection.
In order to maintain the original essence of the test, we need to clear
the state of missionControl with each attempt, essentially advancing
time between each payment attempt.
In this commit we modify the SendPayment loop to optimize for
time-to-first-payment-success-or-failure. The prior logic would first
attempt to find at least 100 routes to the destination, then
iteratively prune them away as errors were encountered. In this commit,
we modify this approach to instead take a lazy approach: we first find
the current “best” path, attempt to send to that, and if an error
occurs we prune a section of the graph by reporting to missionControl,
then continue.
With this new approach, if the first known path has sufficient
capacity, and is available, then the payment speed is greatly improved
from the PoV of users. Additionally, we avoid the excessive computation
of crawling most of the graph in the k-shortest paths loop. With the
decay on missionControl, all routes will now feed information into the
central knowledge hung, allowing all payments to iteratively find out
the inactive portions of the payment graph.
This commit adds a new system within the ChannelRouter: missionControl.
The purpose of this system to is to act as a shared memory of sorts
between payment sending attempts, recording which edges/vertexes word
or didn’t work. Allowing execution attempts to pass on their iterative
knowledge of the graph to later attempts will reduce the number of
failures encountered, and generally lead to a better UX when sending
payments.
The current capabilities of missionControl are rather limited just to
introduce the new abstraction. Later follow up commits will also add
preferential treatment for reliable nodes, knowledge the impact that
target payments have on unbalancing the payment graph, etc.
This commit fixes a bug that could lead to a deadlock inside bolt db
itself. In a recent commit we allowed a db transaction to be passed
directly into findPath, however, the initial call to graph.ForEachNode
instead passed a _nil_ transaction causing the method itself to create
a _new_ transaction, leading to a deadlock.
We fix this issue by instead re-using the transaction pointer.
This commit modifies the errors that we return within the
handleLocalDispatch method. Rather than returning a regular error, or
simply the matching error code in some instances, we now _always_
return an instance of ForwardingError. This will allow the router to
make more intelligent decisions w.r.t routing HTLC’s as with this
information it will now be able to differentiate errors that occur
within the switch (before sending out the HTLC), from errors that occur
within the HTLC route itself.
This commit adds a new field to the switch’s Config, namely the public
key of the backing lightning node. This field will soon be used to
return more detailed errors messages back to the ChannelRouter itself.
This commit adds a new field to the ForwardingError struct: ExtraMsg.
The purpose of this field is to allow the htlcswitch to tack on
additional error context to ForwardingError messages returned to the L3
router.
This reverts commit 6db90ef09ab974df0ff09aeaf75a3d80414d4f50.
The root cause was fixed by commit
f4e7c36c80e8e2be9edb78b3b317c69d28d6d78f. As a result, this commit is no
longer needed.
