From 386626af5a477d235e5ff83fd48b0fb5a6b5c3bb Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Fri, 11 Dec 2020 23:42:18 +0000 Subject: [PATCH 01/14] Working draft of ZIP 311 --- zip-0311.rst | 259 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 257 insertions(+), 2 deletions(-) diff --git a/zip-0311.rst b/zip-0311.rst index 94b7b0e88..d23f74c0f 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -2,7 +2,262 @@ ZIP: 311 Title: Sapling Payment Disclosure - Owners: Deirdre Connolly - Status: Reserved + Owners: Jack Grigg + Status: Draft Category: Standards / RPC / Wallet Discussions-To: + + +Abstract +======== + +This ZIP describes a mechanism and format for disclosing information about Sapling spends +and outputs within a transaction. In the typical case, this means enabling a sender to +present a proof that they transferred funds to a recipient's Sapling address. + + +Motivation +========== + +Payment disclosure is useful in a number of situations, for example: + +- A sender may need to prove that their payment was sent and received by a recipient. +- A third party needs to verify that a payment between sender and recipient was executed + successfully. + +When a transaction involves only transparent addresses, the sender and recipient can verify payment by examining the blockchain. A third party can also perform this verification if they know the transparent addresses of the involved parties. + +However, if the transaction involves shielded addresses, the blockchain by itself does not contain enough information to allow a record of the payment to be reconstructed and verified. + +Let us examine the types of transaction that might occur and when a method of payment disclosure would be useful: + +transparent --> transparent + The source, destination and amount are visible on the public blockchain. Payment + disclosure is not required to view the transaction. + +transparent --> shielded + The destination address and amount sent to that address cannot be confirmed. Payment + disclosure is required. + +shielded --> transparent + The recipient can see the amount received at their destination address, but cannot + identify the sender. Requires either an interactive payment disclosure, or a + non-interactive payment disclosure that reveals the sender's address. + +shielded --> shielded + The sender, recipient and amount are unknown. Payment disclosure required. + + +Use cases +========= + +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: + +- 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. + +Donation drive +-------------- + +Diana is a well-known individual with a public Sapling 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 dontations. 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 CoinCafe to buy a sandwich, and sends funds from his Sapling address to +CoinCafe'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 Sapling 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 recipient address in the given transaction. +- CorpBux was the sender of the given transaction. + + +Requirements +============ + +- The payment disclosure may disclose the contents of zero or more Sapling outputs within + a single transaction. (Zero outputs is useful for t2z transactions.) +- Payment disclosures are non-malleable, and can only be created by a sender of the + transaction. +- A payment disclosure may be tied to a challenge, creating an interactive proof. +- Senders with a Sapling address may choose to provably reveal that address as part of the + payment disclosure. +- 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. (Performance may be + improved if they do cache witness data for spent notes.) + + +Specification +============= + +Payment disclosure data structure +--------------------------------- + +A payment disclosure has the following fields: + +- `txid`: Transaction id for the given transaction `tx`. + +- `msg`: A message field, which could contain a challenge value from the party to whom + the payment disclosure is directed. + +- `sapling_outputs`: A vector of the Sapling Outputs that we are disclosing + [0..tx.shieldedOutputs.len()] + + - `index`: An index into `tx.shieldedOutputs`. + - `ock`: The outgoing cipher key that allows this output to be recovered. + +- `sapling_spends`: A vector of the Sapling Spends for which we are proving spend authority + [0..tx.shieldedSpends.len()] + + - `index`: An index into `tx.shieldedSpends`. + - `cv` + - `rk` + - `zkproof_spend` + - [Optional] A payment address proof: + - Any `(d, pk_d)` such that `pk_d = [ivk] GH(d)` + - `nullifier_addr` + - `zkproof_addr` + - `spendAuthSig` + +- `transparent_inputs`: A vector of the transparent inputs for which we are proving spend + authority [0..tx.vin.len()] + + - `index`: An index into `tx.vin`. + - `sig`: A BIP 322 signature. + + - 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). + +Creating a payment disclosure +----------------------------- + +The inputs to a payment disclosure are: + +- The transaction. +- The SLIP-44 [#slip-0044]_ coin type. +- The message :math:`msg` to be included (which may be empty). +- A vector of `(output_index, ock)` tuples. +- A vector of tuples of: + + - A Sapling spend index. + - Its corresponding expanded spending key :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})`. + - (Optional) An associated payment address :math:`(\mathsf{d}, \mathsf{pk_d})`. + +- A vector of tuples of: + + - `index`: An index into `tx.vin`. + - The inputs to a BIP 322 signature (excluding `message_data`). + +The payment disclosure is created as follows: + +- For each Sapling spend index: + + - Create a Sapling spend proof for the note that was spent in `tx.shieldedSpends[index]`, + using the same anchor, to obtain `(cv, rk, zkproof_spend)` as well as the random α + 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, using α and `rk` from the + previous step. We obtain `(nullifier_addr, zkproof_addr)` from this step. + +- For each transparent input index: + + - TODO: Prepare BIP 322 signature inputs. + +- Construct an unsigned payment disclosure from the disclosed Sapling outputs, and the + above data for the Sapling spends and transparent inputs. + +- For each Sapling spend index: + + - Let :math:`\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})`. + + - Let :math:`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 :math:`digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, payment_disclosure_digest)`. + + - Let :math:`spendAuthSig = \mathsf{SpendAuthSig.Sign}(\mathsf{rsk}, digest)`. + +- For each transparent input index: + + - TODO: Create a BIP 322 signature. + +- Return the payment disclosure. + +Verifying a payment disclosure +------------------------------ + +UIs displaying a payment disclosure MUST support three levels of assurance in a payment disclosure: + +- Level 1: The payment disclosure contains valid `ock`s that disclose the specified outputs in the specified transaction. + - Full Sapling note decryption MUST succeed for all specified outputs. More precisely, all specified outputs MUST have valid note commitments when recovered using the specified corresponding `ock` via the process in Section 4.17.3. + - A payment disclosure that only satisfies level 1 may have been: + - modified to be a subset of some other payment disclosure; or + - merged with another level 1 payment disclosure for the same transaction; or + - extracted from a level 2+ payment disclosure. +- Level 2: In addition to level 1, the payment disclosure has been created by one or more of the senders of the original transaction. + +- Level 3: In addition to level 2, one or more of the proven spend authorities is bound to a + +Random notes below here + + +Rationale +========= + +If a sender elects, at transaction creation time, to use an `ovk` of :math:`\bot` for a +specific Sapling output, then they are unable to subsequently create a payment disclosure +that discloses that output. This maintains the semantics of `ovk`, in that the sender +explicitly chose to lose the capability to recover that output. + +Payment disclosures that prove Sapling spend authority are not required to reveal a +sender address. This is because it is impossible: we can "prove" the transaction came from +any of the diversified addresses linked to the spending key. Fundamentally, the "sender" +of a transaction is anyone who has access to the corresponding spend authority; in the +case of Sapling, a spend authority corresponds to multiple diversified addresses. In +situations where a sender address is already known to the verifier of the payment +disclosure, it may still be useful to have the option of linking the payment disclosure to +that address. From dbf56abbf485d1860b9bc5993709c64c1968ddcd Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Fri, 18 Dec 2020 23:26:02 +0000 Subject: [PATCH 02/14] ZIP 311: Add payment disclosure verification, general draft improvements --- zip-0311.rst | 311 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 240 insertions(+), 71 deletions(-) diff --git a/zip-0311.rst b/zip-0311.rst index d23f74c0f..f52ce9360 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -19,33 +19,38 @@ present a proof that they transferred funds to a recipient's Sapling address. Motivation ========== -Payment disclosure is useful in a number of situations, for example: +There are various situations where a proof-of-payment may be desired. For example: -- A sender may need to prove that their payment was sent and received by a recipient. -- A third party needs to verify that a payment between sender and recipient was executed - successfully. +- A sender may need to prove that their payment was sent to a recipient, and available to + be received (following the Zcash protocol in-band). +- A third party may need to verify that a payment between a given sender and recipient was + executed successfully. -When a transaction involves only transparent addresses, the sender and recipient can verify payment by examining the blockchain. A third party can also perform this verification if they know the transparent addresses of the involved parties. +When a transaction involves only transparent addresses, proof-of-payment is simple: The +sender provides the transaction ID, and the recipent examines the blockchain to confirm +that the transaction was mined. A third party can also perform this verification if they +know the transparent addresses of the involved parties. -However, if the transaction involves shielded addresses, the blockchain by itself does not contain enough information to allow a record of the payment to be reconstructed and verified. +However, if the transaction involves shielded addresses, the blockchain by itself does not +contain enough information to allow a record of the payment to be reconstructed and +verified: -Let us examine the types of transaction that might occur and when a method of payment disclosure would be useful: +=========== =========== ====== ========= ====== ================== +Source Destination Sender Recipient Amount Payment dislosure? +=========== =========== ====== ========= ====== ================== +Transparent Transparent 🔍 🔍 🔍 Not required +Transparent Shielded 🔍 🔐 🔐 Required +Shielded Transparent 🔒 🔍 🔍 Required +Shielded Shielded 🔒 🔐 🔐 Required +=========== =========== ====== ========= ====== ================== -transparent --> transparent - The source, destination and amount are visible on the public blockchain. Payment - disclosure is not required to view the transaction. +- 🔍 = Visible on the block chain. +- 🔐 = Cannot be confirmed without information that is not visible on the block chain. +- 🔒 = Requires either an interactive payment disclosure, or a non-interactive payment + disclosure that reveals the sender's address. -transparent --> shielded - The destination address and amount sent to that address cannot be confirmed. Payment - disclosure is required. - -shielded --> transparent - The recipient can see the amount received at their destination address, but cannot - identify the sender. Requires either an interactive payment disclosure, or a - non-interactive payment disclosure that reveals the sender's address. - -shielded --> shielded - The sender, recipient and amount are unknown. Payment disclosure required. +Enabling proof-of-payment for all of these transaction variants (where it is possible to +do so) is the subject of this ZIP. Use cases @@ -73,7 +78,7 @@ Donation drive Diana is a well-known individual with a public Sapling 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 dontations. Diana +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 @@ -88,8 +93,8 @@ and does not reveal: Merchant dispute ---------------- -Edward goes to CoinCafe to buy a sandwich, and sends funds from his Sapling address to -CoinCafe's transparent address. They can see a payment has been made, but claim that they +Edward goes to CarsRFast to buy a Lamborghini, and sends funds from his Sapling 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. @@ -115,7 +120,7 @@ Requirements ============ - The payment disclosure may disclose the contents of zero or more Sapling outputs within - a single transaction. (Zero outputs is useful for t2z transactions.) + a single transaction. (Zero outputs is useful for z2t transactions.) - Payment disclosures are non-malleable, and can only be created by a sender of the transaction. - A payment disclosure may be tied to a challenge, creating an interactive proof. @@ -126,6 +131,33 @@ Requirements improved if they do cache witness data for spent notes.) +Conventions +=========== + +The following functions used in this ZIP are defined in the Zcash protocol specification: +[#protocol]_ + +- :math:`\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})`, + :math:`\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)`, and + :math:`\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)` [#protocol-concretespendauthsig]_ + +We reproduce some notation and functions from [#protocol]_ here for convenience: + +- :math:`[k] P` means scalar multiplication of the elliptic curve point :math:`P` by the + scalar :math:`k`. + +- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)` refers to unkeyed BLAKE2b-256 in + sequential mode, with an output digest length of 32 bytes, 16-byte personalization + string :math:`p`, and input :math:`x`. + +We also define the following notation here: + +- :math:`[a..b]` means the sequence of values inclusive of :math:`a` and exclusive of + :math:`b`. + +- :math:`a\text{.len}()` means the length of the vector :math:`a`. + + Specification ============= @@ -139,30 +171,33 @@ A payment disclosure has the following fields: - `msg`: A message field, which could contain a challenge value from the party to whom the payment disclosure is directed. -- `sapling_outputs`: A vector of the Sapling Outputs that we are disclosing +- :math:`\mathsf{saplingOutputs}`: A vector of the Sapling Outputs that we are disclosing [0..tx.shieldedOutputs.len()] - - `index`: An index into `tx.shieldedOutputs`. - - `ock`: The outgoing cipher key that allows this output to be recovered. + - :math:`\mathsf{index}`: An index into `tx.shieldedOutputs`. + - :math:`\mathsf{ock}`: The outgoing cipher key that allows this output to be recovered. + [#protocol-saplingencrypt]_ + +- :math:`\mathsf{saplingSpends}`: A vector of the Sapling Spends for which we are proving + spend authority [0..tx.shieldedSpends.len()] + + - :math:`\mathsf{index}`: An index into `tx.shieldedSpends`. + - :math:`\mathsf{cv}`: A value commitment to the spent note. + - :math:`\mathsf{rk}`: A randomized public key linked to the spent note. + - :math:`\mathsf{zkproof_{spend}}`: A Sapling spend proof. + - [Optional] A payment address proof `addr_proof`: -- `sapling_spends`: A vector of the Sapling Spends for which we are proving spend authority - [0..tx.shieldedSpends.len()] + - Any :math:`(\mathsf{d, pk_d})` such that :math:`\mathsf{pk_d} = [\mathsf{ivk}] GH(\mathsf{d})` + - :math:`\mathsf{nullifier_{addr}}`: A nullifier for a ZIP 304 fake note. [#zip-0304]_ + - :math:`\mathsf{zkproof_{addr}}`: A Sapling spend proof. - - `index`: An index into `tx.shieldedSpends`. - - `cv` - - `rk` - - `zkproof_spend` - - [Optional] A payment address proof: - - Any `(d, pk_d)` such that `pk_d = [ivk] GH(d)` - - `nullifier_addr` - - `zkproof_addr` - - `spendAuthSig` + - :math:`\mathsf{spendAuthSig}` -- `transparent_inputs`: A vector of the transparent inputs for which we are proving spend - authority [0..tx.vin.len()] +- :math:`\mathsf{transparentInputs}`: A vector of the transparent inputs for which we are + proving spend authority [0..tx.vin.len()] - - `index`: An index into `tx.vin`. - - `sig`: A BIP 322 signature. + - :math:`\mathsf{index}`: An index into `tx.vin`. + - :math:`\mathsf{sig}`: A BIP 322 signature. [#bip-0322]_ - 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 @@ -171,6 +206,10 @@ A payment disclosure has the following fields: 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). +TODO: Decide on payment disclosure versioning. + +TODO: Define encodings for unsigned and signed payment disclosures. + Creating a payment disclosure ----------------------------- @@ -179,45 +218,51 @@ The inputs to a payment disclosure are: - The transaction. - The SLIP-44 [#slip-0044]_ coin type. - The message :math:`msg` to be included (which may be empty). -- A vector of `(output_index, ock)` tuples. -- A vector of tuples of: +- A vector of :math:`(\mathsf{outputIndex}, \mathsf{ock})` tuples (which may be empty). +- A vector of Sapling spend tuples (which may be empty) containing: - A Sapling spend index. - Its corresponding expanded spending key :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})`. - - (Optional) An associated payment address :math:`(\mathsf{d}, \mathsf{pk_d})`. + - [Optional] An associated payment address :math:`(\mathsf{d}, \mathsf{pk_d})`. -- A vector of tuples of: +- A vector of transparent input tuples (which may be empty) containing: - - `index`: An index into `tx.vin`. + - :math:`\mathsf{index}`: An index into `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 `tx.shieldedSpends[index]`, - using the same anchor, to obtain `(cv, rk, zkproof_spend)` as well as the random α - that was generated internally. + - Create a Sapling spend proof for the note that was spent in + :math:`\mathsf{tx.shieldedSpends[index]}`, using the same anchor, to obtain + :math:`(\mathsf{cv}, \mathsf{rk}, \mathsf{zkproof_{spend}})` as well as the random + :math:`\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, using α and `rk` from the - previous step. We obtain `(nullifier_addr, zkproof_addr)` from this step. + a ZIP 304 signature proof for that payment address, [#zip-0304]_ using :math:`\alpha` + and :math:`\mathsf{rk}` from the previous step. We obtain + :math:`(\mathsf{nullifier_{addr}}, \mathsf{zkproof_{addr}})` from this step. - For each transparent input index: - TODO: Prepare BIP 322 signature inputs. - Construct an unsigned payment disclosure from the disclosed Sapling outputs, and the - above data for the Sapling spends and transparent inputs. + above data for the Sapling spends and transparent inputs. Define the encoding of this as + :math:`unsignedPaymentDisclosure`. - For each Sapling spend index: - - Let :math:`\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})`. + - Let :math:`\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(\alpha, \mathsf{ask})`. - Let :math:`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 :math:`digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, payment_disclosure_digest)`. + - Let :math:`digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, unsignedPaymentDisclosure)`. - Let :math:`spendAuthSig = \mathsf{SpendAuthSig.Sign}(\mathsf{rsk}, digest)`. @@ -225,33 +270,105 @@ The payment disclosure is created as follows: - TODO: Create a BIP 322 signature. -- Return the payment disclosure. +- 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 ------------------------------ -UIs displaying a payment disclosure MUST support three levels of assurance in a payment disclosure: +Given a payment disclosure :math:`\mathsf{pd}`, a transaction :math:`\mathsf{tx}`, and the +`height` of the block in which :math:`\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: + + - :math:`\mathsf{pd.txid} = \mathsf{tx.txid}()` + + - Vector length correctness: + + - :math:`\mathsf{pd.saplingOutputs.len}() \leq \mathsf{tx.shieldedOutputs.len}()` + - :math:`\mathsf{pd.saplingSpends.len}() \leq \mathsf{tx.shieldedSpends.len}()` + - :math:`\mathsf{pd.transparentInputs.len}() \leq \mathsf{tx.vin.len}()` + + - Index uniqueness: + + - For every :math:`\mathsf{output}` in :math:`\mathsf{pd.saplingOutputs}`, + :math:`\mathsf{output.index}` only occurs once. + - For every :math:`\mathsf{spend}` in :math:`\mathsf{pd.saplingSpends}`, + :math:`\mathsf{spend.index}` only occurs once. + - For every :math:`\mathsf{input}` in :math:`\mathsf{pd.transparentInputs}`, + :math:`\mathsf{input.index}` only occurs once. + + - Index correctness: + + - For every :math:`\mathsf{output}` in :math:`\mathsf{pd.saplingOutputs}`, + :math:`\mathsf{output.index} < \mathsf{tx.shieldedOutputs.len}()` + - For every :math:`\mathsf{spend}` in :math:`\mathsf{pd.saplingSpends}`, + :math:`\mathsf{spend.index} < \mathsf{tx.shieldedSpends.len}()` + - For every :math:`\mathsf{input}` in :math:`\mathsf{pd.transparentInputs}`, + :math:`\mathsf{input.index} < \mathsf{tx.vin.len}()` + + - :math:`\mathsf{pd.saplingSpends.len}() + \mathsf{pd.transparentInputs.len}() > 0` + +- Let :math:`unsignedPaymentDisclosure` be the encoding of the payment disclosure without + signatures. -- Level 1: The payment disclosure contains valid `ock`s that disclose the specified outputs in the specified transaction. - - Full Sapling note decryption MUST succeed for all specified outputs. More precisely, all specified outputs MUST have valid note commitments when recovered using the specified corresponding `ock` via the process in Section 4.17.3. - - A payment disclosure that only satisfies level 1 may have been: - - modified to be a subset of some other payment disclosure; or - - merged with another level 1 payment disclosure for the same transaction; or - - extracted from a level 2+ payment disclosure. -- Level 2: In addition to level 1, the payment disclosure has been created by one or more of the senders of the original transaction. +- Let :math:`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). -- Level 3: In addition to level 2, one or more of the proven spend authorities is bound to a +- Let :math:`digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, unsignedPaymentDisclosure)`. -Random notes below here +- For every :math:`\mathsf{spend}` in :math:`\mathsf{pd.saplingSpends}`: + + - If :math:`\mathsf{SpendAuthSig.Verify}(\mathsf{spend.rk}, digest, \mathsf{spend.spendAuthSig}) = 0`, return false. + + - [Optional] If a payment address proof :math:`\mathsf{addrProof}` is present in + :math:`\mathsf{spend}`, verify :math:`(\mathsf{addrProof.nullifier_{addr}}, \mathsf{spend.rk}, \mathsf{addrProof.zkproof_{addr}})` as a ZIP 304 proof + for :math:`(\mathsf{addrProof.d}, \mathsf{addrProof.pk_d})` [#zip-0304]_. If verification fails, return + false. + + - Decode and verify :math:`\mathsf{zkproof_{spend}}` as a Sapling spend proof + [#protocol-spendstatement]_ with primary input: + + - :math:`\mathsf{tx.shieldedSpends[spend.index].rt}` + - :math:`\mathsf{spend.cv}` + - :math:`\mathsf{tx.shieldedSpends[spend.index].nf}` + - :math:`\mathsf{spend.rk}` + + If verification fails, return false. + +- For every :math:`\mathsf{input}` in :math:`\mathsf{pd.transparentInputs}`: + + - TODO: BIP 322 verification. + +- For every :math:`\mathsf{output}` in :math:`\mathsf{pd.saplingOutputs}`: + + - Recover the Sapling note in :math:`\mathsf{tx.shieldedOutputs}[\mathsf{output.index}]` + via the process specified in [#protocol-saplingdecryptovk]_ with inputs + :math:`(height, \mathsf{output.ock})`. If recovery returns :math:`\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. Rationale ========= -If a sender elects, at transaction creation time, to use an `ovk` of :math:`\bot` for a -specific Sapling output, then they are unable to subsequently create a payment disclosure -that discloses that output. This maintains the semantics of `ovk`, in that the sender -explicitly chose to lose the capability to recover that output. +If a sender elects, at transaction creation time, to use an :math:`\mathsf{ovk}` of +:math:`\bot` for a specific Sapling output, then they are unable to subsequently create a +payment disclosure that discloses that output. This maintains the semantics of +:math:`\mathsf{ovk}`, in that the sender explicitly chose to lose the capability to +recover that output. Payment disclosures that prove Sapling spend authority are not required to reveal a sender address. This is because it is impossible: we can "prove" the transaction came from @@ -261,3 +378,55 @@ case of Sapling, a spend authority corresponds to multiple diversified addresses situations where a sender address is already known to the verifier of the payment disclosure, it may still be useful to have the option of linking the payment disclosure to that address. + + +Security and Privacy Considerations +=================================== + +When spending Sapling notes normally in transactions, wallets select a recent anchor to +make the anonymity set of the spent note as large as possible. By contrast, Sapling spend +authority in a payment disclosure is proven using the same anchor that was used in the +transaction itself, instead of a recent anchor. We do this for efficency reasons: + +- The anchor is already encoded in the transaction, so can be omitted from the payment + disclosure encoding. +- It is necessary to have a witness for each spent note that is being included in the + payment disclosure. Using the same anchor means that the same witness can be used for + the transaction spend and the payment disclosure, which in turn means that wallets that + support payment disclosures only need to remember that witness, and do not need to + continually update witnesses for spent notes in the off-chance that they might be used + in a payment disclosure. + +There is no privacy benefit to selecting a more recent anchor; the anonymity set of the +note was "fixed" by the original spend (which revealed that the note existed as of that +anchor's height). + +We require all payment disclosures to prove spend authority for at least one input, in +order to simplify the verification UX. In particular, if payment disclosures without +spends were considered valid, an invalid payment disclosure with invalid signatures (that +would be shown as invalid by UIs) could be mutated into a payment disclosure that would be +shown as valid by UIs, by stripping off the signatures. We do not believe that this +prevents any useful use cases; meanwhile if someone is intent on obtaining Sapling output +disclosures regardless of the validity of their source, they will do so without a common +standard. + + +Reference implementation +======================== + +TBD + + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#RFC4648] `RFC 4648: The Base16, Base32, and Base64 Data Encodings `_ +.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ +.. [#protocol-spendstatement] `Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling) `_ +.. [#protocol-saplingencrypt] `Zcash Protocol Specification, Version 2020.1.15. 4.17.1: Encryption (Sapling) `_ +.. [#protocol-saplingdecryptovk] `Zcash Protocol Specification, Version 2020.1.15. 4.17.3: Decryption using a Full Viewing Key (Sapling) `_ +.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature `_ +.. [#bip-0322] `BIP 322: Generic Signed Message Format `_ +.. [#slip-0044] `SLIP-0044 : Registered coin types for BIP-0044 `_ +.. [#zip-0304] `ZIP 304: Sapling Address Signatures `_ From 0076879df4924988fa00b9930b29764227f4957d Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 18 Dec 2020 23:30:12 +0000 Subject: [PATCH 03/14] Apply suggestions from code review Co-authored-by: Daira Hopwood --- zip-0311.rst | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/zip-0311.rst b/zip-0311.rst index f52ce9360..ddc157291 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -72,6 +72,8 @@ 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 -------------- @@ -112,7 +114,8 @@ CorpBux is an exchange with a transparent hot wallet, and enables customers to w their funds to Sapling 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 recipient address in the given transaction. +- The correct amount was sent to the customer's shielded recipient address in the given + transaction. - CorpBux was the sender of the given transaction. @@ -121,8 +124,10 @@ Requirements - The payment disclosure may disclose the contents of zero or more Sapling outputs within a single transaction. (Zero outputs is useful for z2t transactions.) -- Payment disclosures are non-malleable, and can only be created by a sender of the - transaction. +- Payment disclosures can only be created by a sender of the transaction, + and are non-malleable (that is, no-one else can take one or more payment + disclosures and construct a new one that they would not have been able + to make independently). - A payment disclosure may be tied to a challenge, creating an interactive proof. - Senders with a Sapling address may choose to provably reveal that address as part of the payment disclosure. @@ -166,7 +171,7 @@ Payment disclosure data structure A payment disclosure has the following fields: -- `txid`: Transaction id for the given transaction `tx`. +- `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. @@ -249,7 +254,7 @@ The payment disclosure is created as follows: - For each transparent input index: - - TODO: Prepare BIP 322 signature inputs. + - 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 @@ -259,7 +264,7 @@ The payment disclosure is created as follows: - Let :math:`\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(\alpha, \mathsf{ask})`. - - Let :math:`coinType` be the 4-byte little-endian encoding of the coin type in its + - Let :math:`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 :math:`digest = \mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{"ZIP311Signed"}\,||\,coinType, unsignedPaymentDisclosure)`. @@ -268,7 +273,7 @@ The payment disclosure is created as follows: - For each transparent input index: - - TODO: Create a BIP 322 signature. + - 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. @@ -376,7 +381,7 @@ any of the diversified addresses linked to the spending key. Fundamentally, the of a transaction is anyone who has access to the corresponding spend authority; in the case of Sapling, a spend authority corresponds to multiple diversified addresses. In situations where a sender address is already known to the verifier of the payment -disclosure, it may still be useful to have the option of linking the payment disclosure to +disclosure (or publically), it may still be useful to have the option of linking the payment disclosure to that address. From 28bc4e16115d39ccf35a54b50cc84633198c12cf Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Fri, 18 Dec 2020 23:31:14 +0000 Subject: [PATCH 04/14] ZIP 311: Regenerate HTML --- README.rst | 2 +- index.html | 2 +- zip-0311.html | 603 +++++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 603 insertions(+), 4 deletions(-) diff --git a/README.rst b/README.rst index 3f25986f9..99d0b7046 100644 --- a/README.rst +++ b/README.rst @@ -112,7 +112,7 @@ Index of ZIPs 308 Sprout to Sapling Migration Final 309 Blind Off-chain Lightweight Transactions (BOLT) Reserved 310 Security Properties of Sapling Viewing Keys Draft - 311 Sapling Payment Disclosure Reserved + 311 Sapling Payment Disclosure Draft 312 Shielded Multisignatures using FROST Reserved 313 Reduce Default Transaction Fee Reserved 321 Payment Request URIs Proposed diff --git a/index.html b/index.html index f33ed0501..b34100e7e 100644 --- a/index.html +++ b/index.html @@ -85,7 +85,7 @@ 308 Sprout to Sapling Migration Final 309 Blind Off-chain Lightweight Transactions (BOLT) Reserved 310 Security Properties of Sapling Viewing Keys Draft - 311 Sapling Payment Disclosure Reserved + 311 Sapling Payment Disclosure Draft 312 Shielded Multisignatures using FROST Reserved 313 Reduce Default Transaction Fee Reserved 321 Payment Request URIs Proposed diff --git a/zip-0311.html b/zip-0311.html index 9d6a86e98..6ae8faba3 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -3,15 +3,614 @@ ZIP 311: Sapling Payment Disclosure + 
ZIP: 311
 Title: Sapling Payment Disclosure
