The presence of this variant results in a situation where more
of the code than necessary needs to be aware of and handle
decoding failures. This change moves all handling of decoding
failures to the point of decoding.
Currently, `libzcash::PaymentAddress` serves two purposes: it represents
the result of parsing a string encoding provided by a user, and it holds
the possible shielded protocol addresses that can be used in transaction
outputs. In order to add support for Unified Addresses, we split these
purposes across two separate types.
We also add two new visitors to enable converting between these types:
- `RecipientForPaymentAddress` returns the "preferred protocol address"
that should be used in transaction outputs, or `std::nullopt` if the
payment address encoding was invalid.
- `GetRawAddresses` returns all protocol addresses contained within the
given payment address, or an empty set if the payment address encoding
was invalid.
For the existing address encodings, the implementations of these are
trivial.
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.
This is because they may conflict with reserved names. Also took
this opportunity to make the guards in the zcash subdir a bit
more uniform by having them all conform to ZC_<...>_H_
This closes#1272
Kris Nuttycombe
Jack Grigg
Alfredo Garcia
Jay Graber
Homu
Sean Bowe
syd