Adding the default address to the wallet automatically made sense
prior to support of diversified addresses, but this is no longer
desirable behavior as we have separated key generation from address
derivation.
This operation was poorly named; the wallet already contained
the IVK, and this operation was simply adding the ability to
look up the IVK by a specific diversified address derived
from that IVK.
This reworks the way that address metadata is added to the wallet
to make adding address metadata to the wallet's in-memory cache
the responsibility of a single method rather than distributed
across multiple places in the code.
This changes ZcashdUnifiedSpendingKey::ToUnifiedFullViewingKey
to return a `UnifiedFullViewingKey` object. This makes the
derivation of ZcashdUnifiedFullViewingKey values more regular,
removing the need to be able to construct these values directly
from the spending key.
This change also modifies ZcashdUnifiedSpendingKey to remove
the `std::optional` wrapper from its member keys. This
optionality is spurious, because it is always possible to
derive a "complete" spending key, and we do not support
import of unified spending keys.
In order to support generation of unified addresses, it needs
to be possible for the code generating a unified address to search
the space of Sapling diversifiers to obtain a valid diversifier.
Historically, invalid diviersifiers were simply skipped, so we retain
this behavior when obtaining a Sapling address from the legacy HD seed.
All of these maps are created from scratch on wallet load, so we can
alter their contents without compatibility concerns. With this change,
we can use the existing maps to implement viewing key support. The
downside is that the wallet will take more space in memory, but that can
easily be improved in future by storing ExtFVK fingerprints in some of
the maps (which would improve memory usage even compared to the original
layout).
The wallet now only stores Sapling extended spending keys, and thus can
only be used with keys generated from an HDSeed via ZIP 32.
Note that not all Sapling keys in the wallet will correspond to the
wallet's HDSeed, as a standalone Sapling xsk can be imported via
z_importkey. However, it must have been generated from a seed itself,
and thus is more likely to be backed up elsewhere.
libzcash::PaymentAddress has been renamed to libzcash::SproutPaymentAddress,
and a new typedef boost::variant is now libzcash::PaymentAddress. Similarly
for ViewingKey and SpendingKey.
A new class InvalidEncoding is introduced as the default boost::variant
option for each address and key type; it is used during decoding instead
of boost::optional.
All address and key storage functions in the wallet have been modified to
refer specifically to the Sprout types, as they are used very precisely.
In most other cases, the more general type is leveraged as much as possible,
and we convert to the Sprout type when necessary. This will be subsequently
wrapped in, or replaced with, context-specific functions once Sapling
types are implemented.