|
26 | 26 | <p>The terms "Asset" and "ZSA" in this document are to be interpreted as described in ZIP 227 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0227">5</a>.</p> |
27 | 27 | </section> |
28 | 28 | <section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2> |
29 | | - <p>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.</p> |
| 29 | + <p>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.</p> |
30 | 30 | </section> |
31 | 31 | <section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2> |
32 | 32 | <p>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.</p> |
|
57 | 57 | <section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2> |
58 | 58 | <p>Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following.</p> |
59 | 59 | <section id="approval-signature"><h3><span class="section-heading">Approval Signature</span><span class="section-anchor"> <a rel="bookmark" href="#approval-signature"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3> |
60 | | - <p>Given the Orchard address of the recipient of the output note of an Orchard Action (in the form: |
61 | | - <span class="math">\(d | pk_d\!\)</span> |
62 | | - , see <a id="footnote-reference-7" class="footnote_reference" href="#protocol-raw-address">9</a>), and given that |
63 | | - <span class="math">\(g_d\)</span> |
64 | | - is a Pallas curve point, derived from |
65 | | - <span class="math">\(d\)</span> |
66 | | - (see <a id="footnote-reference-8" class="footnote_reference" href="#protocol-diversify-hash">10</a>) - the approval signature derivation goes as follows:</p> |
| 60 | + <p>Let |
| 61 | + <span class="math">\((\mathsf{d}, \mathsf{pk_d})\)</span> |
| 62 | + be the Orchard shielded payment address of the recipient of the output note of an Orchard Action <a id="footnote-reference-7" class="footnote_reference" href="#protocol-raw-address">9</a>. Let |
| 63 | + <span class="math">\(\mathsf{g_d}\)</span> |
| 64 | + be derived from the diversifier |
| 65 | + <span class="math">\(\mathsf{d}\)</span> |
| 66 | + as in §5.4.1.6 of the protocol specification <a id="footnote-reference-8" class="footnote_reference" href="#protocol-diversify-hash">10</a>. The approval signature is derived as follows:</p> |
67 | 67 | <ol type="1"> |
68 | 68 | <li>The sender sends the |
69 | | - <span class="math">\(OrchardActionDescription\)</span> |
| 69 | + <span class="math">\(\mathtt{OrchardActionDescription}\)</span> |
70 | 70 | (the preimage of the message to be signed, as per <a id="footnote-reference-9" class="footnote_reference" href="#protocol-actions">8</a>) for the recipient to sign.</li> |
71 | 71 | <li> |
72 | 72 | <dl> |
73 | 73 | <dt>The recipient executes the following steps:</dt> |
74 | 74 | <dd> |
75 | 75 | <ul> |
76 | 76 | <li> |
77 | | - <span class="math">\(m \gets H(OrchardActionDescription)\)</span> |
| 77 | + <span class="math">\(m \gets H(\mathtt{OrchardActionDescription})\)</span> |
78 | 78 | </li> |
79 | 79 | <li> |
80 | 80 | <span class="math">\(r \overset{R}{\leftarrow} \mathbb{Z}_{r_{\mathbb{P}}}\!\)</span> |
81 | 81 | , where |
82 | 82 | <span class="math">\(\mathbb{Z}_{r_{\mathbb{P}}}\)</span> |
83 | 83 | is the scalar field of Pallas <a id="footnote-reference-10" class="footnote_reference" href="#protocol-pallas-vesta">11</a>, and where |
84 | 84 | <span class="math">\(\overset{R}{\leftarrow}\)</span> |
85 | | - denotes a variable assignment uniformly at random from a given set.</li> |
| 85 | + denotes a variable assignment uniformly at random from a given set <a id="footnote-reference-11" class="footnote_reference" href="#protocol-notation">16</a>.</li> |
86 | 86 | <li> |
87 | | - <span class="math">\(u \gets [r]g_d\!\)</span> |
88 | | - , a Pallas point</li> |
| 87 | + <span class="math">\(u \gets [r] \mathsf{g_d}\)</span> |
| 88 | + </li> |
89 | 89 | <li> |
90 | | - <span class="math">\(C \gets H(g_d, pk_d, u, m) \mod r_{\mathbb{P}}\!\)</span> |
| 90 | + <span class="math">\(C \gets H(g_d || pk_d || u || m) \mod r_{\mathbb{P}}\!\)</span> |
91 | 91 | , an element of Pallas' scalar field, and where |
92 | 92 | <span class="math">\(H\)</span> |
93 | 93 | is a secure hash function (e.g. SHA256 or Blake2)</li> |
94 | 94 | <li> |
95 | | - <span class="math">\(s \gets r + C * ivk \mod r_{\mathbb{P}}\!\)</span> |
| 95 | + <span class="math">\(s \gets r + C \cdot \mathsf{ivk} \mod r_{\mathbb{P}}\!\)</span> |
96 | 96 | , an element of Pallas' scalar field</li> |
97 | 97 | <li> |
98 | 98 | <span class="math">\(\sigma_{approval} \gets (u, s)\)</span> |
|
113 | 113 | <section id="rationale-for-approval-signature"><h4><span class="section-heading">Rationale for Approval Signature</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-approval-signature"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4> |
114 | 114 | <p>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.</p> |
115 | 115 | <p>To achieve this, we look into the key structure of Zcash Orchard. We know that the Orchard address is of the form: |
116 | | - <span class="math">\(d | pk_d\!\)</span> |
| 116 | + <span class="math">\((\mathsf{d}, \mathsf{pk_d})\!\)</span> |
117 | 117 | . These 2 fields, the diversifier and the diversified address, are used by the sender when sending notes.</p> |
118 | 118 | <p>Looking at the Orchard key components derivations, we know that |
119 | | - <span class="math">\(pk_d\)</span> |
| 119 | + <span class="math">\(\mathsf{pk_d}\)</span> |
120 | 120 | is derived as: |
121 | | - <span class="math">\(pk_d := KAOrchard.DerivePublic(ivk, g_d) = [ivk]g_d\!\)</span> |
122 | | - , see <a id="footnote-reference-11" class="footnote_reference" href="#protocol-orchard-keys">12</a> and <a id="footnote-reference-12" class="footnote_reference" href="#protocol-key-agreement">13</a></p> |
| 121 | + <span class="math">\(\mathsf{pk_d} =mathsf{KAOrchard.DerivePublic}(\mathsf{ivk}, \mathsf{g_d}) = [\mathsf{ivk}]\mathsf{g_d}\)</span> |
| 122 | + [#protocol-orchard-keys]_```</p> |
123 | 123 | <p>Given that |
124 | | - <span class="math">\(ivk\)</span> |
| 124 | + <span class="math">\(\mathsf{ivk}\)</span> |
125 | 125 | 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 |
126 | | - <span class="math">\(ivk\!\)</span> |
| 126 | + <span class="math">\(\mathsf{ivk}\!\)</span> |
127 | 127 | . Such proof of knowledge of |
128 | | - <span class="math">\(ivk\)</span> |
| 128 | + <span class="math">\(\mathsf{ivk}\)</span> |
129 | 129 | can be obtained by using the Non-Interactive Schnorr Protocol.</p> |
130 | 130 | <p>In fact, such proof of knowledge of |
131 | | - <span class="math">\(ivk\)</span> |
| 131 | + <span class="math">\(\mathsf{ivk}\)</span> |
132 | 132 | can be obtained by using a Schnorr Signature on the Action (the message) with |
133 | | - <span class="math">\(ivk\)</span> |
| 133 | + <span class="math">\(\mathsf{ivk}\)</span> |
134 | 134 | as signing/secret key and |
135 | | - <span class="math">\(g_d\)</span> |
| 135 | + <span class="math">\(\mathsf{g_d}\)</span> |
136 | 136 | as group generator.</p> |
137 | | - <p><strong>Note:</strong> Zcash Orchard already uses a Schnorr-based signature scheme instantiated with the Pallas curve (see RedPallas <a id="footnote-reference-13" class="footnote_reference" href="#protocol-redpallas">15</a>). As of NU6, RedPallas is used to instantiate |
| 137 | + <p><strong>Note:</strong> Zcash Orchard already uses a Schnorr-based signature scheme instantiated with the Pallas curve, |
| 138 | + <span class="math">\(\mathsf{RedPallas}\)</span> |
| 139 | + <a id="footnote-reference-12" class="footnote_reference" href="#protocol-redpallas">15</a>. As of NU6, RedPallas is used to instantiate |
138 | 140 | <span class="math">\(SpendAuthSig^{Orchard}\)</span> |
139 | 141 | and |
140 | 142 | <span class="math">\(BindingSig^{Orchard}\!\)</span> |
|
149 | 151 | <span class="math">\(\sigma_{approval}\)</span> |
150 | 152 | </li> |
151 | 153 | <li> |
152 | | - <span class="math">\(OrchardActionDescription\)</span> |
| 154 | + <span class="math">\(\mathtt{OrchardActionDescription}\)</span> |
153 | 155 | </li> |
154 | 156 | </ul> |
155 | 157 | <p>Witness:</p> |
|
164 | 166 | <p>Circuit:</p> |
165 | 167 | <ul> |
166 | 168 | <li> |
167 | | - <span class="math">\(C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(OrchardActionDescription))\)</span> |
| 169 | + <span class="math">\(C’ \gets H(g_d || pk_d || \sigma_{approval}.u || H(\mathtt{OrchardActionDescription}))\)</span> |
168 | 170 | </li> |
169 | 171 | <li> |
170 | 172 | <span class="math">\(LHS \gets [\sigma_{approval}.s]g_d\)</span> |
|
192 | 194 | <p>In this case, the Zcash miners could verify the recipient's approval by doing (for each Action in the transaction):</p> |
193 | 195 | <ol type="1"> |
194 | 196 | <li> |
195 | | - <span class="math">\(C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(OrchardActionDescription))\)</span> |
| 197 | + <span class="math">\(C’ \gets H(g_d, pk_d, \sigma_{approval}.u, H(\mathtt{OrchardActionDescription}))\)</span> |
196 | 198 | </li> |
197 | 199 | <li> |
198 | 200 | <span class="math">\(LHS \gets [\sigma_{approval}.sigma]g_d\)</span> |
|
234 | 236 | </section> |
235 | 237 | </section> |
236 | 238 | <section id="modifications-to-the-transaction-format"><h3><span class="section-heading">Modifications to the Transaction Format</span><span class="section-anchor"> <a rel="bookmark" href="#modifications-to-the-transaction-format"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3> |
237 | | - <p>In order to support this ZIP, the transaction format, as specified in <a id="footnote-reference-14" class="footnote_reference" href="#protocol-tx-encoding">14</a>, must be extended to add the approval signatures, as follows:</p> |
| 239 | + <p>In order to support this ZIP, the transaction format, as specified in <a id="footnote-reference-13" class="footnote_reference" href="#protocol-tx-encoding">14</a>, must be extended to add the approval signatures, as follows:</p> |
238 | 240 | <table> |
239 | 241 | <thead> |
240 | 242 | <tr> |
|
264 | 266 | <ol type="1"> |
265 | 267 | <li>Block a payment and deny to have received the "approval request", then accuse the sender to have failed to settle a contractual obligation.</li> |
266 | 268 | <li>Gain information: By receiving the |
267 | | - <span class="math">\(OrchardActionDescription\)</span> |
| 269 | + <span class="math">\(\mathtt{OrchardActionDescription}\)</span> |
268 | 270 | to approve, recipients gets to see the |
269 | 271 | <span class="math">\(nullifier\)</span> |
270 | 272 | of the input note of the Orchard Action before the rest of the network.</li> |
|
392 | 394 | </tr> |
393 | 395 | </tbody> |
394 | 396 | </table> |
| 397 | + <table id="protocol-notation" class="footnote"> |
| 398 | + <tbody> |
| 399 | + <tr> |
| 400 | + <th>16</th> |
| 401 | + <td><cite>Zcash Protocol Specification, Version 2024.5.1 [NU6]. 2 Notation</cite> <<a href="https://zips.z.cash/protocol/protocol.pdf#notation">https://zips.z.cash/protocol/protocol.pdf#notation</a>></td> |
| 402 | + </tr> |
| 403 | + </tbody> |
| 404 | + </table> |
395 | 405 | </section> |
396 | 406 | </section> |
397 | 407 | </body> |
|
0 commit comments