> You also only get privacy with transactions between two z-addresses, and those require a fair amount of resources to generate FWIW this is rapidly improving.

> You also only get privacy with transactions between two z-addresses, and those require a fair amount of resources to generate FWIW this is rapidly improving. The main thing we need to implement Zcash-style private payments is a Merkle proof in a zk-SNARK, so that we can prove ownership of an account in the Merkle tree without revealing the account. So the proving cost depends heavily on our choice of hash function. Since most SNARKs operate over large finite fields, traditional bit-oriented hashes are a poor fit, but the designers originally went with SHA-256 anyway to be on the safe side. More recent versions of the Zcash circuit use Pedersen hashes, which are much cheaper and still provably collision-resistant (assuming discrete log hardness). Future versions will probably use more specialized hashes designed to minimize field operations, like Rescue [1]. There's also the idea of using an embedded GKR protocol to verify gMIMC hashes with a very low incremental cost [2], although it might be overkill for Zcash-style circuits. [1] https://eprint.iacr.org/2019/426 https://eprint.iacr.org/2019/426 [2] https://hackmd.io/@uCHu_NMSQ4mIUvA8i4qAyg/rkxBcmvcI https://hackmd.io/@uCHu_NMSQ4mIUvA8i4qAyg/rkxBcmvcI