In this commit, we remove the old upgrade/migration logic of the address
manager as it's been superseded by the new approach using the
migration.Manager interface.
In this commit, we can remove the LatestVersion constant as it's no
longer needed. Instead, we'll now define the latest version as the last
entry in the slice of versions previously defined.
In this commit, we add an implementation of the recently introduced
migration.Manager interface for the address manager. With this, we'll
now be able to only expose the things required for the migration to
happen, but have the actual migration logic live at a much higher level.
The existing versions defined are set up in the same way as the existing
upgrade/migration logic, which will end up being superseded by this and
removed in a later commit.
This commit places a mutex around calls to newSecretKey,
since the inner function needs to be swapped out
during testing. Prior to this change, the race
detector would panic since the mutation was
unprotected.
In this commit, we add the new DerivationInfo method to the current
default implementation of the ManagedPubKeyAddress interface. In doing
this, we replace the account field with the derivationPath, as we can
obtain the account field from the derivationPath itself.
In this commit, we add a new method DerivationInfo to the
ManagedPubKeyAddress interface. This method is meant to provide callers
with the information necessary to independently derive each key returned
by the various methods provided to derive addresses.
This commit resolves a deadlock observed when attempting
to generate addresses. There were a few cases, particularly
in chainAddressRowToManaged and loadAccountInfo, which accessed
the public IsLocked() method of the Manager, even though the
shared mutex had already been acquired.
The solution is to create an internal isLocked() method, which
can be safely called assuming the manager's mutex has already been
acquired. As the comments above both of the methods in question
specify, we can assume the Manager's mutex *is* already acquired.
This commit also reduces some unnecessary code duplication, since
the recent changes left both a Locked() and IsLocked() method that
perform the same functionality. IsLocked() was favored as it more
clearly indicates that the returned value is a boolean.
In this commit, we fix a deadlock bug that was introduced recently.
This can happen when ForEachActiveAccountAddress or
ForEachActiveAddress is called, as these internally need to grab the
mutex of the manager (within the scoped manager) in order to check if
the manager is locked or not.
In this commit, we add a database migration from version 4 to version 5.
We also take this opportunity to clean up the old migration code. This
is no longer needed as wallets very old can simply go back in the prior
git history to migrate to version 4, then go from there to version 5.
In this commit, we remove many of the methods in the Manager struct as
they’ve now be been replicated within a scoped format for each of the
ScopedKeyManagers.
A major change is that we’ll now actually store the master HD private
and public keys. This required as in order to create new scopes, we
need access to the master HD private key as hardened derivation is
required in accordance with BIP43.
The initial creation of the manager namespaces has also been extended
to create the namespaces and keys for the set of default key scopes.
Finally, a series of utility method has been added to allow callers to
create ScopedKeyManagers for arbitrary sets of scopes.
In this commit, we create a new struct that houses the key derivation,
address management, and account management for a particular scope. A
scope consists of a (purpose, cointype) tuple. Additionally, each
ScopedKeyManager is able to generate internal/external addresses for a
specific *address type*. This make rescans easier as for each scope, we
know what type of output to look for within the chain.
The ScopedKeyManagers have two new primary methods that weren’t
previously present within the regular Manager:
* DeriveFromKeyPath
* NewRawAccount
These two methods allow callers a greater degree of control over the
way that accounted are created and addressed derived.
In this commit, we create new key spaces to allow users to store the
encrypted master priv/pub keys. This is required as in order to create
new scopes, we must do hardened derivation from the root key.
In this commit, we make a fundamental modification bucket structure
within the database. Most buckets are no under an additional layer of
nesting: the scope. The scope encapsulates which (purpose, coin type)
pair the address, accounts, and coin type keys belong to.
In this commit, we remove all direct references to BIP 44 as upcoming
changes will shift to a model that is no longer directly dependent on
BIP 44 in favor of restoring a layer of abstraction and allowing users
to manage multiple (purpose, coin type) scopes within the same
database.
In this commit, we introduce the concept of scopes for individual key
managers. Each scope will lock down a key manager to a particular
purpose and coin type within the BIP0043 hierarchy. Each scope will
also have a set address type schema. This schema will be consulted when
creating addresses for a particular scoped key manager.
Finally, we introduce 3 new default scopes:
* BIP 44
* BIP 84
* BIP 49++ (BIP49 but uses p2wkh for change addresses)
This changes the database access APIs and each of the "manager"
packages (waddrmgr/wstakemgr) so that transactions are opened (only)
by the wallet package and the namespace buckets that each manager
expects to operate on are passed in as parameters.
This helps improve the atomicity situation as it means that many
calls to these APIs can be grouped together into a single
database transaction.
This change does not attempt to completely fix the "half-processed"
block problem. Mined transactions are still added to the wallet
database under their own database transaction as this is how they are
notified by the consensus JSON-RPC server (as loose transactions,
without the rest of the block that contains them). It will make
updating to a fixed notification model significantly easier, as the
same "manager" APIs can still be used, but grouped into a single
atomic transaction.
This commit introduces two new address types to the waddrmgr. The first
address type is the native p2wkh (pay-to-witness-key-hash) output type
introduced as part of BIP0141 and the segwit soft-fork. The second
address type is a p2wkh output nested *within* a regular p2sh output.
This second address allows older wallets which are not yet aware of the
new segwit output types to transparently pay to a wallet which does
support them. Additionally, using this nested p2wkh output the wallet
gains both the space+transaction fee savings, as well as the
malleability fixes.
Both address types have been implemented as special cases of the
ManagedPubKeyAddress since they share several traits, only
differentiating in the signing mechanism needed, and the concrete
implementation of btcutil.Address returned by the address.
Two new `addressType` constants have been added to waddrmgr’s db in
order to properly serialize and deserialize the new address types.
