Managing contributions for an event

Alice runs an event on behalf of Bob and Carol, who both agree to split the cost equally. Alice receives a single payment for half the amount, and wants proof of who it came from (so she knows which person to follow up with for the remaining amount). Carol can provide a payment disclosure that reveals to Alice:

• The correct amount was sent to the Alice's recipient address in the given transaction.
• Carol was the sender of that transaction (more precisely, Carol controls the spend authority used in that transaction).

and does not reveal:

• Carol's payment address.
• Any of Carol's other diversified payment addresses.
• Any of Carol's other transactions.

For this use case, it is not necessary (and not necessarily intended) that the payment disclosure be publically verifiable.

Donation drive

Diana is a well-known individual with a public shielded payment address (for receiving donations). She runs a matching donation drive to the non-profit Totally Legit Bunnies, and wants to prove to her followers that she correctly matched their donations. Diana can create a payment disclosure, and post it to her social media account, that reveals:

• The correct amount was sent to the Totally Legit Bunnies' recipient address in the given transaction.
• The sender of the transaction is the payment address that is associated with Diana.

and does not reveal:

• Any of Diana's other diversified payment addresses.
• Any of Diana's other transactions.

Merchant dispute

Edward goes to CarsRFast to buy a Lamborghini, and sends funds from his shielded address to CarsRFast's transparent address. They can see a payment has been made, but claim that they have not received a payment from Edward. He can create a payment disclosure that reveals:

• Edward was the sender of the given transaction.

and does not reveal:

• Edward's payment address.
• Any of Edward's other diversified payment addresses.
• Any of Edward's other transactions.

Shielded withdrawals from an exchange

CorpBux is an exchange with a transparent hot wallet, and enables customers to withdraw their funds to shielded addresses. They can create a payment disclosure, that they can give to their customers, that reveals:

• The correct amount was sent to the customer's shielded recipient address in the given transaction.
• CorpBux was the sender of the given transaction.

Payment disclosure data structure

A payment disclosure has the following fields:

• txid: Transaction id for the transaction tx being disclosed.
• msg: A message field, which could contain a challenge value from the party to whom the payment disclosure is directed.
• \(\mathsf{transparentInputs}\!\) : A sequence of the transparent inputs for which we are proving spend authority \([0..\mathsf{length}(\mathsf{tx.vin})]\)
  • \(\mathsf{index}\!\) : An index into \(\mathsf{tx.vin}\!\) .
  • \(\mathsf{sig}\!\) : A BIP 322 signature. 9
    • TODO: zcashd currently only supports the legacy format defined in BIP 322. We may want to backport full BIP 322 support before having transparent input support in this ZIP, to ensure it does what we need.
    • TODO: BIP 322 specifies consensus rule checks as part of the signature verification process. We will likely need to migrate it over to an equivalent ZIP that specifies these for Zcash (which has a different set of script validation consensus rules).
• \(\mathsf{saplingSpends}\!\) : A sequence of the Sapling Spends for which we are proving spend authority \([0..\mathsf{length}(\mathsf{tx.shieldedSpends})]\)
  • \(\mathsf{index}\!\) : An index into \(\mathsf{tx.shieldedSpends}\!\) .
  • \(\mathsf{cv}\!\) : A value commitment to the spent note.
  • \(\mathsf{rk}\!\) : A randomized public key linked to the spent note.
  • \(\mathsf{zkproof_{spend}}\!\) : A Sapling spend proof.
  • [Optional] A payment address proof addr_proof:
    • Any \((\mathsf{d, pk_d})\) such that \(\mathsf{pk_d} = [\mathsf{ivk}] \mathsf{DiversifyHash}(\mathsf{d})\)
    • \(\mathsf{nullifier_{addr}}\!\) : A nullifier for a ZIP 304 fake note. 11
    • \(\mathsf{zkproof_{addr}}\!\) : A Sapling spend proof.
  • \(\mathsf{spendAuthSig}\)
• \(\mathsf{saplingOutputs}\!\) : A sequence of the Sapling Outputs that we are disclosing \([0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]\)
  • \(\mathsf{index}\!\) : An index into \(\mathsf{tx.shieldedOutputs}\!\) .
  • \(\mathsf{ock}\!\) : The outgoing cipher key that allows this output to be recovered. 5

TODO: Add support for Orchard.

TODO: Decide on payment disclosure versioning.

TODO: Define encodings for unsigned and signed payment disclosures.

Creating a payment disclosure

The inputs to a payment disclosure are:

• The transaction.
• The SLIP-44 10 coin type.
• The message \(msg\) to be included (which may be empty).
• A sequence of \((\mathsf{outputIndex}, \mathsf{ock})\) tuples (which may be empty).
• A sequence of Sapling spend tuples (which may be empty) containing:
  • A Sapling spend index.
  • Its corresponding expanded spending key \((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})\!\) .
  • [Optional] An associated payment address \((\mathsf{d}, \mathsf{pk_d})\!\) .
• A sequence of transparent input tuples (which may be empty) containing:
  • \(\mathsf{index}\!\) : An index into \(\mathsf{tx.vin}\!\) .
  • The inputs to a BIP 322 signature (excluding message_data).

The caller MUST provide at least one input tuple of any type (either a Sapling spend tuple or a transparent input tuple).

The payment disclosure is created as follows:

• For each Sapling spend index:
  • Create a Sapling spend proof for the note that was spent in \(\mathsf{tx.shieldedSpends[index]}\!\) , using the same anchor, to obtain \((\mathsf{cv}, \mathsf{rk}, \mathsf{zkproof_{spend}})\) as well as the random \(\alpha\) that was generated internally.
  • [Optional] If an associated payment address was provided for this spend index, create a ZIP 304 signature proof for that payment address, 11 using \(\alpha\) and \(\mathsf{rk}\) from the previous step. We obtain \((\mathsf{nullifier_{addr}}, \mathsf{zkproof_{addr}})\) from this step.
