Creates a dedicated type for the proxy, and uses that instead of `bool` or `TransactionStrategy` to
conditionalize the proxy behavior.
This also converts UA selectors to account selectors more often:
• when the strategy allows linking addresses (as before);
• when the strategy doesn’t allow transparent senders at all; and
• in the remaining cases if the provided UA doesn’t have transparent receivers.
Co-authored-by: Greg Pfeil <greg@technomadic.org>
Previously, `AllowRevealedSenders` would permit linking multiple legacy taddrs. This strengthens the
policy to only allow sending from a single taddr, preventing linking of any addresses. To send from
multiple taddrs (legacy or UA) now requires `AllowLinkingAccountAddresses`.
Without `AllowRevealedRecipients`, we can’t send transparent change, but previously we asserted if
we couldn’t get a transparent change address. Now it returns a new `TransparentChangeNotAllowed`
failure, which is just a more specific `TransparentRecipientNotAllowed` to avoid confusion when
there are no explicit unshielded recipients.
When deciding whether we can pay Orchard receivers, rather than checking
whether we have “sufficient non-Sprout funds”, we can just check whether the
selector selects Sprout – if it doesn’t then we can select Orchard receivers
regardless, and we’ll catch insufficient funds later.
This is also helpful for ZIP 317, because in that case we don’t even know the
total non-Sprout funds necessary until after we decide which receivers to pay.
Do the check deeper, preventing test_bitcoin from being able to bypass it. This
also moves it out of z_sendmany-specific code, which will be helpful when we add
other operations, like sendfromaccount.
Some of the more significant changes are
- remove release note entry for already-released feature;
- rephrase some error messages and comments;
- add a missing case to `EstimateTxSize`;
- don’t return a selector when we don’t have a UFVK for a UA, which allows some
simplifications (and elimination of a failure case) to happen; and
- remove a redundant `InsufficientFundsError`.
Eliminates SelectsTransparentCoinbase in favor of a Disallow/Allow/Require ternary. Also asserts if
a selector requires transparent coinbase but doesn’t select transparent.
These features were deprecated at least 3 minor releases ago. I found
one mistake which was that `z_validateaddress` had not been placed
behind the `addrtype` deprecated feature; this has been fixed.
z_mergetoaddress doesn't currently have any mechanism for specifying
the minconf value. We don't want to default back to a minconf of 1,
as before, because we'll be selecting anchors with at least 3
confirmations by default, so the simplest change here is to make
the minconf value default to the number of anchor confirmations, and
add a configurable minconf at some point in the future. It's likely
that `z_mergetoaddress` will end up being deprecated in any case,
so this works for now.
Also, ensure that anywhere that we're attempting to obtain the Orchard
anchor that we don't attempt to get an anchor from a height below NU5
activation.
This changes anchor selection and Orchard authentication path generation
to default to select anchors at a the depth specified by the
`-orchardanchorconfirmations` CLI argument, with a default anchor
selection depth of 10 blocks.
If the value of `minconf` used for a particular call to `z_sendmany` is
less than the the set number of Orchard anchor confirmations, `minconf`
will be used instead for the Orchard anchor confirmations depth,
so that the selected anchor will be certain to contain any notes
selected to be spent.
Fixes#5644
This adds tests to wallet_z_sendmany that demonstrates conditions
where pool-crossing transfers were not being caught by the privacy
policy checks, which were validating only against the transfer
request rather than the actual transfer selected. This missed
cases where sending funds between unified addresses would reveal
amounts via the turnstile.
Making all privacy policy checks after note selection guards against
this error.
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.
Daira-Emma Hopwood
Greg Pfeil
Greg Pfeil
Jack Grigg
Greg Pfeil
Kris Nuttycombe
Kris Nuttycombe
Steven Smith
ying tong
Alfredo Garcia