-Owners: Deirdre Connolly <deirdre@zfnd.org>
-Status: Reserved
+Owners: Jack Grigg <jack@electriccoin.co>
+Status: Draft
 Category: Standards / RPC / Wallet
 Discussions-To: <https://github.com/zcash/zips/issues/387>
+

Abstract

+

This ZIP describes a mechanism and format for disclosing information about Sapling spends and outputs within a transaction. In the typical case, this means enabling a sender to present a proof that they transferred funds to a recipient's Sapling address.

+
+

Motivation

+

There are various situations where a proof-of-payment may be desired. For example:

+
    +
  • A sender may need to prove that their payment was sent to a recipient, and available to be received (following the Zcash protocol in-band).
    • +
  • A third party may need to verify that a payment between a given sender and recipient was executed successfully.
    • +
+

When a transaction involves only transparent addresses, proof-of-payment is simple: The sender provides the transaction ID, and the recipent examines the blockchain to confirm that the transaction was mined. A third party can also perform this verification if they know the transparent addresses of the involved parties.

+

However, if the transaction involves shielded addresses, the blockchain by itself does not contain enough information to allow a record of the payment to be reconstructed and verified:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SourceDestinationSenderRecipientAmountPayment dislosure?
TransparentTransparent🔍🔍🔍Not required
TransparentShielded🔍🔐🔐Required
ShieldedTransparent🔒🔍🔍Required
ShieldedShielded🔒🔐🔐Required
+
    +
  • 🔍 = Visible on the block chain.
    • +
  • 🔐 = Cannot be confirmed without information that is not visible on the block chain.
    • +
  • 🔒 = Requires either an interactive payment disclosure, or a non-interactive payment disclosure that reveals the sender's address.
    • +
