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.
This replaces the bool argument with a string argument, enabling us to
add additional privacy strategies. We also alter the default to be
backwards-compatible with existing RPC method usage, by only enabling
the strongest checks if a Unified Address is involved.
Closeszcash/zcash#5676.
The methods `FindUnifiedFullViewingKey` and `FindUFVKByReceiver`
are implementable with only the information that'a available from
the keystore, so it's better to use the methods that are defined
there in the previous commit.
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.
Currently we cannot use anything greater than 1, because the Orchard
witness tree cannot provide authentication paths to anything but the
current tree root. Once zcash/incrementalmerkletree#22 is implemented,
we can revert this change as part of zcash/zcash#5644.
Kris Nuttycombe
Charlie O'Keefe
Jack Grigg
Jonas Schnelli
Kris Nuttycombe
Steven Smith
Daira Hopwood
str4d
ying tong
sasha