<p><em>tl;dr</em> Alice can reveal payments she made to Bob. She cannot reveal payments that others made to Bob, or reveal what (if anything) Bob does with the ZEC that Alice sent.</p>

<hr>

<p>Revealing the pre-image of the note commitment only proves that Alice knows the pre-image. It does not prove that Alice sent the transaction, because the proof is replayable: once revealed, anyone can take the randomness and note data, and show it to someone else.</p>

<p>In order for Alice to prove to someone that she sent the transaction, she can do the following:</p>

<ul>
<li>Write a message that contains:

<ul>
<li>The private key <code>esk</code> used to encrypt the note (randomness and value) to Bob.</li>
<li>Bob's payment address.</li>
<li>A challenge string chosen by the person Alice is convincing.</li>
</ul></li>
<li>Sign the message using the private key <code>joinSplitPrivKey</code> corresponding to the <code>joinsplitPubKey</code> that was originally used to sign the transaction.</li>
</ul>

<p>The signed message is proof that Alice currently has access to <code>joinSplitPrivKey</code> (because the challenge string is fresh). Assuming that <code>joinSplitPrivKey</code> is never revealed, Alice is indistinguishable from the person who created the transaction (i.e. either she or someone with her spending keys made the payment). This is what we call a <a href="https://github.com/zcash/zips/pull/119" rel="nofollow noreferrer">payment disclosure</a>, and is how e.g. you would prove to an exchange (or a third party dispute resolution service) that you did indeed pay them.</p>

<p>What you are describing is fundamentally the same issue that messaging apps have with end-to-end encryption: someone with intended access to the data can accidentally or intentionally reveal it. Removing this potential privacy leak would by definition mean that Alice cannot see some or all details about her own outgoing transactions, which is either a contradiction (in the Zcash model, Alice needs to be able to calculate a commitment from its pre-image in order to create valid transactions), or a completely unusable payment system!</p>

<p>Note however that even though Alice can prove that she sent a transaction to Bob, she cannot reveal <strong>anything</strong> about what Bob does with the note he received (because she does not have Bob's spending key, and thus can't calculate the nullifier that will would be revealed at spend time). Alice's ability to reveal information is limited to information she was ever able to view.</p>

CC BY-SA 4.0
2018-06-18T22:15:11.333Z
Thank you! I am not sure I follow why _"removing this potential privacy leak would by definition mean that Alice cannot see some or all details about her own outgoing transactions"_. I could imagine designs where Alice knows all details about her transactions (maybe some of them are kept offline) but these details are completely "deniable:" they cannot be used to prove Alice ever sent coins to Bob. However, it seems this will prevent Alice from ever convincing Bob that she paid him, which could be problematic!
Alin Tomescu
CC BY-SA 4.0
2018-06-18T03:09:15.847Z
2018-06-18T03:09:15.847Z
str4d
<p>To add to @str4d's answer, here are links to public documentation and discussion of the payment disclosure feature:</p>

<ul>
<li><a href="https://blog.z.cash/viewing-keys-selective-disclosure/" rel="nofollow noreferrer">Selective Disclosure &amp; Shielded Viewing Keys - Zcash blog</a></li>
<li><a href="https://github.com/zcash/zcash/blob/master/doc/payment-disclosure.md" rel="nofollow noreferrer">Payment Disclosure (Experimental Feature)</a></li>
<li><a href="https://medium.com/@_garethtdavies/an-introduction-to-payment-disclosure-in-zcash-96748c209d49" rel="nofollow noreferrer">An Introduction to Payment Disclosure in Zcash - Gareth Davies</a></li>
</ul>

<p>Note that if Bob were concerned about this possibility, he could have given Alice a unique address to pay him, so that a revealed payment to that address could not be linked to his other addresses. This is suggested in section 3.1 of the protocol spec.</p>

<p>In Sapling, there is a new feature called "diversified payment addresses" that makes this usage more efficient: Bob can give out a unique  diversified address to each potential payer, and can still scan the block chain for incoming payments as efficiently as if he had only one address. We're planning for this to be integrated into the Zcash equivalent of BIP 32 (Hierarchical Deterministic Addresses), so that all secrets associated with a wallet can be backed up using a single seed.</p>

CC BY-SA 4.0
2018-06-18T13:49:51.373Z
2018-06-18T13:59:18.710Z
2018-06-18T13:59:18.710Z
Daira-Emma Hopwood
<p>Looking at both the Zcash <a href="http://zerocash-project.org/media/pdf/zerocash-oakland2014.pdf" rel="nofollow noreferrer">original paper</a> and the updated Zcash <a href="https://github.com/zcash/zips/blob/master/protocol/protocol.pdf" rel="nofollow noreferrer">protocol specification</a>, it seems that after Alice paid Bob, she can reveal to the world that she did so.</p>