+

Enabling proof-of-payment for all of these transaction variants (where it is possible to do so) is the subject of this ZIP.

+
+

Use cases

+

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:

+
    +
  • 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.
    • +
+
+

System Message: WARNING/2 (zip-0311.rst line 75)

+

Bullet list ends without a blank line; unexpected unindent.

+
+

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 Sapling 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 Sapling 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 Sapling 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.
    • +
+
+
+

Requirements

+
    +
  • The payment disclosure may disclose the contents of zero or more Sapling outputs within a single transaction. (Zero outputs is useful for z2t transactions.)
    • +
  • Payment disclosures can only be created by a sender of the transaction, and are non-malleable (that is, no-one else can take one or more payment disclosures and construct a new one that they would not have been able to make independently).
    • +
  • A payment disclosure may be tied to a challenge, creating an interactive proof.
    • +
  • Senders with a Sapling address may choose to provably reveal that address as part of the payment disclosure.
    • +
  • 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. (Performance may be improved if they do cache witness data for spent notes.)
    • +
+
+

Conventions

+

The following functions used in this ZIP are defined in the Zcash protocol specification: 3

+
    +
  • + \(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\) + , + \(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\) + , and + \(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\) + 7
    • +
+

We reproduce some notation and functions from 3 here for convenience:

