Make consistent use of "pool", "address type" and "receiver type",
in RPC documentaion, and deprecate bare uses of "type" in RPC APIs.
Fixes#5534
Co-authored-by: str4d <thestr4d@gmail.com>
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.
The addition of `OrchardRawAddress` to `RecipientAddress` drives most of
the changes in this commit, which enable `z_sendmany` to send funds to
addresses in the Orchard pool once NU5 activates.
We also add Orchard-specific information to several RPCs in order for
tests to pass:
- `z_listunifiedreceivers`
- `z_getbalanceforaccount`
- `z_getbalanceforviewingkey`
We now use the empty array of pools to indicate that the default pools
should be used when providing a diversifier index parameter, instead of
needing a default sentinel value for the diversifier index parameter
(which was previously suggested as '*' which would have caused issues
for defining a consistent type for that parameter).
Greg Pfeil
Kris Nuttycombe
therealyingtong
Kris Nuttycombe
Steven Smith
Jack Grigg
str4d