For shielded transactions in Zcash, viewing keys are derived directly from spending keys, and there is no central authority that controls access to viewing keys. This has several implications:
- A viewing key is similar to a credential for access control, in that if you hold it, then you are by definition authorized to use it.
- A viewing key can only be obtained from someone who already holds it (assuming the non-existence of quantum computers, which for the Sprout and Sapling designs could recover an incoming viewing key from a known payment address, but can’t recover outgoing viewing keys).
- A viewing key cannot be revoked; only stopping use of the corresponding spending key will stop adding more data that can be viewed.
At first, only the holder of the spending key (e.g. Alice) can derive the viewing key, so they are the only person who can view their transactions (and spend funds). If Alice gives their viewing key to Bob, Bob is now authorized to view Alice’s transactions (linked to the spending key Alice used to derive the viewing key), but cannot spend Alice’s funds. Bob could then give Alice’s viewing key to Carol, and Carol would then also be able to view Alice’s transactions. If Alice wants to stop Bob (and by extension Carol) from viewing their transactions, Alice moves their funds to a new spending key (which would be a visible action to Bob and Carol if the key is a full or outgoing viewing key).
The takeaway here is that if you don’t give your viewing key out, then no one can access it without your participation. Once you give out your viewing key, your participation is no longer required, only the participation of someone who holds your viewing key.
Below I refer specifically to (Sapling) full viewing keys, which provide visibility into both receives and spends (enabling balance correctness to be maintained for a view-only wallet). Incoming viewing keys are also possible (and the only type supported for Sprout), which cannot detect spends at all, and are therefore both useful for restricting view or pure data detection, and useless for maintaining correct balance in a view-only wallet.
It’s important to note that viewing keys don’t guarantee visibility into all activity for a spending key; only activity that follows the standard protocol. The encrypted fields inside the transactions are not checked for correctness by the zero-knowledge proofs (this would have been prohibitively expensive to do). This means that it is possible for Alice to send funds to Dave without Bob and Carol being able to tell that Dave was the recipient, by placing random data in the encrypted transaction fields, and sending the real data directly to Dave out-of-band. Bob and Carol could still tell that funds were spent in this case (because Alice received the spent funds normally). Similarly, Evelyn could send funds to Alice without Bob and Carol detecting those funds.
The downside to this is that those funds cannot be recovered from backup; if Alice or Dave’s wallets were corrupted or deleted, and they imported their backed-up spending keys into new wallets, they would no longer have access to any unspent funds received out-of-band. Alice could probably talk to Evelyn to recover those funds, but Dave would be completely out of luck, as the only place he could recover those funds would be from Alice’s now-corrupted wallet.