+
    +
  • + \([k] P\) + means scalar multiplication of the elliptic curve point + \(P\) + by the scalar + \(k\) + .
    • +
  • + \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\) + refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string + \(p\) + , and input + \(x\) + .
    • +
+

We also define the following notation here:

+
    +
  • + \([a..b]\) + means the sequence of values inclusive of + \(a\) + and exclusive of + \(b\) + .
    • +
  • + \(a\text{.len}()\) + means the length of the vector + \(a\) + .
    • +
+
+

Specification

+

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{saplingOutputs}\) + : A vector of the Sapling Outputs that we are disclosing [0..tx.shieldedOutputs.len()] +
      +
    • + \(\mathsf{index}\) + : An index into tx.shieldedOutputs.
      • +
    • + \(\mathsf{ock}\) + : The outgoing cipher key that allows this output to be recovered. 5
      • +
    +
    • +
  • + \(\mathsf{saplingSpends}\) + : A vector of the Sapling Spends for which we are proving spend authority [0..tx.shieldedSpends.len()] +
      +
    • + \(\mathsf{index}\) + : An index into 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}] GH(\mathsf{d})\) +
        • +
      • + \(\mathsf{nullifier_{addr}}\) + : A nullifier for a ZIP 304 fake note. 10
        • +
      • + \(\mathsf{zkproof_{addr}}\) + : A Sapling spend proof.
        • +
      +
      • +
    • + \(\mathsf{spendAuthSig}\) +
      • +
    +
    • +
  • + \(\mathsf{transparentInputs}\) + : A vector of the transparent inputs for which we are proving spend authority [0..tx.vin.len()] +
      +
    • + \(\mathsf{index}\) + : An index into tx.vin.
      • +
    • + \(\mathsf{sig}\) + : A BIP 322 signature. 8 +
        +
      • 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).
        • +
      +
      • +
    +
    • +
+

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 9 coin type.
    • +
  • The message + \(msg\) + to be included (which may be empty).
    • +
  • A vector of + \((\mathsf{outputIndex}, \mathsf{ock})\) + tuples (which may be empty).
    • +
  • A vector 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 vector of transparent input tuples (which may be empty) containing: +
      +
    • + \(\mathsf{index}\) + : An index into 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, 10 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}()\) +
      • +
    • Vector length correctness: +
        +
      • + \(\mathsf{pd.saplingOutputs.len}() \leq \mathsf{tx.shieldedOutputs.len}()\) +
        • +
      • + \(\mathsf{pd.saplingSpends.len}() \leq \mathsf{tx.shieldedSpends.len}()\) +
        • +
      • + \(\mathsf{pd.transparentInputs.len}() \leq \mathsf{tx.vin.len}()\) +
        • +
      +
      • +
    • 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{tx.shieldedOutputs.len}()\) +
        • +
      • For every + \(\mathsf{spend}\) + in + \(\mathsf{pd.saplingSpends}\) + , + \(\mathsf{spend.index} < \mathsf{tx.shieldedSpends.len}()\) +
        • +
      • For every + \(\mathsf{input}\) + in + \(\mathsf{pd.transparentInputs}\) + , + \(\mathsf{input.index} < \mathsf{tx.vin.len}()\) +
        • +
      +
      • +
    • + \(\mathsf{pd.saplingSpends.len}() + \mathsf{pd.transparentInputs.len}() > 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})\) + 10. 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.
    • +
+
+
+

Rationale

+

If a sender elects, at transaction creation time, to use an + \(\mathsf{ovk}\) + of + \(\bot\) + for a specific Sapling output, then they are unable to subsequently create a payment disclosure that discloses that output. This maintains the semantics of + \(\mathsf{ovk}\) + , in that the sender explicitly chose to lose the capability to recover that output.

+

Payment disclosures that prove Sapling spend authority are not required to reveal a sender address. This is because it is impossible: we can "prove" the transaction came from any of the diversified addresses linked to the spending key. Fundamentally, the "sender" of a transaction is anyone who has access to the corresponding spend authority; in the case of Sapling, a spend authority corresponds to multiple diversified addresses. In situations where a sender address is already known to the verifier of the payment disclosure (or publically), it may still be useful to have the option of linking the payment disclosure to that address.

+
+

Security and Privacy Considerations

+

When spending Sapling notes normally in transactions, wallets select a recent anchor to make the anonymity set of the spent note as large as possible. By contrast, Sapling spend authority in a payment disclosure is proven using the same anchor that was used in the transaction itself, instead of a recent anchor. We do this for efficency reasons:

+
    +
  • The anchor is already encoded in the transaction, so can be omitted from the payment disclosure encoding.
    • +
  • It is necessary to have a witness for each spent note that is being included in the payment disclosure. Using the same anchor means that the same witness can be used for the transaction spend and the payment disclosure, which in turn means that wallets that support payment disclosures only need to remember that witness, and do not need to continually update witnesses for spent notes in the off-chance that they might be used in a payment disclosure.
    • +
+

There is no privacy benefit to selecting a more recent anchor; the anonymity set of the note was "fixed" by the original spend (which revealed that the note existed as of that anchor's height).

+

We require all payment disclosures to prove spend authority for at least one input, in order to simplify the verification UX. In particular, if payment disclosures without spends were considered valid, an invalid payment disclosure with invalid signatures (that would be shown as invalid by UIs) could be mutated into a payment disclosure that would be shown as valid by UIs, by stripping off the signatures. We do not believe that this prevents any useful use cases; meanwhile if someone is intent on obtaining Sapling output disclosures regardless of the validity of their source, they will do so without a common standard.

+
+

Reference implementation

+

TBD

+
+

References

+ + + + + + + +
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2RFC 4648: The Base16, Base32, and Base64 Data Encodings
+ + + + + + + +
3Zcash Protocol Specification, Version 2020.1.15 or later
+ + + + + + + +
4Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling)
+ + + + + + + +
5Zcash Protocol Specification, Version 2020.1.15. 4.17.1: Encryption (Sapling)
+ + + + + + + +
6Zcash Protocol Specification, Version 2020.1.15. 4.17.3: Decryption using a Full Viewing Key (Sapling)
+ + + + + + + +
7Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature
+ + + + + + + +
8BIP 322: Generic Signed Message Format
+ + + + + + + +
9SLIP-0044 : Registered coin types for BIP-0044
+ + + + + + + +
10ZIP 304: Sapling Address Signatures
+
\ No newline at end of file From fa4b1ddcf09174c49c21e42a298ec97d63886c5e Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 25 Jan 2021 11:04:26 +0000 Subject: [PATCH 05/14] ZIP 311: Use length(a) instead of a.len() --- zip-0311.html | 41 ++++++++++++++++++++++++++--------------- zip-0311.rst | 30 +++++++++++++++--------------- 2 files changed, 41 insertions(+), 30 deletions(-) diff --git a/zip-0311.html b/zip-0311.html index 6ae8faba3..4fd5b260f 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -175,7 +175,7 @@

System Message: WARNING/2 (zip-0311.rst line 75)