<p>Alice can do so by revealing the randomness of the <em>new coin commitments</em> she generated, one of which contains Bob's PK and the amount. For example, in the image below, Alice reveals the elements highlighted in red (i.e., Alice's randomness) and purple (i.e., Bob's PK and the value), while the elements in yellow are already public.</p>

<p><a href="https://i.sstatic.net/Tv1Ll.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Tv1Ll.png" alt="Zcash Pour TXN description from Oakland paper"></a></p>

<p>The same attack works in the updated Zcash proposal (see Section 4.4 on page 19 in <a href="https://github.com/zcash/zips/blob/948c9109878bfae4d838208343d57266a48fc3d4/protocol/protocol.pdf" rel="nofollow noreferrer">v2018-beta2.0</a>, plus image below).</p>

<p><a href="https://i.sstatic.net/KBjYR.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/KBjYR.png" alt="Zcash coin commitment from their protocol spec"></a></p>

<p>I just want to confirm that (1) I am not missing anything and this is possible and (2) it's potentially problematic. For example, if Alice paid Bob for some illicit goods or services, she can later reveal that she did so.</p>

<p>Thoughts would be welcome!</p>

<privacy><zcash>
Can malicious payer deanonymize payee in Zcash?
Alin Tomescu
# Can malicious payer deanonymize payee in Zcash?

(Asked by: username_0 on 2018-06-14)

Looking at both the Zcash [original paper](http://zerocash-project.org/media/pdf/zerocash-oakland2014.pdf) and the updated Zcash [protocol specification](https://github.com/zcash/zips/blob/master/protocol/protocol.pdf), it seems that after Alice paid Bob, she can reveal to the world that she did so.

Alice can do so by revealing the randomness of the *new coin commitments* she generated, one of which contains Bob's PK and the amount. For example, in the image below, Alice reveals the elements highlighted in red (i.e., Alice's randomness) and purple (i.e., Bob's PK and the value), while the elements in yellow are already public.

[![Zcash Pour TXN description from Oakland paper](https://i.sstatic.net/Tv1Ll.png)](https://i.sstatic.net/Tv1Ll.png)

The same attack works in the updated Zcash proposal (see Section 4.4 on page 19 in [v2018-beta2.0](https://github.com/zcash/zips/blob/948c9109878bfae4d838208343d57266a48fc3d4/protocol/protocol.pdf), plus image below).

[![Zcash coin commitment from their protocol spec](https://i.sstatic.net/KBjYR.png)](https://i.sstatic.net/KBjYR.png)

I just want to confirm that (1) I am not missing anything and this is possible and (2) it's potentially problematic. For example, if Alice paid Bob for some illicit goods or services, she can later reveal that she did so.

Thoughts would be welcome!

**Tags:** privacy, zcash


---

## 2 answers

### Answer by username_1 on 2018-06-18. Score: 1 | Accepted answer

*tl;dr* Alice can reveal payments she made to Bob. She cannot reveal payments that others made to Bob, or reveal what (if anything) Bob does with the ZEC that Alice sent.

---

Revealing the pre-image of the note commitment only proves that Alice knows the pre-image. It does not prove that Alice sent the transaction, because the proof is replayable: once revealed, anyone can take the randomness and note data, and show it to someone else.

In order for Alice to prove to someone that she sent the transaction, she can do the following:

* Write a message that contains:
  + The private key `esk` used to encrypt the note (randomness and value) to Bob.
  + Bob's payment address.
  + A challenge string chosen by the person Alice is convincing.
* Sign the message using the private key `joinSplitPrivKey` corresponding to the `joinsplitPubKey` that was originally used to sign the transaction.

The signed message is proof that Alice currently has access to `joinSplitPrivKey` (because the challenge string is fresh). Assuming that `joinSplitPrivKey` is never revealed, Alice is indistinguishable from the person who created the transaction (i.e. either she or someone with her spending keys made the payment). This is what we call a [payment disclosure](https://github.com/zcash/zips/pull/119), and is how e.g. you would prove to an exchange (or a third party dispute resolution service) that you did indeed pay them.

What you are describing is fundamentally the same issue that messaging apps have with end-to-end encryption: someone with intended access to the data can accidentally or intentionally reveal it. Removing this potential privacy leak would by definition mean that Alice cannot see some or all details about her own outgoing transactions, which is either a contradiction (in the Zcash model, Alice needs to be able to calculate a commitment from its pre-image in order to create valid transactions), or a completely unusable payment system!

Note however that even though Alice can prove that she sent a transaction to Bob, she cannot reveal **anything** about what Bob does with the note he received (because she does not have Bob's spending key, and thus can't calculate the nullifier that will would be revealed at spend time). Alice's ability to reveal information is limited to information she was ever able to view.

> **Comments:**
> **username_0**: Thank you! I am not sure I follow why _"removing this potential privacy leak would by definition mean that Alice cannot see some or all details about her own outgoing transactions"_. I could imagine designs where Alice knows all details about her transactions (maybe some of them are kept offline) but these details are completely "deniable:" they cannot be used to prove Alice ever sent coins to Bob. However, it seems this will prevent Alice from ever convincing Bob that she paid him, which could be problematic!  

---

### Answer by username_2 on 2018-06-18. Score: 1

To add to @username_1's answer, here are links to public documentation and discussion of the payment disclosure feature:

* [Selective Disclosure & Shielded Viewing Keys - Zcash blog](https://blog.z.cash/viewing-keys-selective-disclosure/)
* [Payment Disclosure (Experimental Feature)](https://github.com/zcash/zcash/blob/master/doc/payment-disclosure.md)
* [An Introduction to Payment Disclosure in Zcash - Gareth Davies](https://medium.com/@_garethtdavies/an-introduction-to-payment-disclosure-in-zcash-96748c209d49)

Note that if Bob were concerned about this possibility, he could have given Alice a unique address to pay him, so that a revealed payment to that address could not be linked to his other addresses. This is suggested in section 3.1 of the protocol spec.

In Sapling, there is a new feature called "diversified payment addresses" that makes this usage more efficient: Bob can give out a unique diversified address to each potential payer, and can still scan the block chain for incoming payments as efficiently as if he had only one address. We're planning for this to be integrated into the Zcash equivalent of BIP 32 (Hierarchical Deterministic Addresses), so that all secrets associated with a wallet can be backed up using a single seed.


---

