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.
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.
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.
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).
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.
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.
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.
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.
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:
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.
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.
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).
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).