\(b\) .
  • - \(a\text{.len}()\) + \(\mathsf{length}(a)\) means the length of the vector \(a\) .
    • @@ -189,11 +189,14 @@

    System Message: WARNING/2 (zip-0311.rst line 75)

  • msg: A message field, which could contain a challenge value from the party to whom the payment disclosure is directed.
  • \(\mathsf{saplingOutputs}\) - : A vector of the Sapling Outputs that we are disclosing [0..tx.shieldedOutputs.len()] + : A vector of the Sapling Outputs that we are disclosing + \([0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]\)
    • \(\mathsf{index}\) - : An index into tx.shieldedOutputs.
      • + : An index into + \(\mathsf{tx.shieldedOutputs}\) + .
    • \(\mathsf{ock}\) : The outgoing cipher key that allows this output to be recovered. 5
      • @@ -201,11 +204,14 @@

      System Message: WARNING/2 (zip-0311.rst line 75)

    • \(\mathsf{saplingSpends}\) - : A vector of the Sapling Spends for which we are proving spend authority [0..tx.shieldedSpends.len()] + : A vector of the Sapling Spends for which we are proving spend authority + \([0..\mathsf{length}(\mathsf{tx.shieldedSpends})]\)
      • \(\mathsf{index}\) - : An index into tx.shieldedSpends.
        • + : An index into + \(\mathsf{tx.shieldedSpends}\) + .
      • \(\mathsf{cv}\) : A value commitment to the spent note.
        • @@ -237,11 +243,14 @@

        System Message: WARNING/2 (zip-0311.rst line 75)

      • \(\mathsf{transparentInputs}\) - : A vector of the transparent inputs for which we are proving spend authority [0..tx.vin.len()] + : A vector of the transparent inputs for which we are proving spend authority + \([0..\mathsf{length}(\mathsf{tx.vin})]\)
        • \(\mathsf{index}\) - : An index into tx.vin.
          • + : An index into + \(\mathsf{tx.vin}\) + .
        • \(\mathsf{sig}\) : A BIP 322 signature. 8 @@ -282,7 +291,9 @@

          System Message: WARNING/2 (zip-0311.rst line 75)

          • \(\mathsf{index}\) - : An index into tx.vin.
            • + : An index into + \(\mathsf{tx.vin}\) + .
          • The inputs to a BIP 322 signature (excluding message_data).
          • @@ -357,13 +368,13 @@

          System Message: WARNING/2 (zip-0311.rst line 75)

        • Vector length correctness:
          • - \(\mathsf{pd.saplingOutputs.len}() \leq \mathsf{tx.shieldedOutputs.len}()\) + \(\mathsf{length}(\mathsf{pd.saplingOutputs}) \leq \mathsf{length}(\mathsf{tx.shieldedOutputs})\)
          • - \(\mathsf{pd.saplingSpends.len}() \leq \mathsf{tx.shieldedSpends.len}()\) + \(\mathsf{length}(\mathsf{pd.saplingSpends}) \leq \mathsf{length}(\mathsf{tx.shieldedSpends})\)
          • - \(\mathsf{pd.transparentInputs.len}() \leq \mathsf{tx.vin.len}()\) + \(\mathsf{length}(\mathsf{pd.transparentInputs}) \leq \mathsf{length}(\mathsf{tx.vin})\)
          • @@ -399,26 +410,26 @@

          System Message: WARNING/2 (zip-0311.rst line 75)

          in \(\mathsf{pd.saplingOutputs}\) , - \(\mathsf{output.index} < \mathsf{tx.shieldedOutputs.len}()\) + \(\mathsf{output.index} < \mathsf{length}(\mathsf{tx.shieldedOutputs})\)
        • For every \(\mathsf{spend}\) in \(\mathsf{pd.saplingSpends}\) , - \(\mathsf{spend.index} < \mathsf{tx.shieldedSpends.len}()\) + \(\mathsf{spend.index} < \mathsf{length}(\mathsf{tx.shieldedSpends})\)
        • For every \(\mathsf{input}\) in \(\mathsf{pd.transparentInputs}\) , - \(\mathsf{input.index} < \mathsf{tx.vin.len}()\) + \(\mathsf{input.index} < \mathsf{length}(\mathsf{tx.vin})\)
      • - \(\mathsf{pd.saplingSpends.len}() + \mathsf{pd.transparentInputs.len}() > 0\) + \(\mathsf{length}(\mathsf{pd.saplingSpends}) + \mathsf{length}(\mathsf{pd.transparentInputs}) > 0\)
      • diff --git a/zip-0311.rst b/zip-0311.rst index ddc157291..6ff6e103e 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -160,7 +160,7 @@ We also define the following notation here: - :math:`[a..b]` means the sequence of values inclusive of :math:`a` and exclusive of :math:`b`. -- :math:`a\text{.len}()` means the length of the vector :math:`a`. +- :math:`\mathsf{length}(a)` means the length of the vector :math:`a`. Specification @@ -177,16 +177,16 @@ A payment disclosure has the following fields: the payment disclosure is directed. - :math:`\mathsf{saplingOutputs}`: A vector of the Sapling Outputs that we are disclosing - [0..tx.shieldedOutputs.len()] + :math:`[0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]` - - :math:`\mathsf{index}`: An index into `tx.shieldedOutputs`. + - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedOutputs}`. - :math:`\mathsf{ock}`: The outgoing cipher key that allows this output to be recovered. [#protocol-saplingencrypt]_ - :math:`\mathsf{saplingSpends}`: A vector of the Sapling Spends for which we are proving - spend authority [0..tx.shieldedSpends.len()] + spend authority :math:`[0..\mathsf{length}(\mathsf{tx.shieldedSpends})]` - - :math:`\mathsf{index}`: An index into `tx.shieldedSpends`. + - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedSpends}`. - :math:`\mathsf{cv}`: A value commitment to the spent note. - :math:`\mathsf{rk}`: A randomized public key linked to the spent note. - :math:`\mathsf{zkproof_{spend}}`: A Sapling spend proof. @@ -199,9 +199,9 @@ A payment disclosure has the following fields: - :math:`\mathsf{spendAuthSig}` - :math:`\mathsf{transparentInputs}`: A vector of the transparent inputs for which we are - proving spend authority [0..tx.vin.len()] + proving spend authority :math:`[0..\mathsf{length}(\mathsf{tx.vin})]` - - :math:`\mathsf{index}`: An index into `tx.vin`. + - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.vin}`. - :math:`\mathsf{sig}`: A BIP 322 signature. [#bip-0322]_ - TODO: `zcashd` currently only supports the legacy format defined in BIP 322. We may @@ -232,7 +232,7 @@ The inputs to a payment disclosure are: - A vector of transparent input tuples (which may be empty) containing: - - :math:`\mathsf{index}`: An index into `tx.vin`. + - :math:`\mathsf{index}`: An index into :math:`\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 @@ -291,9 +291,9 @@ by the caller), the verifier proceeds as follows: - Vector length correctness: - - :math:`\mathsf{pd.saplingOutputs.len}() \leq \mathsf{tx.shieldedOutputs.len}()` - - :math:`\mathsf{pd.saplingSpends.len}() \leq \mathsf{tx.shieldedSpends.len}()` - - :math:`\mathsf{pd.transparentInputs.len}() \leq \mathsf{tx.vin.len}()` + - :math:`\mathsf{length}(\mathsf{pd.saplingOutputs}) \leq \mathsf{length}(\mathsf{tx.shieldedOutputs})` + - :math:`\mathsf{length}(\mathsf{pd.saplingSpends}) \leq \mathsf{length}(\mathsf{tx.shieldedSpends})` + - :math:`\mathsf{length}(\mathsf{pd.transparentInputs}) \leq \mathsf{length}(\mathsf{tx.vin})` - Index uniqueness: @@ -307,13 +307,13 @@ by the caller), the verifier proceeds as follows: - Index correctness: - For every :math:`\mathsf{output}` in :math:`\mathsf{pd.saplingOutputs}`, - :math:`\mathsf{output.index} < \mathsf{tx.shieldedOutputs.len}()` + :math:`\mathsf{output.index} < \mathsf{length}(\mathsf{tx.shieldedOutputs})` - For every :math:`\mathsf{spend}` in :math:`\mathsf{pd.saplingSpends}`, - :math:`\mathsf{spend.index} < \mathsf{tx.shieldedSpends.len}()` + :math:`\mathsf{spend.index} < \mathsf{length}(\mathsf{tx.shieldedSpends})` - For every :math:`\mathsf{input}` in :math:`\mathsf{pd.transparentInputs}`, - :math:`\mathsf{input.index} < \mathsf{tx.vin.len}()` + :math:`\mathsf{input.index} < \mathsf{length}(\mathsf{tx.vin})` - - :math:`\mathsf{pd.saplingSpends.len}() + \mathsf{pd.transparentInputs.len}() > 0` + - :math:`\mathsf{length}(\mathsf{pd.saplingSpends}) + \mathsf{length}(\mathsf{pd.transparentInputs}) > 0` - Let :math:`unsignedPaymentDisclosure` be the encoding of the payment disclosure without signatures. From ff6a98ff652d73ffe597331ea7ba1572520272db Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 25 Jan 2021 11:05:16 +0000 Subject: [PATCH 06/14] ZIP 311: Replace "vector" with "sequence" --- zip-0311.html | 16 ++++++++-------- zip-0311.rst | 16 ++++++++-------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/zip-0311.html b/zip-0311.html index 4fd5b260f..0564e2e53 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -176,7 +176,7 @@

      System Message: WARNING/2 (zip-0311.rst line 75)

      .
    • \(\mathsf{length}(a)\) - means the length of the vector + means the length of the sequence \(a\) .
    @@ -189,7 +189,7 @@

    System Message: WARNING/2 (zip-0311.rst line 75)

  • msg: A message field, which could contain a challenge value from the party to whom the payment disclosure is directed.
  • \(\mathsf{saplingOutputs}\) - : A vector of the Sapling Outputs that we are disclosing + : A sequence of the Sapling Outputs that we are disclosing \([0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]\)
    • @@ -204,7 +204,7 @@

      System Message: WARNING/2 (zip-0311.rst line 75)

    • \(\mathsf{saplingSpends}\) - : A vector of the Sapling Spends for which we are proving spend authority + : A sequence of the Sapling Spends for which we are proving spend authority \([0..\mathsf{length}(\mathsf{tx.shieldedSpends})]\)
      • @@ -243,7 +243,7 @@

        System Message: WARNING/2 (zip-0311.rst line 75)

      • \(\mathsf{transparentInputs}\) - : A vector of the transparent inputs for which we are proving spend authority + : A sequence of the transparent inputs for which we are proving spend authority \([0..\mathsf{length}(\mathsf{tx.vin})]\)
        • @@ -273,10 +273,10 @@

          System Message: WARNING/2 (zip-0311.rst line 75)

        • The message \(msg\) to be included (which may be empty).
          • -
        • A vector of +
        • A sequence of \((\mathsf{outputIndex}, \mathsf{ock})\) tuples (which may be empty).
          • -
        • A vector of Sapling spend tuples (which may be empty) containing: +
        • A sequence of Sapling spend tuples (which may be empty) containing:
          • A Sapling spend index.
          • Its corresponding expanded spending key @@ -287,7 +287,7 @@

            System Message: WARNING/2 (zip-0311.rst line 75)

            .
          • -
        • A vector of transparent input tuples (which may be empty) containing: +
        • A sequence of transparent input tuples (which may be empty) containing:
          • \(\mathsf{index}\) @@ -365,7 +365,7 @@

            System Message: WARNING/2 (zip-0311.rst line 75)

          • \(\mathsf{pd.txid} = \mathsf{tx.txid}()\)
            • -
          • Vector length correctness: +
          • Sequence length correctness:
            • \(\mathsf{length}(\mathsf{pd.saplingOutputs}) \leq \mathsf{length}(\mathsf{tx.shieldedOutputs})\) diff --git a/zip-0311.rst b/zip-0311.rst index 6ff6e103e..2ede2aa5b 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -160,7 +160,7 @@ We also define the following notation here: - :math:`[a..b]` means the sequence of values inclusive of :math:`a` and exclusive of :math:`b`. -- :math:`\mathsf{length}(a)` means the length of the vector :math:`a`. +- :math:`\mathsf{length}(a)` means the length of the sequence :math:`a`. Specification @@ -176,14 +176,14 @@ A payment disclosure has the following fields: - `msg`: A message field, which could contain a challenge value from the party to whom the payment disclosure is directed. -- :math:`\mathsf{saplingOutputs}`: A vector of the Sapling Outputs that we are disclosing +- :math:`\mathsf{saplingOutputs}`: A sequence of the Sapling Outputs that we are disclosing :math:`[0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]` - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedOutputs}`. - :math:`\mathsf{ock}`: The outgoing cipher key that allows this output to be recovered. [#protocol-saplingencrypt]_ -- :math:`\mathsf{saplingSpends}`: A vector of the Sapling Spends for which we are proving +- :math:`\mathsf{saplingSpends}`: A sequence of the Sapling Spends for which we are proving spend authority :math:`[0..\mathsf{length}(\mathsf{tx.shieldedSpends})]` - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedSpends}`. @@ -198,7 +198,7 @@ A payment disclosure has the following fields: - :math:`\mathsf{spendAuthSig}` -- :math:`\mathsf{transparentInputs}`: A vector of the transparent inputs for which we are +- :math:`\mathsf{transparentInputs}`: A sequence of the transparent inputs for which we are proving spend authority :math:`[0..\mathsf{length}(\mathsf{tx.vin})]` - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.vin}`. @@ -223,14 +223,14 @@ The inputs to a payment disclosure are: - The transaction. - The SLIP-44 [#slip-0044]_ coin type. - The message :math:`msg` to be included (which may be empty). -- A vector of :math:`(\mathsf{outputIndex}, \mathsf{ock})` tuples (which may be empty). -- A vector of Sapling spend tuples (which may be empty) containing: +- A sequence of :math:`(\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 :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})`. - [Optional] An associated payment address :math:`(\mathsf{d}, \mathsf{pk_d})`. -- A vector of transparent input tuples (which may be empty) containing: +- A sequence of transparent input tuples (which may be empty) containing: - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.vin}`. - The inputs to a BIP 322 signature (excluding `message_data`). @@ -289,7 +289,7 @@ by the caller), the verifier proceeds as follows: - :math:`\mathsf{pd.txid} = \mathsf{tx.txid}()` - - Vector length correctness: + - Sequence length correctness: - :math:`\mathsf{length}(\mathsf{pd.saplingOutputs}) \leq \mathsf{length}(\mathsf{tx.shieldedOutputs})` - :math:`\mathsf{length}(\mathsf{pd.saplingSpends}) \leq \mathsf{length}(\mathsf{tx.shieldedSpends})` From aa83efbbd152b5aa7331d4c620ae9808f419b945 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 25 Jan 2021 11:09:33 +0000 Subject: [PATCH 07/14] ZIP 311: Use DiversifyHash from the spec in place of GH --- zip-0311.html | 41 ++++++++++++++++++++++++++--------------- zip-0311.rst | 6 +++++- 2 files changed, 31 insertions(+), 16 deletions(-) diff --git a/zip-0311.html b/zip-0311.html index 0564e2e53..3d8e4b404 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -140,15 +140,18 @@

              System Message: WARNING/2 (zip-0311.rst line 75)

              Conventions

              The following functions used in this ZIP are defined in the Zcash protocol specification: 3

                +
              • + \(\mathsf{DiversifyHash}(\mathsf{d})\) + 7
              • \(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\) , \(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\) , and \(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\) - 7
                • + 8
              -

              We reproduce some notation and functions from 3 here for convenience:

              +

              We reproduce some notation and functions from 3 here for convenience:

              • \([k] P\) @@ -199,7 +202,7 @@

                System Message: WARNING/2 (zip-0311.rst line 75)

                .
              • \(\mathsf{ock}\) - : The outgoing cipher key that allows this output to be recovered. 5
                • + : The outgoing cipher key that allows this output to be recovered. 5
            • @@ -226,11 +229,11 @@

              System Message: WARNING/2 (zip-0311.rst line 75)

            • Any \((\mathsf{d, pk_d})\) such that - \(\mathsf{pk_d} = [\mathsf{ivk}] GH(\mathsf{d})\) + \(\mathsf{pk_d} = [\mathsf{ivk}] \mathsf{DiversifyHash}(\mathsf{d})\)
            • \(\mathsf{nullifier_{addr}}\) - : A nullifier for a ZIP 304 fake note. 10
              • + : A nullifier for a ZIP 304 fake note. 11
            • \(\mathsf{zkproof_{addr}}\) : A Sapling spend proof.
              • @@ -253,7 +256,7 @@

              System Message: WARNING/2 (zip-0311.rst line 75)

              .
            • \(\mathsf{sig}\) - : A BIP 322 signature. 8 + : 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).
                • @@ -269,7 +272,7 @@

                System Message: WARNING/2 (zip-0311.rst line 75)

                The inputs to a payment disclosure are:

                • The transaction.
                  • -
                • The SLIP-44 9 coin type.
                  • +
                • The SLIP-44 10 coin type.
                • The message \(msg\) to be included (which may be empty).
                  • @@ -310,7 +313,7 @@

                  System Message: WARNING/2 (zip-0311.rst line 75)

                  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, 10 using +
                • [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}\) @@ -459,10 +462,10 @@

                  System Message: WARNING/2 (zip-0311.rst line 75)

                  \((\mathsf{addrProof.nullifier_{addr}}, \mathsf{spend.rk}, \mathsf{addrProof.zkproof_{addr}})\) as a ZIP 304 proof for \((\mathsf{addrProof.d}, \mathsf{addrProof.pk_d})\) - 10. If verification fails, return false.
                  • + 11. If verification fails, return false.
                • Decode and verify \(\mathsf{zkproof_{spend}}\) - as a Sapling spend proof 4 with primary input: + as a Sapling spend proof 4 with primary input:
                  • \(\mathsf{tx.shieldedSpends[spend.index].rt}\) @@ -498,7 +501,7 @@

                    System Message: WARNING/2 (zip-0311.rst line 75)

                    • Recover the Sapling note in \(\mathsf{tx.shieldedOutputs}[\mathsf{output.index}]\) - via the process specified in 6 with inputs + via the process specified in 6 with inputs \((height, \mathsf{output.ock})\) . If recovery returns \(\bot\) @@ -589,10 +592,18 @@

                      System Message: WARNING/2 (zip-0311.rst line 75)

                      - +
                      + + + +
                      7Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function
                      + + + + @@ -600,7 +611,7 @@

                      System Message: WARNING/2 (zip-0311.rst line 75)

                      8 Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature
                      - + @@ -608,7 +619,7 @@

                      System Message: WARNING/2 (zip-0311.rst line 75)

                      89 BIP 322: Generic Signed Message Format
                      - + @@ -616,7 +627,7 @@

                      System Message: WARNING/2 (zip-0311.rst line 75)

                      910 SLIP-0044 : Registered coin types for BIP-0044
                      - + diff --git a/zip-0311.rst b/zip-0311.rst index 2ede2aa5b..efd8b0d94 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -142,6 +142,8 @@ Conventions The following functions used in this ZIP are defined in the Zcash protocol specification: [#protocol]_ +- :math:`\mathsf{DiversifyHash}(\mathsf{d})` [#protocol-concretediversifyhash]_ + - :math:`\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})`, :math:`\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)`, and :math:`\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)` [#protocol-concretespendauthsig]_ @@ -192,7 +194,8 @@ A payment disclosure has the following fields: - :math:`\mathsf{zkproof_{spend}}`: A Sapling spend proof. - [Optional] A payment address proof `addr_proof`: - - Any :math:`(\mathsf{d, pk_d})` such that :math:`\mathsf{pk_d} = [\mathsf{ivk}] GH(\mathsf{d})` + - Any :math:`(\mathsf{d, pk_d})` such that + :math:`\mathsf{pk_d} = [\mathsf{ivk}] \mathsf{DiversifyHash}(\mathsf{d})` - :math:`\mathsf{nullifier_{addr}}`: A nullifier for a ZIP 304 fake note. [#zip-0304]_ - :math:`\mathsf{zkproof_{addr}}`: A Sapling spend proof. @@ -431,6 +434,7 @@ References .. [#protocol-spendstatement] `Zcash Protocol Specification, Version 2020.1.15. Section 4.15.2: Spend Statement (Sapling) `_ .. [#protocol-saplingencrypt] `Zcash Protocol Specification, Version 2020.1.15. 4.17.1: Encryption (Sapling) `_ .. [#protocol-saplingdecryptovk] `Zcash Protocol Specification, Version 2020.1.15. 4.17.3: Decryption using a Full Viewing Key (Sapling) `_ +.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.1.6: DiversifyHash Hash Function `_ .. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.6.1: Spend Authorization Signature `_ .. [#bip-0322] `BIP 322: Generic Signed Message Format `_ .. [#slip-0044] `SLIP-0044 : Registered coin types for BIP-0044 `_ From 05e9a86e332abf00d0e48a699838a0c2d319c152 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 25 Jan 2021 11:11:03 +0000 Subject: [PATCH 08/14] ZIP 311: Minor edits from PR comments --- zip-0311.html | 4 ++-- zip-0311.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0311.html b/zip-0311.html index 3d8e4b404..2339ac147 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -22,7 +22,7 @@
                    • A sender may need to prove that their payment was sent to a recipient, and available to be received (following the Zcash protocol in-band).
                    • A third party may need to verify that a payment between a given sender and recipient was executed successfully.
                      • -

                      When a transaction involves only transparent addresses, proof-of-payment is simple: The sender provides the transaction ID, and the recipent examines the blockchain to confirm that the transaction was mined. A third party can also perform this verification if they know the transparent addresses of the involved parties.

                      +

                      When a transaction involves only transparent addresses, proof-of-payment is simple: The sender provides the transaction ID, and the recipient examines the blockchain to confirm that the transaction was mined. A third party can also perform this verification if they know the transparent addresses of the involved parties.

                      However, if the transaction involves shielded addresses, the blockchain by itself does not contain enough information to allow a record of the payment to be reconstructed and verified:

                      1011 ZIP 304: Sapling Address Signatures
                      @@ -79,7 +79,7 @@

                      Use cases

                      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:

                      +

                      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).
                        • diff --git a/zip-0311.rst b/zip-0311.rst index efd8b0d94..a291928bf 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -27,7 +27,7 @@ There are various situations where a proof-of-payment may be desired. For exampl executed successfully. When a transaction involves only transparent addresses, proof-of-payment is simple: The -sender provides the transaction ID, and the recipent examines the blockchain to confirm +sender provides the transaction ID, and the recipient examines the blockchain to confirm that the transaction was mined. A third party can also perform this verification if they know the transparent addresses of the involved parties. @@ -61,7 +61,7 @@ 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: +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 From 97d23d656bbfd8a9428e54616fd1b5129d993274 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 23 Feb 2021 13:35:07 +1300 Subject: [PATCH 09/14] ZIP 311: Clarify that t->z reveals some amount information But not enough to confirm the amount paid (due to change). Co-authored-by: Daira Hopwood --- zip-0311.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/zip-0311.rst b/zip-0311.rst index a291928bf..650305770 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -38,14 +38,15 @@ verified: =========== =========== ====== ========= ====== ================== Source Destination Sender Recipient Amount Payment dislosure? =========== =========== ====== ========= ====== ================== -Transparent Transparent 🔍 🔍 🔍 Not required -Transparent Shielded 🔍 🔐 🔐 Required -Shielded Transparent 🔒 🔍 🔍 Required -Shielded Shielded 🔒 🔐 🔐 Required +Transparent Transparent 🔍 🔍 🔍 Not required +Transparent Shielded 🔍 🔐 🔐* Required +Shielded Transparent 🔒 🔍 🔍 Required +Shielded Shielded 🔒 🔐 🔐 Required =========== =========== ====== ========= ====== ================== - 🔍 = Visible on the block chain. - 🔐 = Cannot be confirmed without information that is not visible on the block chain. +- 🔐* = Information is revealed, but not enough to confirm the amount paid (due to change). - 🔒 = Requires either an interactive payment disclosure, or a non-interactive payment disclosure that reveals the sender's address. From e512fa78ad7f50d8c3bd6ceb8dcd4f336780bf67 Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 3 Nov 2022 09:47:18 +0000 Subject: [PATCH 10/14] ZIP 311: Generalise beyond Sapling Applies comments from the last ZIP Sync this was reviewed in. --- zip-0311.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zip-0311.rst b/zip-0311.rst index 650305770..725f74d48 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -1,7 +1,7 @@ :: ZIP: 311 - Title: Sapling Payment Disclosure + Title: Zcash Payment Disclosures Owners: Jack Grigg Status: Draft Category: Standards / RPC / Wallet @@ -135,6 +135,7 @@ Requirements - 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. (Performance may be improved if they do cache witness data for spent notes.) +- The payment disclosure can be created without requiring another trusted setup. Conventions From 396900a9e6b6fc96f8cc5e0d7f7e48d3e2f4687d Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 3 Nov 2022 23:52:47 +1300 Subject: [PATCH 11/14] ZIP 311: Fix formatting error and regenerate HTML --- README.rst | 2 +- index.html | 2 +- zip-0311.html | 36 +++++++++++++++++------------------- zip-0311.rst | 5 +++-- 4 files changed, 22 insertions(+), 23 deletions(-) diff --git a/README.rst b/README.rst index 99d0b7046..de520ebf2 100644 --- a/README.rst +++ b/README.rst @@ -112,7 +112,7 @@ Index of ZIPs
                      - + diff --git a/index.html b/index.html index b34100e7e..970f3d200 100644 --- a/index.html +++ b/index.html @@ -85,7 +85,7 @@ - + diff --git a/zip-0311.html b/zip-0311.html index 2339ac147..049f9b821 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -1,14 +1,14 @@ - ZIP 311: Sapling Payment Disclosure + ZIP 311: Zcash Payment Disclosures
                      ZIP: 311
