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.
We now use the total funds in each available pool to figure out whether
a particular desired selection order can provide the requested amount,
and can alter the selection order each time we add another pool.
This information enables us to select notes and coins in a way that
minimizes information leakage while moving funds into the shielded pool
where possible.
This method selects inputs by iterating through available notes and
coins until sufficient value is found, and then dropping the remaining
notes and coins. However, the processing of each pool type was gated on
having not selected sufficient funds. This meant that if an earlier pool
had sufficient funds to fill a transaction, later pools would not be
processed at all and their notes would be left as selectable.
There are no functional changes in this commit, but the refactor
separates the legacy account handling, and makes it easier to integrate
new pool types.
We also rename `libzcash::ChangeType` to `OutputPool`, in anticipation
of using it to track transaction recipient pools.
Prior to this change, calling `join_network` after a network split
only worked in the case that no new non-coinbase transactions were
created during the network partition; in the case that such a
transaction was created, `join_network` would fail when waiting
for mempool synchronization, because zcashd nodes do not.
automatically broadcast their mempool contents on restart.
This change modifies `setup_network` to wait for mempool synchronization
or not on the basis of a newly added do_mempool_sync flag. In the
case of `join_network`, this flag is set to `False`; the default value
is set to `True` to preserve previous functionality elsewhere.
Tests should explicitly use the `resendwallettransactions` RPC method
to ensure that mempool transactions are rebroadcast before attempting
to synchronize the network after a `join_network` call.