In this commit, we’ll now optionally allow the user to pass in the CLTV
delta value specified by the recipient a payment. If the value isn’t
specified, then we’ll use the current global default for the payment.
In this commit, we modify the FindRoutes method to pass in the CLTV
expiry for the final hop. If the value isn’t passed in, then we’ll use
the current global default value in place.
In this commit, we correct the fee calculation when converting from a
path to route. Previously we would apply the “no fee” case at the
_first_ hop, rather than the last hop. As a result, we needed to swap
the edges during path finding, otherwise, if the incoming and outgoing
edges had different fee rates, then we would create an invalid onion
payload.
In this commit we now properly switch fee calculation into three cases:
* a single hop route, so there’s no fee
* we’re at the first hop in a multi hop route, and we apply the fee
for the _next_ hop
* we’re at an intermediate hop and the fee calculation proceeds as
normal
In this commit we revert a commit which was added in the past as way to
allow the path -> route conversion code to remain the same, while
properly respecting the necessary time locks and fees. In an upcoming
change, this swap is no longer necessary as we’ll always use: the time
lock of the outgoing node and the fee of the incoming node.
In this commit, rather than reading the final CLTV delta from the
channel graph itself (which would require _both_ edges to be advertised
in order to route over), we now instead have moved to allowing the
receiving node to choose their own final CLTV delta.
In this commit, we’ve removed the selfNode attribute from memory, as
the set of new tests we’ll write, will depend on us being able to
switch the source node dynamically from the database itself.
This moves the commitment transaction generation code out of
fetchCommitmentView into createCommitmentTx. Aside from being a pretty
clean logical split, this allows the transaction generation code to be
unit tested more effectively.
This commit fixes the TestChannelBalanceDustLimit unit test in
channel_test.go. The unit test does not account for the fees
required by adding an HTLC. As a result, Alice's balance according
to her local and remote commitment chains drops below 0 at certain
points. By using the correct fee, this is avoided.
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.
