Kris Nuttycombe

DAG Sync: Use a downloaded nullifier set to allow instant spentness checks.

4

One of the requirements for DAG sync is that we be able to more or less immediately identify when one of our existing notes has been spent. In order to...

Performing the nullifier checks here in constant time is likely to have a nontrivial performance overhead. https://github.com/zcash/librustzcash/blob/47d432820a6d277e7ce2434fe7edbe5ba320e546/zcash_client_backend/src/scanning.rs#L456

If we add note commitment tree size metadata to `ScanRange`, it makes it easier to optimize scanning batch sizing when downloading the scan ranges.

If we perform wallet recovery by scanning in reverse order, we don't need to worry about the scenario where we detect a note that will be spent by a later...

zcash_client_backend: Make it possible to skip trial-decryption with internal keys.

2

Since internal keys should only ever receive funds that are being sent by the wallet, it should be possible to skip trial-decryption using the internal IVK for any block except...

zcash_client_backend: Ensure that wallets don't select potentially-spent notes during recovery.

1

In "recovery mode", we can't spend funds that we received before the recovery height, because we might later discover them as having been spent. However, this shouldn't inhibit a wallet...

The following workflow is possible: under ordinary conditions, do not update the note commitment tree. When a note is found, the `FoundNote` scan range should include a request that the...

Wallet UI may want to provide an interface that displays ZIP 317 fees interactively in response to user input. We need to know how computationally expensive proposal creation is given...

zcash_client_sqlite: Require sufficient chain tip scanning prior to spendability

1

At present, there's a rare edge case in anchor selection where an old anchor could be chosen if the chain tip shard contains fewer than `min_confirmations` blocks and the wallet...