We don’t currently have a JSON-RPC method that includes an inferred privacy policy used by the sender for a received transaction, but it wouldn’t be particularly hard to implement, because the privacy implications of a given transaction are plainly visible in its format.
The purpose of the privacy policy argument to zcashd’s JSON-RPCs was to enable senders to control how their wallet built their own transactions, within the constraints of JSON-RPC’s limited interactivity for existing methods. It’s not really the ideal way to handle the privacy implications of a proposed transaction, but it worked well enough for this purpose.
A better mechanism, and the one we’ve been working towards in the Zcash Rust crates, is to build transactions in steps:
- User requests that a transfer of funds be created (e.g. with a ZIP 321 Payment Request URI).
- Wallet returns a Transaction Proposal, that says how the wallet will enact the requested transfer of funds.
- In particular, this contains enough information to determine the privacy implications of the proposed transaction(s).
- Wallets should always strive to create the most private transaction possible, given the constraints of the user’s current wallet state.
- User reviews the Transaction Proposal in their wallet’s UI, which ideally includes details about what information will be disclosed or leaked.
- If the user is happy with the Transaction Proposal and its privacy, the user confirms the proposal.
- The wallet then builds the corresponding transaction(s) from the proposal.
Privacy Policies in zcashd have the downside that the user has to state the desired policy up-front before any proposal is made, and if the proposal can’t be created satisfying the stated policy then nothing happens and the user doesn’t learn what kind of transaction could have been created. With the Transaction Proposal workflow (currently used under the hood in the mobile SDKs and that I want to expose JSON-RPCs for in Zallet), users instead learn the (ideally if the wallet is well-implemented) most private transaction that the wallet can produce, and they can decide whether that transaction is sufficient or whether they need to take additional steps to improve the overall state of their wallet and enable more private transactions.