The previous approach to UTXO handling involved UTXO data being
deleted from the wallet after the relevant UTXOs had been spent.
However, this means that we can no longer accurately compute
transaction fees for the transactions spending those UTXOs.
The `net_value` of the resulting rows in v_transactions will be
null.
The implementation of `io:Read` for `ResponseLazyReader` used to return
only one byte regardless of the size of the provided `buf`, which
significantly degraded the performance of loading the response.
This change makes use of the provided `buf`. On my machine with Rust
1.64, the downloading speed went up from ~100 KiB/s to ~2 MiB/s.
However, as before this change, the process still uses 100% of a single
CPU thread when downloading the response. The most likely reason is that
we still manually read each byte of the response. I can download the
same data with ~ 50 MiB/s on my machine using a different HTTP client.
This fix seems to be sufficient for now.
As of zcash/librustzcash#633, `SaplingDomain::IncomingViewingKey` now
allocates memory internally, and this memory persists as long as the
`BatchRunner` is alive. Now that we have decoupled the measurement of
heap usage for batch tasks from their internals, we can add bounds to
all of the generic parameters of `Batch` to enable correctly measuring
their actual heap usage.
We also add `DynamicUsage` impls for a bunch of `zcash_primitives` types
that will be used with `BatchRunner` (or its equivalent implementation
in `zcashd`) by callers.
This enables the heap usage measurements to be conditionally enabled by
the `BatchRunner` user. Importantly, when heap usage measurements are
not enabled, the `DynamicUsage` bound on `Batch` is not required.
This refactor also fixes a bug in the prior implementation. We were
counting the heap usage of a task when it started to run, but the item
may have been in the `rayon` work-stealing queues for a non-negligible
period before then. We now count the heap usage immediately before
spawning the task into the `rayon` thread pool.
Previously we were sending an `Option<DecryptedNote>` from each `Batch`
back to its parent `BatchRunner`. However, this requires allocating
sufficient space in the channel to handle the case where every output
can be decrypted. In general this will not be the case, and we can
instead signal "nothing decrypted" by just dropping the channel sender.
This reduces the post-batch-scanning memory usage of `BatchRunner` from
being linear in the number of on-chain outputs, to being linear in the
number of outputs for the wallet.
Ported from zcash/zcash@f7f6c2070d.
The `MAX` SQLite function returns `null` when the table is empty. The
code was expecting zero rows to be returned in this case, and was trying
to parse the `null` as an integer.
This was only used to provide example code for Sapling usage of
the `NoteEncryption` struct; this example code has been moved
to `sapling::note_encryption`.
str4d
Daira Hopwood
Marek
Kris Nuttycombe
Kris Nuttycombe
dependabot[bot]