From 90ee1395d51d524046a3c35c1a77535a2008e200 Mon Sep 17 00:00:00 2001 From: Antoine Rondelet Date: Sun, 22 Dec 2024 11:02:07 +0100 Subject: [PATCH 1/9] Added first version of approval ZIP --- zips/zip-approval.rst | 230 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 230 insertions(+) create mode 100644 zips/zip-approval.rst diff --git a/zips/zip-approval.rst b/zips/zip-approval.rst new file mode 100644 index 000000000..41c783c5e --- /dev/null +++ b/zips/zip-approval.rst @@ -0,0 +1,230 @@ +:: + + ZIP: TODO: TO BE ASSIGNED + Title: Transaction User Controls + Owners: Pablo Kogan + Antoine Rondelet + Status: Draft + Category: Consensus + Created: 2024-12-22 + License: MIT + Discussions-To: + Pull-Request: + + +Terminology +=========== + +The key word "MUST" in this document is to be interpreted as described in BCP 14 [#BCP14]_ when, and only when, it appears in all capitals. + +The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_. + +The terms "Orchard" and "Action" in this document are to be interpreted as described in ZIP 224 [#zip-0224]_. + +The terms "Asset" and "ZSA" in this document are to be interpreted as described in ZIP 227 [#zip-0227]_. + +Abstract +======== + +This ZIP proposes transaction user controls - a mechanism allowing recipients of shielded funds to actively participate in the transfer of assets by approving or rejecting incoming transactions. + +Motivation +========== + +In the current version of Zcash, fund transfers occur without explicit recipient consent. +While this simplicity offers convenience, it creates significant challenges for users of the network (e.g. individuals or businesses). +The goal of this ZIP is to design a mechanism where the recipient of shielded funds on Zcash (for any type of ZSA) can confirm (or ‘approve’) the receipt of the funds on chain. +This enhancement addresses crucial needs in the Zcash ecosystem, particularly at a time when privacy-preserving assets face increased scrutiny from major exchanges. +The proposed controls offer robust safeguarding solutions while maintaining Zcash’s core privacy features. + +Overview +======== + +Existing Zcash users rely on the notion of "address" to identify each other. +Each Zcash user has one or more address. +When 2 users (a sender and a recipient) want to transact, they first need to "discover each other". +More particularly, the sender of the funds, must get the address of the recipient in order to transfer funds to the counterparty. +This "address discovery" is usually done via off-chain communications (e.g. emails, forum). +By sharing (or not sharing) their payment address, recipients can decide (i.e. 'authorize' or 'not authorize') which other network participants can send them funds on the network. + +In some contexts, individuals and/or organizations may want to publish one of their addresses in order to allow everyone to issue a payment to them (e.g. charities like Turing Trust). +In other cases, Zcash users may want to selectively disclose their payment addresses to only allow incoming payments from a restricted set of users. + +But, relying exclusively on "address discovery" to authorize / not authorize incoming payments has the following limitations: + +- Lack of revocation: Sharing one's payment address only allows the recipient to "grant" the "authority to be paid by a user", but it doesn't allow the recipient to "revoke" this "authority to be paid". This could be an issue if recipients want to authorize the sender to pay them only once. (Generating new addresses is not a clean way to revoke the authorization to pay because the sender can still send funds to the old address, potentially leading to lost funds. More on that below.) +- Loose authorization. Sharing one's address with a sender only allows the recipient to "grant" the "authority to be paid by a user" but it does not constrain the terms of the payment. The recipient might want to only authorize payments for specific amounts - or at specific times (e.g. for tax reasons) -, instead of authorizing "every kind of payments, any time" from the sender they shared their payment address with. +- Payment authorization is transitive (undesired property). A malicious sender could disclose the payment address of the recipient to other network participants which will - in turn - "grant them authorization to send funds to the recipient", against the recipient's will. Say, e.g. Alice gives her address to Bob to authorize him to pay her. If Bob leaks Alice's address to Charlie, then, now Charlie knows Alice's address - as if Alice gave her address to Charlie (to authorize him to pay her). In other words, recipients can control who they share their address with, but once shared they can't control who else will get their address. (Obviously, not all senders will be malicious in reality, but every sender can be compromised. This is why, we must assume all senders to be malicious in the analysis.) + +Nowadays, any sender who has the address of another Zcash user can - unilaterally - send funds to this user. + +In doing so, the sender can: + +- Create a link between the recipient and a specific asset. +- Create a link between a recipient and unlawfully acquired/tainted funds (e.g. to blackmail, cause reputational damages) etc. +- Associate the recipient with a group of users or a set of on-chain transactions + +The fact that senders can - unaliterally - transfer funds to a recipient, without their consent creates a set of practical issues. +Custodians like centralized exchanges (CEX), for instance, have no way to reject fraudulent deposits. As a consequence, several CEX have started to delist privacy preserving crypto assets like Zcash [INSERT REF]. Such delistings impact the Zcash community, making the asset harder to buy and sell across the ecosystem. +Likewise, given that recipients are not actively involved in the transfer of funds, the sender is the sole responsible to make sure that the asset transfer occurs as expected. +Unfortunately, mistakes are made regularly (e.g. typos in the address of the recipient), which regularly leads funds being lost. +Established payment systems (e.g. CHAPS or Faster Payments in the UK) have developped solutions to mitigate errors in transfers (e.g. Confirmation of Payee (CoP) [TODO REF]), but, to date, crypto transfers lack such safeguarding functionality. + +This ZIP introduces an interactive protocol for the sender of funds to seek approval from the recipient during an asset transfer. +This approval is generated by the recipient of funds who generates an approval signature on the raw transaction and sends it back to the sender. +Upon receipt of the approval signature, the sender can then submit the transaction to the chain for execution. +The Zcash network can verify the validity of the approval by verifying that the approval signature has been generated by the recipient of the funds transfered in the transaction. + +This interactive user control protocol offers a double-opt in on fund transfers, which: + +1. acts as a loss-prevention mechanism, and +2. allows the recipients of funds to control (accept/reject) the funds being sent to their wallet. + +Specification +============= + +Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following. + +Approval Signature +------------------ + +Given the Orchard address (in the form: $d | pk_d$) of the recipient of the output note of an Orchard Action and given that $g_d$ is a Pallas curve point, derived from $d$ - the approval signature derivation goes as follows: + +1. The sender sends the OrchardAction (the preimage of the message to be signed) for the recipient to sign. +2. The recipient executes the following steps: + - $m \gets H(OrchardActionDescription)$, where $OrchardActionDescription$ is the Orchard Action description as per https://zips.z.cash/protocol/protocol.pdf#actionencodingandconsensus. + - Takes $r \overset{{\scriptscriptstyle\$}}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas, and where $\overset{{\scriptscriptstyle\$}}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. + - $u \gets [r]g_d$, a Pallas point + - $C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field + - $s \gets r + C * ivk \mod r_{\mathbb{P}}$, an element of Pallas' scalar field + - $\sigma_{approval} \gets (u, s)$ + +, and sends $\sigma_{approval}$ to the sender (off-chain). + +$\sigma_{approval}$ is a tuple made of one Pallas point and one element of Pallas' scalar field. +Hence, the size, in bytes of $\sigma_{approval}$ is: 96 bytes. + +Rationale for Approval Signature +```````````````````````````````` + +To prove that the correct recipient of the output notes of an Orchard Action approves (the transfer of funds represented by) the Action, we want to show that the approval signature has been generated with a signing key that is derived from the spending key of the recipient of the output notes of the Action. +In other words, we want to prove that the approval signature is generated by the network user who "knows" the spending key of the output notes of the Action. +Doing so means that only the recipient of the note created in the Orchard Action can approve the payment. + +To achieve this, we look into the key structure of Zcash Orchard. +We know that the Orchard address is of the form: $d | pk_d$. +These 2 fields, the diversifier and the diversified address, are used by the sender when sending notes. + +Looking at the Orchard key components derivations, we know that $pk_d$ is derived as: +$pk_d := KAOrchard.DerivePublic(ivk, g_d) = [ivk]g_d$ + +Given that $ivk$ is derived from the spending key of the recipient of the funds, we can prove that the recipient of the funds in an Orchard Action is approving the receipt of the funds, by using a proof of knowledge of $ivk$. +Such proof of knowledge of $ivk$ can be obtained by using the Non-Interactive Schnorr Protocol. + +In fact, such proof of knowledge of ivk can be obtained by using a Schnorr Signature on the Action (the message) with ivk as signing/secret key and $g_d$ as group generator. + +Modifications to the Orchard Statement/Circuit +---------------------------------------------- + +The following steps are added to the Orchard Action statement: + +Instance: + +- $\sigma_{approval}$ +- OrchardActionDescription + +Witness: + +- $g_d$ +- $pk_d$ + +Circuit: + +- $C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(OrchardActionDescription))$ +- $LHS \gets [\sigma_{approval}.s]g_d$ +- $RHS \gets \sigma_{approval}.u + [C']pk_d$ +- $LHS - RHS = 0$ + +Rationale for the modifications to the Orchard Statement/Circuit +```````````````````````````````````````````````````````````````` + +Upon receipt of the approval signature by the recipient of the funds, the sender could include $\sigma_{approval}$ along with $g_d$ and $pk_d$ in the transaction to be sent on chain. +Indeed, both $g_d$ and $pk_d$ of the recipient are needed by the Zcash validators/miners to verify the approval Schnorr signature on chain. + +In this case, the Zcash miners could verify the recipient's approval by doing (for each Action in the transaction): + +1. $C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(OrchardActionDescription))$ +2. $LHS \gets [\sigma_{approval}.sigma]g_d$ +3. $RHS \gets \sigma_{approval}.u + [C']pk_d$ +4. $LHS \stackrel{?}{=} RHS$. If not, reject transaction. + +If the signature was generated correctly, $LHS = [r + C * ivk]g_d$ and $RHS =[r]g_d + [C]pk_d$, since a well derived $pk_d$ equals $[ivk]g_d$ we get $RHS = [r]g_d + [C][ivk]g_d \implies RHS = [r + C * ivk]g_d$. +So if all steps are followed properly, $LHS = RHS$ and the signature verification succeeds. + +However, to verify the signature, Zcash miners need to know which $g_d$ and $pk_d$ to use to verify the approval signatures on each Actions. +Disclosing these values leaks "which Orchard address" is the recipient of the output notes of an Action. +So, unlinkability is affected. + +Here, the sender needs to include the Orchard address of the recipient for the miners to check approval from the recipient. +To fix this, we included the Schnorr signature verification in the Orchard Action circuit directly. This keeps the recipient's $g_d$ and $pk_d$ privy to the transacting parties (i.e. the values remain part of the witness - as currently done in the NU5 protocol). +The Zcash miners, just need to verify the Orchard Action proof to make sure the approval signature was: + +- Properly generated by the recipient of the notes in the Orchard Actions +- Properly verified by the sender of the funds + +Modifications to the Transaction Format +--------------------------------------- + +In order to support this ZIP, the transaction format must be extended to add the appoval signatures, as follows: + +======================= ================ ============================ ================================================================ +Bytes Name Data Type Description +======================= ================ ============================ ================================================================ +96 * nActionsOrchard vApprovalSigs byte[96][nActionsOrchard] Approval signatures for each Orchard Action +======================= ================ ============================ ================================================================ + +Other Considerations +==================== + +Transaction Fees +---------------- + +Given the modification of the transaction structure (and the additional bytes), it might be necessary to slightly increase the default transaction fees on Zcash if this ZIP gets implemented. + +References +========== + +.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances `_ +.. [#zip-0224] `ZIP 224: Orchard `_ +.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ +.. [#zip-0227-specification-global-issuance-state] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Global Issuance State `_ +.. [#zip-0227-assetidentifier] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Asset Identifier `_ +.. [#zip-0227-consensus] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Consensus Rule Changes `_ +.. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance `_ +.. [#zip-0227-sigdigest] `ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest `_ +.. [#zip-0227-authcommitment] `ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment `_ +.. [#zip-0230] `ZIP 230: Version 6 Transaction Format `_ +.. [#zip-0230-orchardzsa-fee-calculation] `ZIP 230: Version 6 Transaction Format: OrchardZSA Fee Calculation `_ +.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ +.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment `_ +.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ +.. [#protocol-notes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes `_ +.. [#protocol-actions] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.7: Action Transfers and their Descriptions `_ +.. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.8: Commitment `_ +.. [#protocol-orcharddummynotes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.8.3: Dummy Notes (Orchard) `_ +.. [#protocol-orchardbalance] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.14: Balance and Binding Signature (Orchard) `_ +.. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.16: Computing ρ values and Nullifiers `_ +.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.18.4: Action Statement (Orchard) `_ +.. [#protocol-endian] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.1: Integers, Bit Sequences, and Endianness `_ +.. [#protocol-constants] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants `_ +.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.1.9: Sinsemilla hash function `_ +.. [#protocol-concretehomomorphiccommit] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ +.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.8.4: Sinsemilla commitments `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.6: Pallas and Vesta `_ +.. [#protocol-notept] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ +.. [#protocol-actionencodingandconsensus] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.5: Action Description Encoding and Consensus `_ +.. [#initial-zsa-issue] `User-Defined Assets and Wrapped Assets `_ +.. [#generalized-value-commitments] `Comment on Generalized Value Commitments `_ +.. [#circuit-modifications] `Modifications to the Orchard circuit for the OrchardZSA Protocol `_ From 36a23455dd36eb82a865c90c7e451bd697fb3925 Mon Sep 17 00:00:00 2001 From: Antoine Rondelet Date: Sun, 29 Dec 2024 13:12:33 +0000 Subject: [PATCH 2/9] Cleaned references --- zips/zip-approval.rst | 40 +++++++--------------------------------- 1 file changed, 7 insertions(+), 33 deletions(-) diff --git a/zips/zip-approval.rst b/zips/zip-approval.rst index 41c783c5e..7c805d976 100644 --- a/zips/zip-approval.rst +++ b/zips/zip-approval.rst @@ -1,6 +1,6 @@ :: - ZIP: TODO: TO BE ASSIGNED + ZIP: TO BE ASSIGNED Title: Transaction User Controls Owners: Pablo Kogan Antoine Rondelet @@ -65,10 +65,10 @@ In doing so, the sender can: - Associate the recipient with a group of users or a set of on-chain transactions The fact that senders can - unaliterally - transfer funds to a recipient, without their consent creates a set of practical issues. -Custodians like centralized exchanges (CEX), for instance, have no way to reject fraudulent deposits. As a consequence, several CEX have started to delist privacy preserving crypto assets like Zcash [INSERT REF]. Such delistings impact the Zcash community, making the asset harder to buy and sell across the ecosystem. +Custodians like centralized exchanges (CEX), for instance, have no way to reject fraudulent deposits. As a consequence, several CEX have started to delist privacy preserving crypto assets like Zcash [#zcash-delist]_. Such delistings impact the Zcash community, making the asset harder to buy and sell across the ecosystem. Likewise, given that recipients are not actively involved in the transfer of funds, the sender is the sole responsible to make sure that the asset transfer occurs as expected. Unfortunately, mistakes are made regularly (e.g. typos in the address of the recipient), which regularly leads funds being lost. -Established payment systems (e.g. CHAPS or Faster Payments in the UK) have developped solutions to mitigate errors in transfers (e.g. Confirmation of Payee (CoP) [TODO REF]), but, to date, crypto transfers lack such safeguarding functionality. +Established payment systems (e.g. CHAPS or Faster Payments in the UK) have developped solutions to mitigate errors in transfers (e.g. Confirmation of Payee (CoP) [#confirmation-of-payee]_), but, to date, crypto transfers lack such safeguarding functionality. This ZIP introduces an interactive protocol for the sender of funds to seek approval from the recipient during an asset transfer. This approval is generated by the recipient of funds who generates an approval signature on the raw transaction and sends it back to the sender. @@ -92,7 +92,7 @@ Given the Orchard address (in the form: $d | pk_d$) of the recipient of the outp 1. The sender sends the OrchardAction (the preimage of the message to be signed) for the recipient to sign. 2. The recipient executes the following steps: - - $m \gets H(OrchardActionDescription)$, where $OrchardActionDescription$ is the Orchard Action description as per https://zips.z.cash/protocol/protocol.pdf#actionencodingandconsensus. + - $m \gets H(OrchardActionDescription)$, where $OrchardActionDescription$ is the Orchard Action description as per [#protocol-actions]_. - Takes $r \overset{{\scriptscriptstyle\$}}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas, and where $\overset{{\scriptscriptstyle\$}}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. - $u \gets [r]g_d$, a Pallas point - $C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field @@ -199,32 +199,6 @@ References .. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances `_ .. [#zip-0224] `ZIP 224: Orchard `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ -.. [#zip-0227-specification-global-issuance-state] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Global Issuance State `_ -.. [#zip-0227-assetidentifier] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Asset Identifier `_ -.. [#zip-0227-consensus] `ZIP 227: Issuance of Zcash Shielded Assets: Specification: Consensus Rule Changes `_ -.. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TxId Digest - Issuance `_ -.. [#zip-0227-sigdigest] `ZIP 227: Issuance of Zcash Shielded Assets: Signature Digest `_ -.. [#zip-0227-authcommitment] `ZIP 227: Issuance of Zcash Shielded Assets: Authorizing Data Commitment `_ -.. [#zip-0230] `ZIP 230: Version 6 Transaction Format `_ -.. [#zip-0230-orchardzsa-fee-calculation] `ZIP 230: Version 6 Transaction Format: OrchardZSA Fee Calculation `_ -.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ -.. [#zip-0244-authcommitment] `ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment `_ -.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ -.. [#protocol-notes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes `_ -.. [#protocol-actions] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.7: Action Transfers and their Descriptions `_ -.. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.8: Commitment `_ -.. [#protocol-orcharddummynotes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.8.3: Dummy Notes (Orchard) `_ -.. [#protocol-orchardbalance] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.14: Balance and Binding Signature (Orchard) `_ -.. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.16: Computing ρ values and Nullifiers `_ -.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.18.4: Action Statement (Orchard) `_ -.. [#protocol-endian] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.1: Integers, Bit Sequences, and Endianness `_ -.. [#protocol-constants] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants `_ -.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.1.9: Sinsemilla hash function `_ -.. [#protocol-concretehomomorphiccommit] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.8.3: Homomorphic Pedersen commitments (Sapling and Orchard) `_ -.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.8.4: Sinsemilla commitments `_ -.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.6: Pallas and Vesta `_ -.. [#protocol-notept] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ -.. [#protocol-actionencodingandconsensus] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.5: Action Description Encoding and Consensus `_ -.. [#initial-zsa-issue] `User-Defined Assets and Wrapped Assets `_ -.. [#generalized-value-commitments] `Comment on Generalized Value Commitments `_ -.. [#circuit-modifications] `Modifications to the Orchard circuit for the OrchardZSA Protocol `_ +.. [#confirmation-of-payee] `Confirmation of Payee` +.. [#zcash-delist] `Important: Potential Binance Delisting` +.. [#protocol-actions] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.5: Action Description Encoding and Consensus, ` \ No newline at end of file From 41742aa0e98cf0d0d534027f7c23e898ec6b8f0e Mon Sep 17 00:00:00 2001 From: Antoine Rondelet Date: Sun, 29 Dec 2024 13:48:28 +0000 Subject: [PATCH 3/9] Added more references --- zips/zip-approval.rst | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/zips/zip-approval.rst b/zips/zip-approval.rst index 7c805d976..9c0a64997 100644 --- a/zips/zip-approval.rst +++ b/zips/zip-approval.rst @@ -88,14 +88,14 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Approval Signature ------------------ -Given the Orchard address (in the form: $d | pk_d$) of the recipient of the output note of an Orchard Action and given that $g_d$ is a Pallas curve point, derived from $d$ - the approval signature derivation goes as follows: +Given the Orchard address (in the form: $d | pk_d$, see [#protocol-raw-address]_) of the recipient of the output note of an Orchard Action and given that $g_d$ is a Pallas curve point, derived from $d$ (see [#protocol-diversify-hash]_) - the approval signature derivation goes as follows: 1. The sender sends the OrchardAction (the preimage of the message to be signed) for the recipient to sign. 2. The recipient executes the following steps: - $m \gets H(OrchardActionDescription)$, where $OrchardActionDescription$ is the Orchard Action description as per [#protocol-actions]_. - - Takes $r \overset{{\scriptscriptstyle\$}}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas, and where $\overset{{\scriptscriptstyle\$}}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. + - Takes $r \overset{{\scriptscriptstyle\$}}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas [#protocol-pallas-vesta]_, and where $\overset{{\scriptscriptstyle\$}}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. - $u \gets [r]g_d$, a Pallas point - - $C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field + - $C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field, and where $H$ is a secure hash function (e.g. SHA256 or Blake2) - $s \gets r + C * ivk \mod r_{\mathbb{P}}$, an element of Pallas' scalar field - $\sigma_{approval} \gets (u, s)$ @@ -116,7 +116,7 @@ We know that the Orchard address is of the form: $d | pk_d$. These 2 fields, the diversifier and the diversified address, are used by the sender when sending notes. Looking at the Orchard key components derivations, we know that $pk_d$ is derived as: -$pk_d := KAOrchard.DerivePublic(ivk, g_d) = [ivk]g_d$ +$pk_d := KAOrchard.DerivePublic(ivk, g_d) = [ivk]g_d$, see [#protocol-orchard-keys]_ and [#protocol-key-agreement]_ Given that $ivk$ is derived from the spending key of the recipient of the funds, we can prove that the recipient of the funds in an Orchard Action is approving the receipt of the funds, by using a proof of knowledge of $ivk$. Such proof of knowledge of $ivk$ can be obtained by using the Non-Interactive Schnorr Protocol. @@ -131,7 +131,7 @@ The following steps are added to the Orchard Action statement: Instance: - $\sigma_{approval}$ -- OrchardActionDescription +- $OrchardActionDescription$ Witness: @@ -175,7 +175,7 @@ The Zcash miners, just need to verify the Orchard Action proof to make sure the Modifications to the Transaction Format --------------------------------------- -In order to support this ZIP, the transaction format must be extended to add the appoval signatures, as follows: +In order to support this ZIP, the transaction format, as specified in [#protocol-tx-encoding]_, must be extended to add the appoval signatures, as follows: ======================= ================ ============================ ================================================================ Bytes Name Data Type Description @@ -201,4 +201,10 @@ References .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#confirmation-of-payee] `Confirmation of Payee` .. [#zcash-delist] `Important: Potential Binance Delisting` -.. [#protocol-actions] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.5: Action Description Encoding and Consensus, ` \ No newline at end of file +.. [#protocol-actions] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.5: Action Description Encoding and Consensus` +.. [#protocol-raw-address] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.6.4.2 Orchard Raw Payment Addresses` +.. [#protocol-diversify-hash] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.1.6 DiversifyHashSapling and DiversifyHashOrchard Hash Functions` +.. [#protocol-pallas-vesta] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.9.6 Pallas and Vesta` +.. [#protocol-orchard-keys] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 4.2.3 Orchard Key Components` +.. [#protocol-key-agreement] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.5.5 Orchard Key Agreement` +.. [#protocol-tx-encoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 7.1 Transaction Encoding and Consensus` \ No newline at end of file From e254561fa47b0881719464c554ce21e281542b10 Mon Sep 17 00:00:00 2001 From: Antoine Rondelet Date: Sun, 29 Dec 2024 15:55:18 +0000 Subject: [PATCH 4/9] Fixed rendering of the ZIP and added notes --- zips/zip-approval.rst | 89 ++++++++++++++++++++++--------------------- 1 file changed, 45 insertions(+), 44 deletions(-) diff --git a/zips/zip-approval.rst b/zips/zip-approval.rst index 9c0a64997..9fe8c7204 100644 --- a/zips/zip-approval.rst +++ b/zips/zip-approval.rst @@ -2,8 +2,8 @@ ZIP: TO BE ASSIGNED Title: Transaction User Controls - Owners: Pablo Kogan - Antoine Rondelet + Owners: Antoine Rondelet + Pablo Kogan Status: Draft Category: Consensus Created: 2024-12-22 @@ -26,59 +26,44 @@ The terms "Asset" and "ZSA" in this document are to be interpreted as described Abstract ======== -This ZIP proposes transaction user controls - a mechanism allowing recipients of shielded funds to actively participate in the transfer of assets by approving or rejecting incoming transactions. +This ZIP proposes transaction user controls - a mechanism allowing recipients of shielded funds to actively participate in the transfer of Assets by approving or rejecting incoming transactions. Motivation ========== -In the current version of Zcash, fund transfers occur without explicit recipient consent. +In the current version of Zcash, fund transfers occur without the explicit consent of recipients. While this simplicity offers convenience, it creates significant challenges for users of the network (e.g. individuals or businesses). The goal of this ZIP is to design a mechanism where the recipient of shielded funds on Zcash (for any type of ZSA) can confirm (or ‘approve’) the receipt of the funds on chain. -This enhancement addresses crucial needs in the Zcash ecosystem, particularly at a time when privacy-preserving assets face increased scrutiny from major exchanges. +This enhancement addresses crucial needs in the Zcash ecosystem, particularly at a time when privacy-preserving assets face increased scrutiny from major cryptocurrency exchanges. The proposed controls offer robust safeguarding solutions while maintaining Zcash’s core privacy features. Overview ======== -Existing Zcash users rely on the notion of "address" to identify each other. -Each Zcash user has one or more address. -When 2 users (a sender and a recipient) want to transact, they first need to "discover each other". -More particularly, the sender of the funds, must get the address of the recipient in order to transfer funds to the counterparty. -This "address discovery" is usually done via off-chain communications (e.g. emails, forum). -By sharing (or not sharing) their payment address, recipients can decide (i.e. 'authorize' or 'not authorize') which other network participants can send them funds on the network. +In the current Zcash network, users identify each other through addresses. When two parties want to transact, the sender must first obtain the recipient's address, typically through off-chain communications like email or forums. Recipients can control incoming payments by selectively sharing their addresses, effectively "authorizing" specific users to send them funds. -In some contexts, individuals and/or organizations may want to publish one of their addresses in order to allow everyone to issue a payment to them (e.g. charities like Turing Trust). -In other cases, Zcash users may want to selectively disclose their payment addresses to only allow incoming payments from a restricted set of users. +While some users or organizations (e.g. charities like Turing Trust) may choose to publicly share their addresses, others prefer to restrict address sharing to specific parties. However, this address-based authorization system has several fundamental limitations: -But, relying exclusively on "address discovery" to authorize / not authorize incoming payments has the following limitations: - -- Lack of revocation: Sharing one's payment address only allows the recipient to "grant" the "authority to be paid by a user", but it doesn't allow the recipient to "revoke" this "authority to be paid". This could be an issue if recipients want to authorize the sender to pay them only once. (Generating new addresses is not a clean way to revoke the authorization to pay because the sender can still send funds to the old address, potentially leading to lost funds. More on that below.) -- Loose authorization. Sharing one's address with a sender only allows the recipient to "grant" the "authority to be paid by a user" but it does not constrain the terms of the payment. The recipient might want to only authorize payments for specific amounts - or at specific times (e.g. for tax reasons) -, instead of authorizing "every kind of payments, any time" from the sender they shared their payment address with. -- Payment authorization is transitive (undesired property). A malicious sender could disclose the payment address of the recipient to other network participants which will - in turn - "grant them authorization to send funds to the recipient", against the recipient's will. Say, e.g. Alice gives her address to Bob to authorize him to pay her. If Bob leaks Alice's address to Charlie, then, now Charlie knows Alice's address - as if Alice gave her address to Charlie (to authorize him to pay her). In other words, recipients can control who they share their address with, but once shared they can't control who else will get their address. (Obviously, not all senders will be malicious in reality, but every sender can be compromised. This is why, we must assume all senders to be malicious in the analysis.) +1. No Revocation Mechanism: Once an address is shared, recipients cannot revoke a sender's ability to transfer funds. While generating new addresses is possible, the sender can still send funds to old addresses, potentially leading to lost funds. +2. Lack of Fine-grained Control: Sharing an address grants unrestricted payment authorization. Recipients cannot set conditions on incoming payments, such as specific amounts or timing restrictions (e.g., for tax purposes). +3. Uncontrolled Transitivity: Address sharing is transitive - if recipient Alice shares her address with Bob, who then shares it with Charlie, Charlie gains the same payment capabilities as Bob. This means recipients lose control over who can ultimately send them funds, as their address may be shared (maliciously or through compromise) with unintended parties. -Nowadays, any sender who has the address of another Zcash user can - unilaterally - send funds to this user. +Currently, any sender with a recipient's address can unilaterally initiate transfers. This capability creates several risks: -In doing so, the sender can: +- Establishing unwanted links between recipients and a specific Asset +- Associating recipients with tainted funds (e.g. for blackmail or reputational damage) +- Creating undesired connections between recipients and other users or transactions -- Create a link between the recipient and a specific asset. -- Create a link between a recipient and unlawfully acquired/tainted funds (e.g. to blackmail, cause reputational damages) etc. -- Associate the recipient with a group of users or a set of on-chain transactions +This unilateral transfer capability presents practical challenges across the ecosystem. Centralized exchanges (CEXs) cannot reject fraudulent deposits, leading some to delist privacy-preserving assets like Zcash [#zcash-delist]_. These delistings impact the entire Zcash community by reducing asset liquidity and accessibility. -The fact that senders can - unaliterally - transfer funds to a recipient, without their consent creates a set of practical issues. -Custodians like centralized exchanges (CEX), for instance, have no way to reject fraudulent deposits. As a consequence, several CEX have started to delist privacy preserving crypto assets like Zcash [#zcash-delist]_. Such delistings impact the Zcash community, making the asset harder to buy and sell across the ecosystem. -Likewise, given that recipients are not actively involved in the transfer of funds, the sender is the sole responsible to make sure that the asset transfer occurs as expected. -Unfortunately, mistakes are made regularly (e.g. typos in the address of the recipient), which regularly leads funds being lost. -Established payment systems (e.g. CHAPS or Faster Payments in the UK) have developped solutions to mitigate errors in transfers (e.g. Confirmation of Payee (CoP) [#confirmation-of-payee]_), but, to date, crypto transfers lack such safeguarding functionality. +Furthermore, since recipients are not actively involved in transfers, the sender bears sole responsibility for transaction accuracy. Common mistakes like address typos regularly result in lost funds. While traditional payment systems (e.g. for CHAPS or Faster Payments in the UK) have developed safeguards against such errors (e.g., Confirmation of Payee [#confirmation-of-payee]_), cryptocurrency transfers lack similar protections. -This ZIP introduces an interactive protocol for the sender of funds to seek approval from the recipient during an asset transfer. -This approval is generated by the recipient of funds who generates an approval signature on the raw transaction and sends it back to the sender. -Upon receipt of the approval signature, the sender can then submit the transaction to the chain for execution. -The Zcash network can verify the validity of the approval by verifying that the approval signature has been generated by the recipient of the funds transfered in the transaction. +This ZIP introduces an interactive protocol requiring recipient approval for asset transfers. The recipient generates an approval signature for the Orchard Action and returns it to the sender, who then submits the complete transaction to the network. The network verifies the approval by checking that the signature was generated by the intended recipient. -This interactive user control protocol offers a double-opt in on fund transfers, which: +This double opt-in protocol provides two key benefits: -1. acts as a loss-prevention mechanism, and -2. allows the recipients of funds to control (accept/reject) the funds being sent to their wallet. +1. Prevention of accidental fund loss (i.e. safeguarding) +2. Recipient control over incoming transfers Specification ============= @@ -88,12 +73,12 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Approval Signature ------------------ -Given the Orchard address (in the form: $d | pk_d$, see [#protocol-raw-address]_) of the recipient of the output note of an Orchard Action and given that $g_d$ is a Pallas curve point, derived from $d$ (see [#protocol-diversify-hash]_) - the approval signature derivation goes as follows: +Given the Orchard address of the recipient of the output note of an Orchard Action (in the form: $d | pk_d$, see [#protocol-raw-address]_), and given that $g_d$ is a Pallas curve point, derived from $d$ (see [#protocol-diversify-hash]_) - the approval signature derivation goes as follows: -1. The sender sends the OrchardAction (the preimage of the message to be signed) for the recipient to sign. +1. The sender sends the $OrchardActionDescription$ (the preimage of the message to be signed, as per [#protocol-actions]_) for the recipient to sign. 2. The recipient executes the following steps: - - $m \gets H(OrchardActionDescription)$, where $OrchardActionDescription$ is the Orchard Action description as per [#protocol-actions]_. - - Takes $r \overset{{\scriptscriptstyle\$}}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas [#protocol-pallas-vesta]_, and where $\overset{{\scriptscriptstyle\$}}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. + - $m \gets H(OrchardActionDescription)$ + - $r \overset{R}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas [#protocol-pallas-vesta]_, and where $\overset{R}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. - $u \gets [r]g_d$, a Pallas point - $C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field, and where $H$ is a secure hash function (e.g. SHA256 or Blake2) - $s \gets r + C * ivk \mod r_{\mathbb{P}}$, an element of Pallas' scalar field @@ -101,8 +86,7 @@ Given the Orchard address (in the form: $d | pk_d$, see [#protocol-raw-address]_ , and sends $\sigma_{approval}$ to the sender (off-chain). -$\sigma_{approval}$ is a tuple made of one Pallas point and one element of Pallas' scalar field. -Hence, the size, in bytes of $\sigma_{approval}$ is: 96 bytes. +$\sigma_{approval}$ is a tuple made of one Pallas point and one element of Pallas' scalar field. Hence, the size of $\sigma_{approval}$ is 96 bytes. Rationale for Approval Signature ```````````````````````````````` @@ -121,7 +105,10 @@ $pk_d := KAOrchard.DerivePublic(ivk, g_d) = [ivk]g_d$, see [#protocol-orchard-ke Given that $ivk$ is derived from the spending key of the recipient of the funds, we can prove that the recipient of the funds in an Orchard Action is approving the receipt of the funds, by using a proof of knowledge of $ivk$. Such proof of knowledge of $ivk$ can be obtained by using the Non-Interactive Schnorr Protocol. -In fact, such proof of knowledge of ivk can be obtained by using a Schnorr Signature on the Action (the message) with ivk as signing/secret key and $g_d$ as group generator. +In fact, such proof of knowledge of $ivk$ can be obtained by using a Schnorr Signature on the Action (the message) with $ivk$ as signing/secret key and $g_d$ as group generator. + +**Note:** Zcash Orchard already uses a Schnorr-based signature scheme instantiated with the Pallas curve (see RedPallas [#protocol-redpallas]_). +As of NU6, RedPallas is used to instantiate $SpendAuthSig^{Orchard}$ and $BindingSig^{Orchard}$. Modifications to the Orchard Statement/Circuit ---------------------------------------------- @@ -145,6 +132,10 @@ Circuit: - $RHS \gets \sigma_{approval}.u + [C']pk_d$ - $LHS - RHS = 0$ + +**Note:** It is also possible to move these steps into a separate circuit. +In this case, the transaction structure needs to be modified to account for an extra proof per action. + Rationale for the modifications to the Orchard Statement/Circuit ```````````````````````````````````````````````````````````````` @@ -175,7 +166,7 @@ The Zcash miners, just need to verify the Orchard Action proof to make sure the Modifications to the Transaction Format --------------------------------------- -In order to support this ZIP, the transaction format, as specified in [#protocol-tx-encoding]_, must be extended to add the appoval signatures, as follows: +In order to support this ZIP, the transaction format, as specified in [#protocol-tx-encoding]_, must be extended to add the approval signatures, as follows: ======================= ================ ============================ ================================================================ Bytes Name Data Type Description @@ -191,6 +182,15 @@ Transaction Fees Given the modification of the transaction structure (and the additional bytes), it might be necessary to slightly increase the default transaction fees on Zcash if this ZIP gets implemented. +Malicious Recipients +-------------------- + +By empowering recipients to approve (or not) incoming transactions, we also give them the ability to withhold their approval. +This could be done maliciously to, for instance: + +1. Block a payment and deny to have received the "approval request", then accuse the sender to have failed to settle a contractual obligation. +2. Gain information: By receiving the $OrchardActionDescription$ to approve, recipients gets to see the $nullifier$ of the input note of the Orchard Action before the rest of the network. + References ========== @@ -207,4 +207,5 @@ References .. [#protocol-pallas-vesta] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.9.6 Pallas and Vesta` .. [#protocol-orchard-keys] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 4.2.3 Orchard Key Components` .. [#protocol-key-agreement] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.5.5 Orchard Key Agreement` -.. [#protocol-tx-encoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 7.1 Transaction Encoding and Consensus` \ No newline at end of file +.. [#protocol-tx-encoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 7.1 Transaction Encoding and Consensus` +.. [#protocol-redpallas] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.7 RedDSA, RedJubjub, and RedPallas` \ No newline at end of file From 3d1ca4e0cc5b0cfe095e1d78a8714f2ac3cf8c9f Mon Sep 17 00:00:00 2001 From: Antoine Rondelet Date: Sun, 26 Jan 2025 14:20:19 +0000 Subject: [PATCH 5/9] Renamed approval zip file adding draft prefix --- zips/{zip-approval.rst => draft-approval.rst} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename zips/{zip-approval.rst => draft-approval.rst} (99%) diff --git a/zips/zip-approval.rst b/zips/draft-approval.rst similarity index 99% rename from zips/zip-approval.rst rename to zips/draft-approval.rst index 9fe8c7204..4dfea5628 100644 --- a/zips/zip-approval.rst +++ b/zips/draft-approval.rst @@ -1,6 +1,6 @@ :: - ZIP: TO BE ASSIGNED + ZIP: Unassigned Title: Transaction User Controls Owners: Antoine Rondelet Pablo Kogan @@ -9,7 +9,7 @@ Created: 2024-12-22 License: MIT Discussions-To: - Pull-Request: + Pull-Request: TBD Terminology From 27042ba735ec998eec80a2ab980704200065c1e2 Mon Sep 17 00:00:00 2001 From: Antoine Rondelet Date: Sat, 15 Feb 2025 20:19:00 +0000 Subject: [PATCH 6/9] Apply Vivek's Latex edits Co-authored-by: Vivek Arte <46618816+vivek-arte@users.noreply.github.com> --- zips/draft-approval.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/zips/draft-approval.rst b/zips/draft-approval.rst index 4dfea5628..34a18052d 100644 --- a/zips/draft-approval.rst +++ b/zips/draft-approval.rst @@ -26,7 +26,7 @@ The terms "Asset" and "ZSA" in this document are to be interpreted as described Abstract ======== -This ZIP proposes transaction user controls - a mechanism allowing recipients of shielded funds to actively participate in the transfer of Assets by approving or rejecting incoming transactions. +This ZIP specifies user controls for transactions - a mechanism allowing recipients of shielded funds to actively participate in the transfer of Assets by approving or rejecting incoming transactions. Motivation ========== @@ -79,9 +79,9 @@ Given the Orchard address of the recipient of the output note of an Orchard Acti 2. The recipient executes the following steps: - $m \gets H(OrchardActionDescription)$ - $r \overset{R}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas [#protocol-pallas-vesta]_, and where $\overset{R}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. - - $u \gets [r]g_d$, a Pallas point + - $u \gets [r] \mathsf{g_d}$ - $C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field, and where $H$ is a secure hash function (e.g. SHA256 or Blake2) - - $s \gets r + C * ivk \mod r_{\mathbb{P}}$, an element of Pallas' scalar field + - $s \gets r + C \cdot ivk \mod r_{\mathbb{P}}$, an element of Pallas' scalar field - $\sigma_{approval} \gets (u, s)$ , and sends $\sigma_{approval}$ to the sender (off-chain). @@ -96,18 +96,18 @@ In other words, we want to prove that the approval signature is generated by the Doing so means that only the recipient of the note created in the Orchard Action can approve the payment. To achieve this, we look into the key structure of Zcash Orchard. -We know that the Orchard address is of the form: $d | pk_d$. +We know that the Orchard address is of the form: $(\mathsf{d}, \mathsf{pk_d})$. These 2 fields, the diversifier and the diversified address, are used by the sender when sending notes. -Looking at the Orchard key components derivations, we know that $pk_d$ is derived as: -$pk_d := KAOrchard.DerivePublic(ivk, g_d) = [ivk]g_d$, see [#protocol-orchard-keys]_ and [#protocol-key-agreement]_ +Looking at the Orchard key components derivations, we know that $\mathsf{pk_d}$ is derived as: +$\mathsf{pk_d} =mathsf{KAOrchard.DerivePublic}(\mathsf{ivk}, \mathsf{g_d}) = [\mathsf{ivk}]\mathsf{g_d}$ [#protocol-orchard-keys]_``` -Given that $ivk$ is derived from the spending key of the recipient of the funds, we can prove that the recipient of the funds in an Orchard Action is approving the receipt of the funds, by using a proof of knowledge of $ivk$. -Such proof of knowledge of $ivk$ can be obtained by using the Non-Interactive Schnorr Protocol. +Given that $\mathsf{ivk}$ is derived from the spending key of the recipient of the funds, we can prove that the recipient of the funds in an Orchard Action is approving the receipt of the funds, by using a proof of knowledge of $\mathsf{ivk}$. +Such proof of knowledge of $\mathsf{ivk}$ can be obtained by using the Non-Interactive Schnorr Protocol. -In fact, such proof of knowledge of $ivk$ can be obtained by using a Schnorr Signature on the Action (the message) with $ivk$ as signing/secret key and $g_d$ as group generator. +In fact, such proof of knowledge of $\mathsf{ivk}$ can be obtained by using a Schnorr Signature on the Action (the message) with $\mathsf{ivk}$ as signing/secret key and $\mathsf{g_d}$ as group generator. -**Note:** Zcash Orchard already uses a Schnorr-based signature scheme instantiated with the Pallas curve (see RedPallas [#protocol-redpallas]_). +**Note:** Zcash Orchard already uses a Schnorr-based signature scheme instantiated with the Pallas curve, $\mathsf{RedPallas}$ [#protocol-redpallas]_. As of NU6, RedPallas is used to instantiate $SpendAuthSig^{Orchard}$ and $BindingSig^{Orchard}$. Modifications to the Orchard Statement/Circuit From 7003b49544390a8e3bd2e76bfa312f911091834f Mon Sep 17 00:00:00 2001 From: Antoine Rondelet Date: Sun, 16 Feb 2025 19:08:12 +0000 Subject: [PATCH 7/9] Added some latex beautifying and minor rephrasing --- zips/draft-approval.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/zips/draft-approval.rst b/zips/draft-approval.rst index 34a18052d..71b65db4e 100644 --- a/zips/draft-approval.rst +++ b/zips/draft-approval.rst @@ -73,15 +73,15 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5, Approval Signature ------------------ -Given the Orchard address of the recipient of the output note of an Orchard Action (in the form: $d | pk_d$, see [#protocol-raw-address]_), and given that $g_d$ is a Pallas curve point, derived from $d$ (see [#protocol-diversify-hash]_) - the approval signature derivation goes as follows: +Let $(\mathsf{d}, \mathsf{pk_d})$ be the Orchard shielded payment address of the recipient of the output note of an Orchard Action [#protocol-raw-address]_. Let $\mathsf{g_d}$ be derived from the diversifier $\mathsf{d}$ as in §5.4.1.6 of the protocol specification [#protocol-diversify-hash]_. The approval signature is derived as follows: -1. The sender sends the $OrchardActionDescription$ (the preimage of the message to be signed, as per [#protocol-actions]_) for the recipient to sign. +1. The sender sends the $\mathtt{OrchardActionDescription}$ (the preimage of the message to be signed, as per [#protocol-actions]_) for the recipient to sign. 2. The recipient executes the following steps: - - $m \gets H(OrchardActionDescription)$ - - $r \overset{R}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas [#protocol-pallas-vesta]_, and where $\overset{R}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set. + - $m \gets H(\mathtt{OrchardActionDescription})$ + - $r \overset{R}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}$, where $\mathbb{Z}_{r_{\mathbb{P}}}$ is the scalar field of Pallas [#protocol-pallas-vesta]_, and where $\overset{R}{\leftarrow}$ denotes a variable assignment uniformly at random from a given set [#protocol-notation]_. - $u \gets [r] \mathsf{g_d}$ - - $C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field, and where $H$ is a secure hash function (e.g. SHA256 or Blake2) - - $s \gets r + C \cdot ivk \mod r_{\mathbb{P}}$, an element of Pallas' scalar field + - $C \gets H(g_d || pk_d || u || m) \mod r_{\mathbb{P}}$, an element of Pallas' scalar field, and where $H$ is a secure hash function (e.g. SHA256 or Blake2) + - $s \gets r + C \cdot \mathsf{ivk} \mod r_{\mathbb{P}}$, an element of Pallas' scalar field - $\sigma_{approval} \gets (u, s)$ , and sends $\sigma_{approval}$ to the sender (off-chain). @@ -118,7 +118,7 @@ The following steps are added to the Orchard Action statement: Instance: - $\sigma_{approval}$ -- $OrchardActionDescription$ +- $\mathtt{OrchardActionDescription}$ Witness: @@ -127,7 +127,7 @@ Witness: Circuit: -- $C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(OrchardActionDescription))$ +- $C’ \gets H(g_d || pk_d || \sigma_{approval}.u || H(\mathtt{OrchardActionDescription}))$ - $LHS \gets [\sigma_{approval}.s]g_d$ - $RHS \gets \sigma_{approval}.u + [C']pk_d$ - $LHS - RHS = 0$ @@ -144,7 +144,7 @@ Indeed, both $g_d$ and $pk_d$ of the recipient are needed by the Zcash validator In this case, the Zcash miners could verify the recipient's approval by doing (for each Action in the transaction): -1. $C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(OrchardActionDescription))$ +1. $C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(\mathtt{OrchardActionDescription}))$ 2. $LHS \gets [\sigma_{approval}.sigma]g_d$ 3. $RHS \gets \sigma_{approval}.u + [C']pk_d$ 4. $LHS \stackrel{?}{=} RHS$. If not, reject transaction. @@ -189,7 +189,7 @@ By empowering recipients to approve (or not) incoming transactions, we also give This could be done maliciously to, for instance: 1. Block a payment and deny to have received the "approval request", then accuse the sender to have failed to settle a contractual obligation. -2. Gain information: By receiving the $OrchardActionDescription$ to approve, recipients gets to see the $nullifier$ of the input note of the Orchard Action before the rest of the network. +2. Gain information: By receiving the $\mathtt{OrchardActionDescription}$ to approve, recipients gets to see the $nullifier$ of the input note of the Orchard Action before the rest of the network. References ========== From 4c05528e15ef2cd2479440016dcbe2f5cc3e0d53 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Sun, 6 Jul 2025 11:33:41 +0530 Subject: [PATCH 8/9] renaming draft as per ZIP 0 scheme --- zips/{draft-approval.rst => draft-qedit-tx-user-controls.rst} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename zips/{draft-approval.rst => draft-qedit-tx-user-controls.rst} (100%) diff --git a/zips/draft-approval.rst b/zips/draft-qedit-tx-user-controls.rst similarity index 100% rename from zips/draft-approval.rst rename to zips/draft-qedit-tx-user-controls.rst From 034378623ada1fa050feb0189a635d396308f453 Mon Sep 17 00:00:00 2001 From: Vivek Arte Date: Tue, 8 Jul 2025 14:17:07 +0530 Subject: [PATCH 9/9] some math notation improvements --- zips/draft-qedit-tx-user-controls.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/zips/draft-qedit-tx-user-controls.rst b/zips/draft-qedit-tx-user-controls.rst index 71b65db4e..96aed09ef 100644 --- a/zips/draft-qedit-tx-user-controls.rst +++ b/zips/draft-qedit-tx-user-controls.rst @@ -100,7 +100,7 @@ We know that the Orchard address is of the form: $(\mathsf{d}, \mathsf{pk_d})$. These 2 fields, the diversifier and the diversified address, are used by the sender when sending notes. Looking at the Orchard key components derivations, we know that $\mathsf{pk_d}$ is derived as: -$\mathsf{pk_d} =mathsf{KAOrchard.DerivePublic}(\mathsf{ivk}, \mathsf{g_d}) = [\mathsf{ivk}]\mathsf{g_d}$ [#protocol-orchard-keys]_``` +$\mathsf{pk_d} =mathsf{KAOrchard.DerivePublic}(\mathsf{ivk}, \mathsf{g_d}) = [\mathsf{ivk}]\mathsf{g_d}$ [#protocol-orchard-keys]_. Given that $\mathsf{ivk}$ is derived from the spending key of the recipient of the funds, we can prove that the recipient of the funds in an Orchard Action is approving the receipt of the funds, by using a proof of knowledge of $\mathsf{ivk}$. Such proof of knowledge of $\mathsf{ivk}$ can be obtained by using the Non-Interactive Schnorr Protocol. @@ -108,7 +108,7 @@ Such proof of knowledge of $\mathsf{ivk}$ can be obtained by using the Non-Inter In fact, such proof of knowledge of $\mathsf{ivk}$ can be obtained by using a Schnorr Signature on the Action (the message) with $\mathsf{ivk}$ as signing/secret key and $\mathsf{g_d}$ as group generator. **Note:** Zcash Orchard already uses a Schnorr-based signature scheme instantiated with the Pallas curve, $\mathsf{RedPallas}$ [#protocol-redpallas]_. -As of NU6, RedPallas is used to instantiate $SpendAuthSig^{Orchard}$ and $BindingSig^{Orchard}$. +As of NU6, $\mathsf{RedPallas}$ is used to instantiate $\mathsf{SpendAuthSig^{Orchard}}$ and $\mathsf{BindingSig^{Orchard}}$. Modifications to the Orchard Statement/Circuit ---------------------------------------------- @@ -144,7 +144,7 @@ Indeed, both $g_d$ and $pk_d$ of the recipient are needed by the Zcash validator In this case, the Zcash miners could verify the recipient's approval by doing (for each Action in the transaction): -1. $C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(\mathtt{OrchardActionDescription}))$ +1. $C’ \gets H(g_d || pk_d || \sigma_{approval}.u || H(\mathtt{OrchardActionDescription}))$ 2. $LHS \gets [\sigma_{approval}.sigma]g_d$ 3. $RHS \gets \sigma_{approval}.u + [C']pk_d$ 4. $LHS \stackrel{?}{=} RHS$. If not, reject transaction. @@ -189,7 +189,7 @@ By empowering recipients to approve (or not) incoming transactions, we also give This could be done maliciously to, for instance: 1. Block a payment and deny to have received the "approval request", then accuse the sender to have failed to settle a contractual obligation. -2. Gain information: By receiving the $\mathtt{OrchardActionDescription}$ to approve, recipients gets to see the $nullifier$ of the input note of the Orchard Action before the rest of the network. +2. Gain information: By receiving the $\mathtt{OrchardActionDescription}$ to approve, recipients gets to see the nullifier of the input note of the Orchard Action before the rest of the network. References ==========