`CWallet::FindUnifiedAddressByReceiver` is a wrapper around the visitor
`UnifiedAddressForReceiver`, which looks up the Unified Address (if any)
corresponding to the given receiver. However, this only returns external
UAs, and returns `std::nullopt` both if the receiver does not correspond
to a UFVK, and if it does but is derived from an internal FVK. By using
this method as a filter, `listaddresses` was not filtering out internal
Sapling receivers, and thus was leaking Sapling change addresses for
accounts (which we do not want revealed in the UI anywhere).
Instead, we now check for UFVK metadata directly, which verifies that
the Sapling receiver is derived from a UFVK without any extra filtering.
- Legacy transparent addresses derived from the mnemonic seed are no
longer duplicated in the `legacy_random` source.
- Legacy transparent change addresses derived from the mnemonic seed are
now shown under that source.
- Sapling addresses that aren't part of a UA are now identified
correctly when derived from the mnemonic seed, rather than being
assumed to be derived from the legacy HD seed.
- The legacy_random source should only contain Sprout addresses (as
zcashd now only derives transparent addresses from the mnemonic seed).
- Sapling addresses should appear in the mnemonic_seed source, not the
legacy_seed source (as zcashd no longer ever generates keys there).
The RPC test also now has several additional checks:
- `listaddresses` does not return duplicate addresses (an address can
only come from a single source).
- Address sets are now explicitly checked (to ensure that there are no
unexpected addresses under the checked sources).
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
Also refactors Sapling key export logic to match. Sapling key exports
already have hdkeypath and seedfp (in a different spot in the line).
Sprout key exports are unmodified, because we have removed the ability
to generate new Sprout keys, so there will never be HD Sprout keys.
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.
This method detects and returns metadata for any notes belonging to the
wallet that are spent in the transaction. It also trial-decrypts the
Orchard outputs of a transaction using the wallet's incoming viewing
keys along a set of OVKs provided by the caller, and returns metadata
about the notes that were successfully decrypted.
The missing header reference meant that Gitian builds didn't include the
file in its distribution step, causing subsequent builds to fail with a
'file not found' error.
Closeszcash/zcash#5697.
We now have a full roster of privacy policies. We can graph the
relationships between the policies; arrows point from more-private to
less-private, and each policy is permitted to reveal information covered
by all policies pointing to it (in addition to the extra information it
is permitted to reveal).
FullPrivacy
v
AllowRevealedAmounts
v v
AllowRevealedRecipients ---- AllowRevealedSenders
v / v
AllowFullyTransparent <- AllowLinkingAccountAddresses
v v
NoPrivacy
The synthetic `LegacyCompat` policy now uses the `AllowFullyTransparent`
policy for backwards compatibility, and the `FullPrivacy` policy if the
sender or recipients involve Unified Addresses.
Closeszcash/zcash#5677.
Closeszcash/zcash#5678.
sasha
str4d
Jack Grigg
Dimitris Apostolou
Jack Grigg
Charlie O'Keefe
Larry Ruane
Kris Nuttycombe
Jonas Schnelli
Kris Nuttycombe
Steven Smith
Daira Hopwood