This now returns whether or not the address corresponds to an
internal recipient, an external address for the wallet, or a
counterparty's address (an address not derived from any of
the wallet's keys) from GetPaymentAddressForRecipient.
Fixes#5708
One of the invariants that we want to hold for unified addresses
is that we never want change addresses to be visible to users.
This updates address metadata retrieval to also indicate whether
or not an address is associated with a UFVK's internal key,
and omits and flags change addresses in z_viewtransaction output.
When a user supplies a unified address as the source of funds
for z_sendmany, the previous behavior could have risked user
privacy by spending transparent UTXOs belonging to different
diversified addresses in the same transaction, thereby linking
those addresses, and consequently any diversified shielded
receivers of unified addresses containing those transparent
receivers.
This change limits selection of transparent UTXOs to only those
explicitly associated with the unified receivers of the provided
source UA. Also, if a UA is provided as the source, the behavior
is maintained that only shielded notes in pools corresponding to
the receivers of that UA will be selected.
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.
This commit does not include functional changes; it merely
breaks up content previously included in `zcash/address/zip32.h`
into smaller and more focused components.
Issue: #10905
By returning the result, a few useless lines can be removed.
Return-value-optimization means there should be no copy.
zcash: cherry picked from commit 5cb3da04b8882ca975b4e3d6c089c64bbaf67d0d
zcash: https://github.com/bitcoin/bitcoin/pull/10916
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.
Kris Nuttycombe
Kris Nuttycombe
Marko Bencun
Jack Grigg
Matt Corallo
Larry Ruane
Daira Hopwood
Homu
Eirik Ogilvie-Wigley
Jay Graber