• For each transparent input index:
  • TODO: Prepare BIP 322 signature inputs using msg as the message_data.
• Construct an unsigned payment disclosure from the disclosed Sapling outputs, and the above data for the Sapling spends and transparent inputs. Define the encoding of this as \(unsignedPaymentDisclosure\!\) .
• For each Sapling spend index:
  • Let \(\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(\alpha, \mathsf{ask})\!\) .
  • Let \(coinType\) be the 4-byte little-endian encoding of the SLIP 44 coin type in its index form, not its hardened form (i.e. 133 for mainnet Zcash).
  • Let \(digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZIP311Signed”}\,||\,coinType, unsignedPaymentDisclosure)\!\) .
  • Let \(spendAuthSig = \mathsf{SpendAuthSig.Sign}(\mathsf{rsk}, digest)\!\) .
• For each transparent input index:
  • TODO: Create a BIP 322 signature using msg as the message_data.
• Return the payment disclosure as the combination of the unsigned payment disclosure and the set of spendAuthSig and transparent signature values.

Verifying a payment disclosure

Given a payment disclosure \(\mathsf{pd}\!\) , a transaction \(\mathsf{tx}\!\) , and the height of the block in which \(\mathsf{tx}\) was mined (which we assume was verified by the caller), the verifier proceeds as follows:

• Perform the following structural correctness checks, returning false if any check fails:
  • \(\mathsf{pd.txid} = \mathsf{tx.txid}()\)
  • Sequence length correctness:
    • \(\mathsf{length}(\mathsf{pd.saplingOutputs}) \leq \mathsf{length}(\mathsf{tx.shieldedOutputs})\)
    • \(\mathsf{length}(\mathsf{pd.saplingSpends}) \leq \mathsf{length}(\mathsf{tx.shieldedSpends})\)
    • \(\mathsf{length}(\mathsf{pd.transparentInputs}) \leq \mathsf{length}(\mathsf{tx.vin})\)
  • Index uniqueness:
    • For every \(\mathsf{output}\) in \(\mathsf{pd.saplingOutputs}\!\) , \(\mathsf{output.index}\) only occurs once.
    • For every \(\mathsf{spend}\) in \(\mathsf{pd.saplingSpends}\!\) , \(\mathsf{spend.index}\) only occurs once.
    • For every \(\mathsf{input}\) in \(\mathsf{pd.transparentInputs}\!\) , \(\mathsf{input.index}\) only occurs once.
  • Index correctness:
    • For every \(\mathsf{output}\) in \(\mathsf{pd.saplingOutputs}\!\) , \(\mathsf{output.index} < \mathsf{length}(\mathsf{tx.shieldedOutputs})\)
    • For every \(\mathsf{spend}\) in \(\mathsf{pd.saplingSpends}\!\) , \(\mathsf{spend.index} < \mathsf{length}(\mathsf{tx.shieldedSpends})\)
    • For every \(\mathsf{input}\) in \(\mathsf{pd.transparentInputs}\!\) , \(\mathsf{input.index} < \mathsf{length}(\mathsf{tx.vin})\)
  • \(\mathsf{length}(\mathsf{pd.saplingSpends}) + \mathsf{length}(\mathsf{pd.transparentInputs}) > 0\)
• Let \(unsignedPaymentDisclosure\) be the encoding of the payment disclosure without signatures.
• Let \(coinType\) be the 4-byte little-endian encoding of the coin type in its index form, not its hardened form (i.e. 133 for mainnet Zcash).
• Let \(digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZIP311Signed”}\,||\,coinType, unsignedPaymentDisclosure)\!\) .
• For every \(\mathsf{spend}\) in \(\mathsf{pd.saplingSpends}\!\) :
  • If \(\mathsf{SpendAuthSig.Verify}(\mathsf{spend.rk}, digest, \mathsf{spend.spendAuthSig}) = 0\!\) , return false.
  • [Optional] If a payment address proof \(\mathsf{addrProof}\) is present in \(\mathsf{spend}\!\) , verify \((\mathsf{addrProof.nullifier_{addr}}, \mathsf{spend.rk}, \mathsf{addrProof.zkproof_{addr}})\) as a ZIP 304 proof for \((\mathsf{addrProof.d}, \mathsf{addrProof.pk_d})\) 11. If verification fails, return false.
  • Decode and verify \(\mathsf{zkproof_{spend}}\) as a Sapling spend proof 4 with primary input:
    • \(\mathsf{tx.shieldedSpends[spend.index].rt}\)
    • \(\mathsf{spend.cv}\)
    • \(\mathsf{tx.shieldedSpends[spend.index].nf}\)
    • \(\mathsf{spend.rk}\)

    If verification fails, return false.

• For every \(\mathsf{input}\) in \(\mathsf{pd.transparentInputs}\!\) :
  • TODO: BIP 322 verification.
• For every \(\mathsf{output}\) in \(\mathsf{pd.saplingOutputs}\!\) :
  • Recover the Sapling note in \(\mathsf{tx.shieldedOutputs}[\mathsf{output.index}]\) via the process specified in 6 with inputs \((height, \mathsf{output.ock})\!\) . If recovery returns \(\bot\!\) , return false.
• Return true.

Payment disclosure validity in UIs

TODO: Set some standards for how UIs should display payment disclosures, and how they should convey the various kinds of validity information:

• One, but not all, of the spenders proved spend authority.
• All spenders of a specific type proved spend authority.
• All spenders proved spend authority.
• These, but also including optional payment address proofs.