Now that we're able to fund transactions from multiple accounts within
different key scopes, we extend our transaction creation methods to
accept a key scope parameter as well, to determine the correct account
to select inputs from.
Following the previous commit, some external hardware signers require a
master key fingerprint to be present within the PSBT input derivation
paths so that the signer can recognize which inputs are relevant and
must be signed.
Watch-only accounts are usually backed by an external hardware signer,
some of which require derivation paths to be populated for each relevant
input to sign.
This configuration to run the checks on appveyor looks very old and
unused since it still refers to glide for dependency management. We
remove the file as it no longer serves a purpose.
We use the golangci-lint in lnd and it has quite a few more detections
enabled than what's in the current gotest.sh script.
We don't start with a given base commit on purpose but instead fix
everything the linter finds in the following commits.
For key scopes which have an address schema where the external and
internal branches differ, we always assume that imported keys use the
external address type defined in the scope's address schema. This may
not always be the case however, and should be handled correctly.
Ideally, we generate two addresses per imported key (only if the
external and internal address types differ) and scan for both in the
chain.
This change was motivated by the need to support importing BIP-0049 keys
that use the standard address derivation scheme, where nested witness
pubkeys are used for both the external and internal branches. Our
BIP-0049 key scope is slightly different, in that addresses derived from
the internal branch use the witness pubkey address type. By having the
option of overriding the address schema for a particular account, we can
support importing standard BIP-0049 keys.
The master fingerprint corresponds to the fingerprint of the root master
public key (otherwise known as m/). This is required by some hardware
wallets for proper identification and signing.
The address schema is an optional field that allows an account to
override its corresponding address schema with a custom one.
Watch-only accounts are usually backed by an external signer as they do
not contain any private key information. Some external signers require a
root key fingerprint for identification and signing purposes. In order
to guarantee compatibility with external signers, we need to persist the
root key fingerprint within the database.
Before this change, watch-only accounts used the default account
database structure. In this commit, we introduce a new account type to
store different information for watch-only accounts only. This isn't a
breaking change as watch-only accounts have yet to be supported by the
primary user of the wallet (lnd). With this new account type, we can
avoid the empty private key fields, which are irrelevant to watch-only
accounts, and we can store the root key fingerprint.
Previously, addresses that belong to a watch-only account would have a
derivation path using the internal account number used to identify
accounts within the databse, rather than the actual account number based
on the account's master public key child index. This wasn't an issue
before as only one account would exist within the wallet, the 0 account,
which is also the default. To ensure users of the DerivationPath struct
can arrive at addresses correctly, we introduce a new field
InternalAccount to denote the internal account number and repurpose the
existing Account field to its actual meaning.
This error would be seen when an old wallet that has yet to update is
performing the latest wtxmgr migration. It's possible for the locked
outputs bucket to not exist if outputs haven't been locked before, so we
should its deletion correctly.
We create a more generic copy of the dropwtxmgr command's functionality
and export it as the DropTransactionHistory function.
It removes all transaction history from the given wallet to force a
full chain rescan. Optionally the user-defined transaction labels can be
preserved.
