Jack Grigg

I've implemented the alternate API in #598, which should make the guide sections slightly easier to write.

This was motivated by comments on the auto-shielding PR: - https://github.com/zcash/librustzcash/pull/341#discussion_r794982036 - https://github.com/zcash/librustzcash/pull/341#discussion_r794984561

For Bitcoin, that's usually not a choice: wallets following BIP 44 semantics require users to receive funds in (at least some of) generated addresses before subsequent new ones are generated,...

Wrt storing the UFVK as one column per receiver vs just storing the UFVK directly in the table, both of these will require migrations: - One column per receiver: we...

Decided we'll go with a single `ufvk` column.

#600 implemented a migration that replaced the `extfvk` column of the `accounts` table with `ufvk`, and also ensured that the `address` column consistently contained the default Unified Address for the...

> The same argument would not apply to verification: you can verify a proof with just the verifying key, without needing the code for the circuit. That's not quite true:...

> If we save the generated proving key, when we restart a prover, we can reuse the proving key to prove for different witnesses. In proving systems like Groth16, it...

@daira pointed out that: > very large circuits used by short-lived prover processes (is this a use case people have?) is the exact use case for a CI workflow of...

Yes, but this time will be reduced by improved compute (and e.g. GPU support), which applications using these large circuits will favour anyway for proving. So if the application is...