1

Looking at both the Zcash original paper and the updated Zcash protocol specification, 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

The same attack works in the updated Zcash proposal (see Section 4.4 on page 19 in v2018-beta2.0, plus image below).

Zcash coin commitment from their protocol spec

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!

1

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, 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.

  • 1
    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 Jun 18 '18 at 22:15
1

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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.