Hey guys!
I’m new in Zcash so apologize for my stupid question.
But isn’t Zcash idea of private transaction contradicts the idea of transparent transactions in blockchain? Or, maybe, I don’t understand something?
Please help!
Not a stupid question at all, probably the most important feature of Zcash.
Transparent transactions cause problems, for example a large business would be publishing all their financial information if they used them - which is a bad thing as their competitors could track/identify their customers, suppliers, basically everything.
Zcash shielded transactions allow you to choose who can see that information, for example regulators, auditors, for taxes, responding to court orders etc - all important things.
Its also important for personal privacy, I doubt anyone likes the idea of their transactions being tracked/back-tracked to identify how much money they have.
4 Likes
I see. So you still can allow some people to see your transactions
1 Like
Referred to as “selective disclosure”
1 Like
It’s all on blockchain idea, but you have the choice to whom to show your transactions, but I guess in some kind of sense it contradicts to idea of blockchain
I didn’t know I can show my transactions to anyone
Really?! Thanks for info. I didn’t know about it.
Its in the works (has been on the drawing table for a while now)
opened 08:49PM - 04 Feb 19 UTC
A-crypto
F-selective-disclosure
A-wallet-change
The Payment Disclosure feature for Sprout discloses a transaction's amount, dest… ination address and the contents of the encrypted memo field.
There are situations where the Sender of a transaction may want to also share a transaction's _source_ address(es) in a way that can be verified independently by a third party.
opened 11:44PM - 25 Sep 17 UTC
A-crypto
I-privacy
A-consensus
F-selective-disclosure
M-requires-nu
F-memo-field
not in Sapling
(I couldn't find an existing issue that covered this.)
@jackgavigan mentioned… an idea where individual parts of a transaction / received note could be individually revealed without revealing the entire contents. It seems to me that, at least at the per-transaction level, this could potentially be implemented pretty cheaply.
Currently, we obtain a per-recipient per-transaction symmetric key (via DH + KDF) to encrypt the note contents as a single blob. Instead, we could take that key, and derive personalised sub-keys for each "field" of the note, individually encrypting the fields. Then, disclosure of a single field would entail disclosing that particular subkey, while disclosing the entire output would be the same as before.
There is some interaction with the design of payment disclosure, depending on whether we'd want to be able to always authenticate that the field revealed is part of a spendable note, or only do that when the entire note is revealed - the former might require its own ZKP.
There would be some overhead to splitting up the ciphertext in this manner, as each chunk would need its own authentication tag. On the other hand, there may be a computational benefit to this, as not every field would need to be trial-decrypted to determine if a note belongs to an address (in particular, decryption of the memo field, which is the majority of the ciphertext, could be avoided).
Finally, the "fields" would need to be specified. I personally see three fields in the current notes:
- value
- other parts of the note (that can validate its correctness in combination with the value)
- memo field
Please kindly do us a favor!
