This adds a field for specifying the macaroon root key to use during the
wallet initialization process instead of having lnd generate a random
macaroon root key itself.
In this commit, we modify the `macaroons.NewService` consturctor to
accept the main interface rather than the raw DB. This allows us to use
other backends other than bolt or the kvdb interface to store the
macaroon root keys.
We also create a new ExtendedRootKeyStore interface that implements some
of the more advanced features we use such as macaroon encryption and
password rotation.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
It seems that the GitHub CI runners share a CPU and therefore only have
very few ressources available. This causes the wallet unlocker and breach
arbiter tests to fail if we don't give them enough time to complete.
In addition to creating a new wallet from an aezeed, we allow specifying
an exteded master root key as the main wallet key directly.
Because an exteded key (xprv) doesn't contain any information about the
creation time of the wallet, we must assume a birthday to start scanning
the chain from (if the user doesn't provide an explicit value). Since
lnd only uses SegWit addresses, it makes sense to
choose the date that corresponds to the first mainnet block that
contained SegWit transactions.
Restoring a wallet from an extended master root key will result in a
significantly longer initial wallet rescan time if the default value is
used.
The macaroon root keys should also be stored to the remote database if a
replicated backend such as etcd is used.
This commit refactors the macaroons service and wallet unlocker to
accept a kvdb backend directly instead of creating the bolt instance
automatically.
This commit adds a new "waiting to start" state which may be used to
query if we're still waiting to become the cluster leader. Once leader
we advance the state to "wallet not exist" or "wallet locked" given
wallet availablity.
Apparently dropping the wallet transaction history only fully takes
effect after opening the wallet from scratch again. To do this cleanly,
we need to do it in the unlocker instead of lnd.
* mod: bump btcwallet version to accept db timeout
* btcwallet: add DBTimeOut in config
* kvdb: add database timeout option for bbolt
This commit adds a DBTimeout option in bbolt config. The relevant
functions walletdb.Open/Create are updated to use this config. In
addition, the bolt compacter also applies the new timeout option.
* channeldb: add DBTimeout in db options
This commit adds the DBTimeout option for channeldb. A new unit
test file is created to test the default options. In addition,
the params used in kvdb.Create inside channeldb_test is updated
with a DefaultDBTimeout value.
* contractcourt+routing: use DBTimeout in kvdb
This commit touches multiple test files in contractcourt and routing.
The call of function kvdb.Create and kvdb.Open are now updated with
the new param DBTimeout, using the default value kvdb.DefaultDBTimeout.
* lncfg: add DBTimeout option in db config
The DBTimeout option is added to db config. A new unit test is
added to check the default DB config is created as expected.
* migration: add DBTimeout param in kvdb.Create/kvdb.Open
* keychain: update tests to use DBTimeout param
* htlcswitch+chainreg: add DBTimeout option
* macaroons: support DBTimeout config in creation
This commit adds the DBTimeout during the creation of macaroons.db.
The usage of kvdb.Create and kvdb.Open in its tests are updated with
a timeout value using kvdb.DefaultDBTimeout.
* walletunlocker: add dbTimeout option in UnlockerService
This commit adds a new param, dbTimeout, during the creation of
UnlockerService. This param is then passed to wallet.NewLoader
inside various service calls, specifying a timeout value to be
used when opening the bbolt. In addition, the macaroonService
is also called with this dbTimeout param.
* watchtower/wtdb: add dbTimeout param during creation
This commit adds the dbTimeout param for the creation of both
watchtower.db and wtclient.db.
* multi: add db timeout param for walletdb.Create
This commit adds the db timeout param for the function call
walletdb.Create. It touches only the test files found in chainntnfs,
lnwallet, and routing.
* lnd: pass DBTimeout config to relevant services
This commit enables lnd to pass the DBTimeout config to the following
services/config/functions,
- chainControlConfig
- walletunlocker
- wallet.NewLoader
- macaroons
- watchtower
In addition, the usage of wallet.Create is updated too.
* sample-config: add dbtimeout option
This is required to make restart work for LndMobile builds.
Not calling UnloadWallet would make `UnlockWallet` stall forever as
the file is already opened.
In this commit, we we extend the Init and Unlock methods to also parse
out and return optional SCB instances. With this change, when the user
creates their node, if they have an existing seed and also a set of SCBs
(either single or multi), they'll be able to recover both their on-chain
balance, and also any funds that were settled within their existing
channels.
In this commit, we fix a bug where it's possible that changing the
wallet's password fails due to not being able to remove non-existent
macaroon files. Since it's possible to run lnd without creating them,
changing the wallet's password would always result in a failure.
In this commit, we extend the UnlockerService to account for the new
changes in the lnrpc definition. Setting up the daemon for the first
time is now two step process: first the user will generate a new seed
via the GenSeed method, then the user will present this new seed (and
optional pass) to the InitWallet method which then will finalize the
wallet creation.
This two step process ensures that we don't commit the wallet changes
in the case that the user doesn't actually "ACK" the new seed.
In the case that the user already has an existing seed, they can
re-enter it and skip straight to the InitWallet step.
We also update the tests to account for the new API changes.
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).
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.
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.
Eng Zer Jun