ZIP draft: Tx acceptance / User controls

zips/draft-qedit-tx-user-controls.rst

@@ -0,0 +1,211 @@
+::
+
+  ZIP: Unassigned
+  Title: Transaction User Controls
+  Owners: Antoine Rondelet <[email protected]>
+          Pablo Kogan <[email protected]>
+  Status: Draft
+  Category: Consensus
+  Created: 2024-12-22
+  License: MIT
+  Discussions-To: <https://forum.zcashcommunity.com/t/introducing-transaction-controls-in-zcash/49640>
+  Pull-Request: TBD
+
+
+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 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
+==========
+
+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 cryptocurrency exchanges.
+The proposed controls offer robust safeguarding solutions while maintaining Zcash’s core privacy features.
+
+Overview
+========
+
+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.
+
+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:
+
+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.
+
+Currently, any sender with a recipient's address can unilaterally initiate transfers. This capability creates several risks:
+
+- 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
+
+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.
+
+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 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 double opt-in protocol provides two key benefits:
+
+1. Prevention of accidental fund loss (i.e. safeguarding)
+2. Recipient control over incoming transfers
+
+Specification
+=============
+
+Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following.
+
+Approval Signature
+------------------
+
+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 $\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(\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 \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).
+
+$\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
+````````````````````````````````
+
+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: $(\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]_.
+
+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 $\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, $\mathsf{RedPallas}$ is used to instantiate $\mathsf{SpendAuthSig^{Orchard}}$ and $\mathsf{BindingSig^{Orchard}}$.
+
+Modifications to the Orchard Statement/Circuit
+----------------------------------------------
+
+The following steps are added to the Orchard Action statement:
+
+Instance:
+
+- $\sigma_{approval}$
+- $\mathtt{OrchardActionDescription}$
+
+Witness:
+
+- $g_d$
+- $pk_d$
+
+Circuit:
+
+- $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$
+
+
+**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
+````````````````````````````````````````````````````````````````
+
+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(\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.
+
+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, as specified in [#protocol-tx-encoding]_, must be extended to add the approval 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.
+
+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 $\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
+==========
+
+.. [#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" <https://www.rfc-editor.org/info/bcp14>`_
+.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.html>`_
+.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <zip-0209.html>`_
+.. [#zip-0224] `ZIP 224: Orchard <zip-0224.html>`_
+.. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets <zip-0227.html>`_
+.. [#confirmation-of-payee] `Confirmation of Payee` <https://www.wearepay.uk/what-we-do/overlay-services/confirmation-of-payee/>
+.. [#zcash-delist] `Important: Potential Binance Delisting` <https://forum.zcashcommunity.com/t/important-potential-binance-delisting/45954>
+.. [#protocol-actions] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.5: Action Description Encoding and Consensus` <https://zips.z.cash/protocol/protocol.pdf#actionencodingandconsensus>
+.. [#protocol-raw-address] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.6.4.2 Orchard Raw Payment Addresses` <https://zips.z.cash/protocol/protocol.pdf#orchardpaymentaddrencoding>
+.. [#protocol-diversify-hash] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.1.6 DiversifyHashSapling and DiversifyHashOrchard Hash Functions` <https://zips.z.cash/protocol/protocol.pdf#concretediversifyhash>
+.. [#protocol-pallas-vesta] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.9.6 Pallas and Vesta` <https://zips.z.cash/protocol/protocol.pdf#pallasandvesta>
+.. [#protocol-orchard-keys] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 4.2.3 Orchard Key Components` <https://zips.z.cash/protocol/protocol.pdf#orchardkeycomponents>
+.. [#protocol-key-agreement] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.5.5 Orchard Key Agreement` <https://zips.z.cash/protocol/protocol.pdf#concreteorchardkeyagreement>
+.. [#protocol-tx-encoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 7.1 Transaction Encoding and Consensus` <https://zips.z.cash/protocol/protocol.pdf#txnencoding>
+.. [#protocol-redpallas] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. 5.4.7 RedDSA, RedJubjub, and RedPallas` <https://zips.z.cash/protocol/protocol.pdf#concretereddsa>