-Title: Sapling Payment Disclosure
+Title: Zcash Payment Disclosures
 Owners: Jack Grigg <jack@electriccoin.co>
 Status: Draft
 Category: Standards / RPC / Wallet
@@ -49,7 +49,7 @@
                      - + @@ -73,6 +73,7 @@
                      • 🔍 = Visible on the block chain.
                      • 🔐 = Cannot be confirmed without information that is not visible on the block chain.
                        • +
                      • 🔐* = Information is revealed, but not enough to confirm the amount paid (due to change).
                      • 🔒 = Requires either an interactive payment disclosure, or a non-interactive payment disclosure that reveals the sender's address.

                      Enabling proof-of-payment for all of these transaction variants (where it is possible to do so) is the subject of this ZIP.

                      @@ -90,10 +91,6 @@
                    • Any of Carol's other diversified payment addresses.
                    • Any of Carol's other transactions.
                      • -
                      -

                      System Message: WARNING/2 (zip-0311.rst line 75)

                      -

                      Bullet list ends without a blank line; unexpected unindent.

                      -

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

                      Donation drive

                      @@ -135,23 +132,24 @@

                      System Message: WARNING/2 (zip-0311.rst line 75)

                    • A payment disclosure may be tied to a challenge, creating an interactive proof.
                    • Senders with a Sapling address may choose to provably reveal that address as part of the payment disclosure.
                    • 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. (Performance may be improved if they do cache witness data for spent notes.)
                      • +
                    • The payment disclosure can be created without requiring another trusted setup.

                      • Conventions

                      -

                      The following functions used in this ZIP are defined in the Zcash protocol specification: 3

                      +

                      The following functions used in this ZIP are defined in the Zcash protocol specification: 3

                      • \(\mathsf{DiversifyHash}(\mathsf{d})\) - 7
                        • + 7
                      • \(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\) , \(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\) , and \(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\) - 8
                        • + 8
                      -

                      We reproduce some notation and functions from 3 here for convenience:

                      +

                      We reproduce some notation and functions from 3 here for convenience:

                      • \([k] P\) @@ -202,7 +200,7 @@

                        System Message: WARNING/2 (zip-0311.rst line 75)

                        .
                      • \(\mathsf{ock}\) - : The outgoing cipher key that allows this output to be recovered. 5
                        • + : The outgoing cipher key that allows this output to be recovered. 5
                    • @@ -233,7 +231,7 @@

                      System Message: WARNING/2 (zip-0311.rst line 75)

                    • \(\mathsf{nullifier_{addr}}\) - : A nullifier for a ZIP 304 fake note. 11
                      • + : A nullifier for a ZIP 304 fake note. 11
                    • \(\mathsf{zkproof_{addr}}\) : A Sapling spend proof.
                      • @@ -256,7 +254,7 @@

                      System Message: WARNING/2 (zip-0311.rst line 75)

                      .
                    • \(\mathsf{sig}\) - : A BIP 322 signature. 9 + : 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).
                        • @@ -272,7 +270,7 @@

                        System Message: WARNING/2 (zip-0311.rst line 75)

                        The inputs to a payment disclosure are:

                        • The transaction.
                          • -
                        • The SLIP-44 10 coin type.
                          • +
                        • The SLIP-44 10 coin type.
                        • The message \(msg\) to be included (which may be empty).
                          • @@ -313,7 +311,7 @@

                          System Message: WARNING/2 (zip-0311.rst line 75)

                          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 +
                        • [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}\) @@ -462,10 +460,10 @@

                          System Message: WARNING/2 (zip-0311.rst line 75)

                          \((\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.
                          • + 11. If verification fails, return false.
                        • Decode and verify \(\mathsf{zkproof_{spend}}\) - as a Sapling spend proof 4 with primary input: + as a Sapling spend proof 4 with primary input:
                          • \(\mathsf{tx.shieldedSpends[spend.index].rt}\) @@ -501,7 +499,7 @@

                            System Message: WARNING/2 (zip-0311.rst line 75)

                            • Recover the Sapling note in \(\mathsf{tx.shieldedOutputs}[\mathsf{output.index}]\) - via the process specified in 6 with inputs + via the process specified in 6 with inputs \((height, \mathsf{output.ock})\) . If recovery returns \(\bot\) diff --git a/zip-0311.rst b/zip-0311.rst index 725f74d48..a8ad8ebfe 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -73,8 +73,9 @@ 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. + +For this use case, it is not necessary (and not necessarily intended) that the payment +disclosure be publically verifiable. Donation drive -------------- From 10152374d86431f4ade8898e58ea9385e5916f1f Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Fri, 4 Nov 2022 17:36:42 +1300 Subject: [PATCH 12/14] ZIP 311: Generalise abstract, use cases, and requirements beyond Sapling --- zip-0311.html | 12 ++++++------ zip-0311.rst | 14 +++++++------- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/zip-0311.html b/zip-0311.html index 049f9b821..e2e62e045 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -14,7 +14,7 @@ Category: Standards / RPC / Wallet Discussions-To: <https://github.com/zcash/zips/issues/387>

                              Abstract

                              -

                              This ZIP describes a mechanism and format for disclosing information about Sapling spends and outputs within a transaction. In the typical case, this means enabling a sender to present a proof that they transferred funds to a recipient's Sapling address.

                              +

                              This ZIP describes a mechanism and format for disclosing information about shielded spends and outputs within a transaction. In the typical case, this means enabling a sender to present a proof that they transferred funds to a recipient's shielded address.

                              Motivation

                              There are various situations where a proof-of-payment may be desired. For example:

                              @@ -94,7 +94,7 @@

                              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 Sapling 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:

                              +

                              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.
                                • @@ -106,7 +106,7 @@

                              Merchant dispute

                              -

                              Edward goes to CarsRFast to buy a Lamborghini, and sends funds from his Sapling 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 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.
                              @@ -118,7 +118,7 @@

                      • Shielded withdrawals from an exchange

                      -

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

                      +

                      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.
                        • @@ -127,10 +127,10 @@

                      Requirements

                        -
                      • The payment disclosure may disclose the contents of zero or more Sapling outputs within a single transaction. (Zero outputs is useful for z2t transactions.)
                        • +
                      • The payment disclosure may disclose the contents of zero or more shielded outputs within a single transaction. (Zero outputs is useful for z2t transactions.)
                      • Payment disclosures can only be created by a sender of the transaction, and are non-malleable (that is, no-one else can take one or more payment disclosures and construct a new one that they would not have been able to make independently).
                      • A payment disclosure may be tied to a challenge, creating an interactive proof.
                        • -
                      • Senders with a Sapling address may choose to provably reveal that address as part of the payment disclosure.
                        • +
                      • Senders with a shielded address may choose to provably reveal that address as part of the payment disclosure.
                      • 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. (Performance may be improved if they do cache witness data for spent notes.)
                      • The payment disclosure can be created without requiring another trusted setup.
                      diff --git a/zip-0311.rst b/zip-0311.rst index a8ad8ebfe..7736ee4d2 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -11,9 +11,9 @@ Abstract ======== -This ZIP describes a mechanism and format for disclosing information about Sapling spends +This ZIP describes a mechanism and format for disclosing information about shielded spends and outputs within a transaction. In the typical case, this means enabling a sender to -present a proof that they transferred funds to a recipient's Sapling address. +present a proof that they transferred funds to a recipient's shielded address. Motivation @@ -80,7 +80,7 @@ disclosure be publically verifiable. Donation drive -------------- -Diana is a well-known individual with a public Sapling payment address (for receiving +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: @@ -97,7 +97,7 @@ and does not reveal: Merchant dispute ---------------- -Edward goes to CarsRFast to buy a Lamborghini, and sends funds from his Sapling address to +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: @@ -113,7 +113,7 @@ Shielded withdrawals from an exchange ------------------------------------- CorpBux is an exchange with a transparent hot wallet, and enables customers to withdraw -their funds to Sapling addresses. They can create a payment disclosure, that they can give +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 @@ -124,14 +124,14 @@ to their customers, that reveals: Requirements ============ -- The payment disclosure may disclose the contents of zero or more Sapling outputs within +- The payment disclosure may disclose the contents of zero or more shielded outputs within a single transaction. (Zero outputs is useful for z2t transactions.) - Payment disclosures can only be created by a sender of the transaction, and are non-malleable (that is, no-one else can take one or more payment disclosures and construct a new one that they would not have been able to make independently). - A payment disclosure may be tied to a challenge, creating an interactive proof. -- Senders with a Sapling address may choose to provably reveal that address as part of the +- Senders with a shielded address may choose to provably reveal that address as part of the payment disclosure. - 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. (Performance may be From 2f7ccb26bb5373c0bbc16ae0096c3a1fb6ea8a24 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Fri, 4 Nov 2022 17:45:44 +1300 Subject: [PATCH 13/14] ZIP 311: Reorder payment disclosure data structure to match v5 tx --- zip-0311.html | 34 +++++++++++++++++----------------- zip-0311.rst | 32 ++++++++++++++++---------------- 2 files changed, 33 insertions(+), 33 deletions(-) diff --git a/zip-0311.html b/zip-0311.html index e2e62e045..214b55bf2 100644 --- a/zip-0311.html +++ b/zip-0311.html @@ -189,18 +189,23 @@
                    • 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{saplingOutputs}\) - : A sequence of the Sapling Outputs that we are disclosing - \([0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]\) + \(\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.shieldedOutputs}\) + \(\mathsf{tx.vin}\) .
                      • - \(\mathsf{ock}\) - : The outgoing cipher key that allows this output to be recovered. 5
                        • + \(\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).
                          • +
                        +
                    • @@ -243,23 +248,18 @@
                    • - \(\mathsf{transparentInputs}\) - : A sequence of the transparent inputs for which we are proving spend authority - \([0..\mathsf{length}(\mathsf{tx.vin})]\) + \(\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.vin}\) + \(\mathsf{tx.shieldedOutputs}\) .
                      • - \(\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{ock}\) + : The outgoing cipher key that allows this output to be recovered. 5
                      • diff --git a/zip-0311.rst b/zip-0311.rst index 7736ee4d2..115339327 100644 --- a/zip-0311.rst +++ b/zip-0311.rst @@ -181,12 +181,18 @@ A payment disclosure has the following fields: - `msg`: A message field, which could contain a challenge value from the party to whom the payment disclosure is directed. -- :math:`\mathsf{saplingOutputs}`: A sequence of the Sapling Outputs that we are disclosing - :math:`[0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]` +- :math:`\mathsf{transparentInputs}`: A sequence of the transparent inputs for which we are + proving spend authority :math:`[0..\mathsf{length}(\mathsf{tx.vin})]` - - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedOutputs}`. - - :math:`\mathsf{ock}`: The outgoing cipher key that allows this output to be recovered. - [#protocol-saplingencrypt]_ + - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.vin}`. + - :math:`\mathsf{sig}`: A BIP 322 signature. [#bip-0322]_ + + - 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). - :math:`\mathsf{saplingSpends}`: A sequence of the Sapling Spends for which we are proving spend authority :math:`[0..\mathsf{length}(\mathsf{tx.shieldedSpends})]` @@ -204,18 +210,12 @@ A payment disclosure has the following fields: - :math:`\mathsf{spendAuthSig}` -- :math:`\mathsf{transparentInputs}`: A sequence of the transparent inputs for which we are - proving spend authority :math:`[0..\mathsf{length}(\mathsf{tx.vin})]` - - - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.vin}`. - - :math:`\mathsf{sig}`: A BIP 322 signature. [#bip-0322]_ +- :math:`\mathsf{saplingOutputs}`: A sequence of the Sapling Outputs that we are disclosing + :math:`[0..\mathsf{length}(\mathsf{tx.shieldedOutputs})]` - - 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). + - :math:`\mathsf{index}`: An index into :math:`\mathsf{tx.shieldedOutputs}`. + - :math:`\mathsf{ock}`: The outgoing cipher key that allows this output to be recovered. + [#protocol-saplingencrypt]_ TODO: Decide on payment disclosure versioning. From 2479dc18d1ec620e2f1b432e39f7c935c9ec6a7a Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Wed, 17 Jul 2024 02:15:41 +0000 Subject: [PATCH 14/14] ZIP 311: Add TODO for Orchard support --- rendered/zip-0311.html | 1 + zips/zip-0311.rst | 2 ++ 2 files changed, 3 insertions(+) diff --git a/rendered/zip-0311.html b/rendered/zip-0311.html index d39dc10ce..cfec0a94b 100644 --- a/rendered/zip-0311.html +++ b/rendered/zip-0311.html @@ -263,6 +263,7 @@ +

                      TODO: Add support for Orchard.

                      TODO: Decide on payment disclosure versioning.

                      TODO: Define encodings for unsigned and signed payment disclosures.

                      diff --git a/zips/zip-0311.rst b/zips/zip-0311.rst index 115339327..b55b94bac 100644 --- a/zips/zip-0311.rst +++ b/zips/zip-0311.rst @@ -217,6 +217,8 @@ A payment disclosure has the following fields: - :math:`\mathsf{ock}`: The outgoing cipher key that allows this output to be recovered. [#protocol-saplingencrypt]_ +TODO: Add support for Orchard. + TODO: Decide on payment disclosure versioning. TODO: Define encodings for unsigned and signed payment disclosures.
                      308 Sprout to Sapling Migration Final
                      309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
                      310 Security Properties of Sapling Viewing Keys Draft
                      311 Sapling Payment Disclosure Draft
                      311 Zcash Payment Disclosures Draft
                      312 Shielded Multisignatures using FROST Reserved
                      313 Reduce Default Transaction Fee Reserved
                      321 Payment Request URIs Proposed
                      308 Sprout to Sapling Migration Final
                      309 Blind Off-chain Lightweight Transactions (BOLT) Reserved
                      310 Security Properties of Sapling Viewing Keys Draft
                      311 Sapling Payment Disclosure Draft
                      311 Zcash Payment Disclosures Draft
                      312 Shielded Multisignatures using FROST Reserved
                      313 Reduce Default Transaction Fee Reserved
                      321 Payment Request URIs Proposed Shielded 🔍 🔐🔐🔐* Required