This unification allows us to better isolate transparent-input dependent
functionality. Previously, `TransparentInputSource` could not be placed
under a feature flag because the interface was needed for proposal
deserialization; by instead making the transparent input source methods
flag-dependent, we can correctly produce an error when proposal
deserializaiton attempts to select transparent inputs and the feature
flag is off.
We plan to also introduce a similar flag to gate access to Sapling
functionality. Since introduction of Orchard functionality is still
nascent, it's the correct time to introduce this isolation, before
there's more functionality that needs to be isolated in this fashion.
`ReceivedNote` now allows Orchard notes to be represented as received
notes. As part of this change, received notes now track whether they
were received using internally- or externally-scoped viewing keys.
This eliminates the need to trial-regenerate notes using the wallet's
IVKs to determine scope at spend time.
Public methods for mutation of these fields have been provided that
perform checking for overflow of the valid monetary range as part
of their operation.
Prior to this change, it's necessary to implement the entirety of the
`WalletRead` trait in order to be able to use the input selection
functionality provided by `zcash_client_backend::data_api::input_selection`.
This change factors out the minimal operations required for transaction
proposal construction to better reflect the principle of least authority
and make the input selection code reusable in more contexts.
In order to minimize the operations of the newly-created `InputSource`
and `ShieldingSource` traits, this change also removes the
`min_confirmations` field from transaction proposals, in favor of
storing explicit target and anchor heights. This has the effect of
limiting the lifetime of transaction proposals to `PRUNING_DEPTH -
min_confirmations` blocks.
`fetch_params.sh` is now deprecated and the bundled proving parameters
from `wagyu-zcash-parameters` are used everywhere, so the tests should
follow suit.
Fixes#1016
This fixes an API issue whereby it was possible to execute a `Proposal`
with a different value of `min_confirmations` than that with which the
`Proposal` was constructed.
`StandardFeeRule` is an enumeration of the standard fees that have
existed in the history of Zcash zips. It is provided to simplify
transition to new fee strategies; legacy elements of this enumeration
are introduced already-deprecated.
The `v_transactions` view is built upon the set of received notes,
received note values being added to the balance for the transaction and
spent notes being deducted from this balance. This fixes an error
wherein if multiple identically-valued notes were spent in a
transaction, only one of those notes' values was being counted as having
been spent.
The `v_transactions` view is built upon the set of received notes,
received note values being added to the balance for the transaction and
spent notes being deducted from this balance. This fixes an error
wherein if multiple identically-valued notes were spent in a
transaction, only one of those notes' values was being counted as having
been spent.
The existing API limited change outputs to having only a single memo
repeated across each change output. This change makes it so that each
proposed change output can have its own associated memo, and leaves it
up to the input selector to determine how requested change memos are
associated with change outputs.
In order to use `uint64` for amounts that must be nonnegative in the
`proposal.proto` file, it is useful to update fee and change computation
to use `NonNegativeAmount` where possible.
When scanning, a wallet only needs to update balance and transaction
information shown to users when the scan has resulted in a change to
wallet state. This modifies `scan_cached_blocks` to return the range of
block heights actually scanned, along with the counts of notes spent and
received by the wallet in that range.
Fixes#918
We don't need to iterate over them, but the `*_extrema` internal methods
are semantically returning inclusive ranges, and using `RangeInclusive`
avoids bugs where the wrong half of the tuple is used (instead moving
the location of the tuple handling inside the `*_extrema` methods, which
cuts the number of occurrences from linear in the number of function
calls to constant).
The MSRV for the main crates is 1.65, which is higher than the Rust
version that stabilised workplace dependencies (1.64). The implicit MSRV
for the component crates is still lower than this, so we don't migrate
these crates.
Previously we used `Uuid::from_fields` to ensure that the various UUID
fields were correctly constructed, but now that we have a CI lint that
checks this automatically, we can consistently use `Uuid::from_u128`
which is easier to prepare from `uuidgen` output.
We don't know at truncation time what the latest chain tip is; the chain
might have reorged to a shorter heavier chain, or the reorg depth might
only be a few blocks. `WalletDb::chain_height` uses the scan queue as
its source of truth, so the `Verify` range we add during truncation
(to prioritise determining whether the rewind was sufficient) can't
extend beyond the block height we know to exist.
The next call to `WalletDb::update_chain_tip` will add additional ranges
beyond this height, which might include a `Verify` range that ends up
merging with the one added during truncation.
The `LEFT OUTER JOIN` was causing the `tx.block IS NULL` check to alias
two cases: an unspent transparent output, and a transparent output spent
in an unmined transaction. The latter only makes sense to include in the
UTXO count if the transaction is expired, and (due to limitations of the
transparent data model in the current wallet) if that expiry won't be
undone by a reorg. We now handle these two cases directly.
Partly reverts 8828276361.
Closeszcash/librustzcash#983.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>