# Is it possible to destroy a view key? **URL:** \ **Category:** Technology\ **Created:** [July 22, 2024, 5:23pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369 "2024-07-22T17:23:51Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Zec\_Max](https://avatars.discourse-cdn.com/v4/letter/z/3ab097/32.png) [@Zec\_Max](https://forum.zcashcommunity.com/u/Zec_Max)\ **Post date:** [July 22, 2024, 5:23pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/1 "2024-07-22T17:23:51Z")
Hey, I just thought about the fact that if I ever share my view key, my address becomes transparent to the view key owner forever, and they might even share it with others. Additionally, I could be forced to reveal my view key, which would show all the transactions of the wallet. With cash, there is no transaction history. Is it possible to mimic this by like destroying it or something like that? Is it possible to only disclose certain transactions but not all? In reality, you can look into my wallet and see X amount, but you don’t know how much it was yesterday. I might have a bill, which proves that I made some payment. At the moment it seems to me like I have a hidden notebook where I note every transaction, but if someone finds it all my traces are revealed, in reality I would never to that for example. ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [July 22, 2024, 6:28pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/2 "2024-07-22T18:28:15Z")
> [@Zec\_Max](#): > > Is it possible to mimic this by like destroying it or something like that? No. A full viewing key, by definition, provides viewing access to the corresponding account’s full history (past and future) that cannot be revoked. This is one of the primary reasons that we strongly dissuade people from using the “upload your viewing key to a remote server for wallet scanning” approach, and instead focus on making local scanning more efficient. > [@Zec\_Max](#): > > Is it possible to only disclose certain transactions but not all? Yes: it is technically possible to create a Payment Disclosure for an individual transaction, that only reveals its details. There’s a still-in-progress draft ZIP about this: [ZIP 311: Zcash Payment Disclosures](https://zips.z.cash/zip-0311). ---
**Author:** ![Autotunafish](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/autotunafish/32/7827_2.png) [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)\ **Post date:** [July 22, 2024, 6:37pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/3 "2024-07-22T18:37:01Z")
If you do upload a viewing key, then you should tag it as publicly viewble and use a different account for other transactions. It could be done with multi account wallets or using multiple different wallets (the wallet would have to support importing a viewing key). ---
**Author:** ![zerodartz](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zerodartz/32/26722_2.png) [@zerodartz](https://forum.zcashcommunity.com/u/zerodartz)\ **Post date:** [July 22, 2024, 7:09pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/4 "2024-07-22T19:09:40Z")
so its possible, but only with zcashd full node wallet i guess? as no mobile or lightwalletd clients have this functionality right? ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [July 22, 2024, 7:13pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/5 "2024-07-22T19:13:04Z")
If you’re asking if Payment Disclosures are possible to create, `zcashd` only supports the old Sprout Payment Disclosures, which are incompatible with ZIP 311 (due to significant differences in the key tree) and basically unsupported. The main reason ZIP 311 hasn’t seen progress is a lack of time / resources, combined with a lack of people asking for the functionality. ---
**Author:** ![zerodartz](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zerodartz/32/26722_2.png) [@zerodartz](https://forum.zcashcommunity.com/u/zerodartz)\ **Post date:** [July 22, 2024, 7:19pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/6 "2024-07-22T19:19:31Z")
so no for sapling and orchard? ok. i guess we will need it once we decide to move to only shielded addresses? from josh post i thought that feature exists already: [x.com](https://x.com/jswihart/status/1814057577040560521) ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [July 22, 2024, 7:24pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/7 "2024-07-22T19:24:43Z")
It’s more nuanced: for the transaction builders that I am aware of (including the `zcash_primitives` one), every transaction _can_ have a Payment Disclosure produced for it as long as the sender provided an `ovk` at the time they created it (which results in the correct keys being generated that the Payment Disclosure requires). What is missing (and that ZIP 311 is a draft for) is an encoding for passing Payment Disclosures around with a consistent UX. ---
**Author:** ![zerodartz](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zerodartz/32/26722_2.png) [@zerodartz](https://forum.zcashcommunity.com/u/zerodartz)\ **Post date:** [July 22, 2024, 7:35pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/8 "2024-07-22T19:35:17Z")
ok so possible. but for normal user too hard cause no easy consistent UX. got it. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [July 22, 2024, 8:31pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/9 "2024-07-22T20:31:30Z")
The ovk is reused by the sender. Why just not give the symmetric encryption key instead? ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [July 22, 2024, 8:34pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/10 "2024-07-22T20:34:20Z")
If you read what I wrote again, or read the ZIP 311 draft, you’ll see that I did not say that the `ovk` is given out. I said that _generating the transaction with an `ovk`_ is necessary, because it causes an `ock` to be derived and used in a way that is recoverable. It’s the `ock` that is then stored in a ZIP 311 Payment Disclosure. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [July 22, 2024, 8:41pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/11 "2024-07-22T20:41:44Z")
ok but then my question is why do you have this requirement when all the OP asks is for a way to disclose a single payment. ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [July 22, 2024, 8:51pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/12 "2024-07-22T20:51:42Z")
Disclosing the symmetric key that is used to decrypt `encCiphertext` is insufficient to disclose the recipient; the note plaintext only contains the diversifier, so all you’d be revealing is an amount with no proof that a particular recipient received it. You need `pk_d` as well to disclose the recipient, which gets stored in `outCiphertext`, for which you need `ock`. You could alternatively provide _both_ the symmetric key _and_ the `pk_d` value, but if the sender didn’t create the transaction with an `ovk` then they _cannot_ recover anything about the output from the chain, which means they would be unable to produce a Payment Disclosure if they lose the wallet that created the transaction in the first place (and don’t have backups of that particular wallet’s data). And this would violate one of the requirements of ZIP 311 (that was also violated by Sprout Payment Disclosures, making them far less useful): > Senders are not required to remember any ephemeral data from the creation of a transaction in order to produce a payment disclosure for that transaction. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [July 22, 2024, 8:58pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/13 "2024-07-22T20:58:27Z")
Yeah but this is sender centric. The OP is talking about showing the payment details for something he received without giving out his entire history. I am wondering why use zip 311 in this situation. Edit: Then as you said, he could share sym key + pkd. Arguably the one who wants the details should know the address, so maybe sym key is enough. ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [July 22, 2024, 9:04pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/14 "2024-07-22T21:04:30Z")
> [@hanh](#): > > Yeah but this is sender centric. The OP is talking about showing the payment details for something he received without giving out his entire history. Umm, no? They make no reference at all to receiving transactions, only to general transaction history which also encompasses spends, and therefore requires considering how to handle disclosure of spends. In the specific case of asking about disclosure of a transaction, they specifically reference spends (emphasis added) which is why I replied with a reference to ZIP 311: > [@Zec\_Max](#): > > Is it possible to only disclose certain transactions but not all? In reality, you can look into my wallet and see X amount, but you don’t know how much it was yesterday. I might have a bill, **which proves that I made some payment.** If you are solely concerned with revealing receives, then whether or not the sender used an `ovk` is irrelevant. You still can’t just disclose the symmetric key for decrypting `encCiphertext`, you also need to disclosed `pk_d`, but as a recipient you know your own `ivk` and can therefore always recover the matching `pk_d`. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [July 22, 2024, 9:06pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/15 "2024-07-22T21:06:53Z")
ok, if they want to disclose a payment out of their account then need to give the ock. ---
**Author:** ![Zec\_Max](https://avatars.discourse-cdn.com/v4/letter/z/3ab097/32.png) [@Zec\_Max](https://forum.zcashcommunity.com/u/Zec_Max)\ **Post date:** [July 22, 2024, 9:39pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/16 "2024-07-22T21:39:23Z")
Thanks for the input. > Senders are not required to remember any ephemeral data from the creation of a transaction in order to produce a payment disclosure for that transaction. Not sure if I understand this correctly, but right now, would I have to save the ephemeral data (I guess some transaction data) when I want to disclose a payment for a certain transaction? Actually, I would kind of like that—having the opportunity to disclose transactions I choose (comparable to a cash payment with a receipt) but also having the option not to (throwing the receipt away). In my optimal scenario from a user perspective, I would have the ability to give someone viewing access, but only for the transactions I choose (one or more), while they also don’t have the ability to know if these are all the transactions or not, similar to cash. Additionally, having plausible deniability on my side, where I might be unable to provide viewing access because I don’t have the ephemeral data, would be beneficial to me, as it gives me the ability to destroy my traces. Otherwise, I could always see myself being forced to give up my privacy. ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [July 22, 2024, 9:47pm UTC](https://forum.zcashcommunity.com/t/is-it-possible-to-destroy-a-view-key/48369/17 "2024-07-22T21:47:21Z")
> [@Zec\_Max](#): > > Not sure if I understand this correctly, but right now, would I have to save the ephemeral data (I guess some transaction data) when I want to disclose a payment for a certain transaction? Actually, I would kind of like that—having the opportunity to disclose transactions I choose (comparable to a cash payment with a receipt) but also having the option not to (throwing the receipt away). For received transactions, no: if your `ivk` can decrypt it from chain, then by definition anyone with access to your `ivk` can also decrypt it. There are ways around this, but none that are solely in your control (they require active collaboration with the transaction sender). For sent transactions, yes. [In our Rust crates we have the concept of an “OVK Policy”](https://docs.rs/zcash_client_backend/0.12.1/zcash_client_backend/wallet/enum.OvkPolicy.html), which currently has three options: - Prevent the transaction details from being recoverable from chain by anyone (no `ovk`). - Your wallet could choose to store some ephemeral data here to retain decryptability; we don’t expose this capability. - Enable the transaction details to be recoverable from chain by the sender (by using the `ovk` derived from their full viewing key). - Enable the transaction details to be recoverable with a custom `ovk`. - This can be an ephemeral value that the wallet generates, or it could be used to implement some kind of ratcheting (enabling an `ovk` to recover some time period of sent transaction data, after which it gets rotated).