forked from zcash/zips
-
Notifications
You must be signed in to change notification settings - Fork 0
/
zip-0212.html
485 lines (485 loc) · 37.6 KB
/
zip-0212.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
<!DOCTYPE html>
<html>
<head>
<title>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 212
Title: Allow Recipient to Derive Ephemeral Secret from Note Plaintext
Owners: Sean Bowe <[email protected]>
Status: Final
Category: Consensus
Created: 2019-03-31
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
<p>The following functions are defined in the Zcash Protocol Specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol">2</a> according to the type (Sapling or Orchard) of note plaintext being processed:</p>
<ul>
<li>let
<span class="math">\(\mathsf{ToScalar}\)</span>
be
<span class="math">\(\mathsf{ToScalar^{Sapling}}\)</span>
defined in section 4.2.2 <a id="footnote-reference-3" class="footnote_reference" href="#protocol-saplingkeycomponents">5</a> or
<span class="math">\(\mathsf{ToScalar^{Orchard}}\)</span>
defined in section 4.2.3 <a id="footnote-reference-4" class="footnote_reference" href="#protocol-orchardkeycomponents">6</a>;</li>
<li>let
<span class="math">\(\mathsf{DiversifyHash}\)</span>
be
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}\)</span>
or
<span class="math">\(\mathsf{DiversifyHash^{Orchard}}\)</span>
defined in section 5.4.1.6 <a id="footnote-reference-5" class="footnote_reference" href="#protocol-concretediversifyhash">12</a>;</li>
<li>let
<span class="math">\(\mathsf{KA}\)</span>
be
<span class="math">\(\mathsf{KA^{Sapling}}\)</span>
defined in section 5.4.5.3 <a id="footnote-reference-6" class="footnote_reference" href="#protocol-concretesaplingkeyagreement">13</a> or
<span class="math">\(\mathsf{KA^{Orchard}}\)</span>
defined in section 5.4.5.5 <a id="footnote-reference-7" class="footnote_reference" href="#protocol-concreteorchardkeyagreement">14</a>;</li>
<li>let
<span class="math">\(\mathsf{NoteCommit}\)</span>
be
<span class="math">\(\mathsf{NoteCommit^{Sapling}}\)</span>
or
<span class="math">\(\mathsf{NoteCommit^{Orchard}}\)</span>
defined in section 4.1.8 <a id="footnote-reference-8" class="footnote_reference" href="#protocol-abstractcommit">4</a>.</li>
</ul>
</section>
<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>
<p>This ZIP proposes a new note plaintext format for Sapling Outputs (later extended to include Orchard Actions) in transactions. The new format allows recipients to verify that the sender of an Output or Action knows the private key corresponding to the ephemeral Diffie–Hellman key, in order to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.</p>
</section>
<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>
<p>The Sapling and Orchard payment protocols have a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.</p>
<p>The feature works by allowing payment addresses to become a tuple
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
of a public key
<span class="math">\(\mathsf{pk_d}\)</span>
and
<span class="math">\(88\!\)</span>
-bit diversifier
<span class="math">\(\mathsf{d}\)</span>
such that
<span class="math">\(\mathsf{pk_d} = [\mathsf{ivk}]\, \mathsf{DiversifyHash}(\mathsf{d})\)</span>
for some incoming viewing key
<span class="math">\(\mathsf{ivk}\!\)</span>
. The hash function
<span class="math">\(\mathsf{DiversifyHash}(\mathsf{d})\)</span>
maps from a diversifier to prime-order elements of the Jubjub or Pallas elliptic curve. It is possible for a user to choose many
<span class="math">\(\mathsf{d}\)</span>
to create several distinct and unlinkable payment addresses of this form.</p>
<p>In order to make a payment to a Sapling or Orchard address, an ephemeral secret
<span class="math">\(\mathsf{esk}\)</span>
is sampled by the sender and an ephemeral public key
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{DiversifyHash}(\mathsf{d})\)</span>
is included in the Output or Action description. Then, a shared Diffie-Hellman secret is computed by the sender as
<span class="math">\(\mathsf{KA.Agree}(\mathsf{esk}, \mathsf{pk_d})\!\)</span>
. The recipient can recover this shared secret without knowledge of the particular
<span class="math">\(\mathsf{d}\)</span>
by computing
<span class="math">\(\mathsf{KA.Agree}(\mathsf{ivk}, \mathsf{epk})\!\)</span>
. This shared secret is then used as part of note decryption.</p>
<p>Naïvely, the recipient cannot know which
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
was used to compute the shared secret, but the sender is asked to include the
<span class="math">\(\mathsf{d}\)</span>
within the note plaintext to reconstruct the note. However, if the recipient has more than one known address, an attacker could use a different payment address to perform secret exchange and, by observing the behavior of the recipient, link the two diversified addresses together. (This attacker strategy was discovered by Brian Warner earlier in the design of the Sapling protocol.)</p>
<p>In order to prevent this attack before activation of this ZIP, the protocol forced the sender to prove knowledge of the discrete logarithm of
<span class="math">\(\mathsf{epk}\)</span>
with respect to the
<span class="math">\(\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})\)</span>
included within the note commitment. This
<span class="math">\(\mathsf{g_d}\)</span>
is determined by
<span class="math">\(\mathsf{d}\)</span>
and recomputed during note decryption, and so either the note decryption will fail, or the sender will be unable to produce the proof that requires knowledge of the discrete logarithm.</p>
<p>However, the latter proof was part of the Sapling Output statement, and so relied on the soundness of the underlying Groth16 zk-SNARK — hence on relatively strong cryptographic assumptions and a trusted setup. It is preferable to force the sender to transfer sufficient information in the note plaintext to allow deriving
<span class="math">\(\mathsf{esk}\!\)</span>
, so that, during note decryption, the recipient can check that
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
for the expected
<span class="math">\(\mathsf{g_d}\!\)</span>
, and ignore the payment as invalid otherwise. For Sapling, this forms a line of defense in the case that soundness of the zk-SNARK does not hold. For Orchard, this check is essential because (for efficiency and simplicity)
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
is <em>not</em> checked in the Action statement.</p>
<p>Merely sending
<span class="math">\(\mathsf{esk}\)</span>
to the recipient in the note plaintext would require us to enlarge the note plaintext, but also would compromise the proof of IND-CCA2 security for in-band secret distribution. We avoid both of these concerns by using a key derivation to obtain both
<span class="math">\(\mathsf{esk}\)</span>
and
<span class="math">\(\mathsf{rcm}\!\)</span>
.</p>
</section>
<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>
<aside class="note">
<p>The specification in this ZIP is intended to be aligned with version 2023.4.0 or later of the Zcash Protocol Specification <a id="footnote-reference-9" class="footnote_reference" href="#protocol">2</a>, and with the deployed implementations in <code>librustzcash</code> and the <code>orchard</code> crate.</p>
<p>Please note that prior versions of the protocol specification (2022.3.8 and earlier) were inconsistent with this ZIP regarding the domain separators for
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
used to derive
<span class="math">\(\mathsf{rcm}\)</span>
and
<span class="math">\(\mathsf{esk}\!\)</span>
. The protocol specification diverged from the deployed implementations for Sapling, and this ZIP previously (before December 2023) diverged from the deployed implementations for Orchard.</p>
</aside>
<p>Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification <a id="footnote-reference-10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
for the purposes of this ZIP. This function is keyed by a 256-bit key
<span class="math">\(\mathsf{sk}\)</span>
and takes an arbitrary length byte sequence as input, returning a
<span class="math">\(64\!\)</span>
-byte sequence as output.</p>
<section id="changes-to-sapling-and-orchard-note-plaintexts"><h3><span class="section-heading">Changes to Sapling and Orchard Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-and-orchard-note-plaintexts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="footnote-reference-11" class="footnote_reference" href="#protocol-notept">15</a>. Before activation of this ZIP, the encoding of a Sapling note plaintext required that the first byte take the form
<span class="math">\(\mathtt{0x01}\!\)</span>
, indicating the version of the note plaintext. In addition, a
<span class="math">\(256\!\)</span>
-bit
<span class="math">\(\mathsf{rcm}\)</span>
field exists within the note plaintext and encoding.</p>
<p>Following the activation of this ZIP, senders of Sapling or Orchard notes MUST use the following note plaintext format:</p>
<ul>
<li>The first byte of the encoding MUST take the form
<span class="math">\(\mathtt{0x02}\)</span>
(representing the new note plaintext version).</li>
<li>The field
<span class="math">\(\mathsf{rcm}\)</span>
of the encoding is renamed to
<span class="math">\(\mathsf{rseed}\!\)</span>
. This field
<span class="math">\(\mathsf{rseed}\)</span>
of the Sapling or Orchard note plaintext no longer takes the type of
<span class="math">\(\mathsf{NoteCommit.Trapdoor}\)</span>
(as it did for Sapling) but instead is a
<span class="math">\(32\!\)</span>
-byte sequence.</li>
</ul>
<p>The requirement that the former
<span class="math">\(\mathsf{rcm}\)</span>
field be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from descriptions of note plaintexts in the Zcash Protocol Specification.</p>
</section>
<section id="changes-to-the-process-of-sending-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of sending Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling <a id="footnote-reference-12" class="footnote_reference" href="#protocol-saplingsend">7</a> and section 4.7.3 for Orchard <a id="footnote-reference-13" class="footnote_reference" href="#protocol-orchardsend">8</a>. In addition, the process of encrypting a note is described in section 4.19.1 of the Zcash Protocol Specification <a id="footnote-reference-14" class="footnote_reference" href="#protocol-saplingandorchardencrypt">9</a>. Prior to activation of this ZIP, the sender sampled
<span class="math">\(\mathsf{rcm^{new}}\)</span>
and the ephemeral private key
<span class="math">\(\mathsf{esk}\)</span>
uniformly at random during this process.</p>
<p>After the activation of this ZIP, the sender MUST instead sample a uniformly random
<span class="math">\(32\!\)</span>
-byte sequence
<span class="math">\(\mathsf{rseed}\!\)</span>
. The note plaintext takes
<span class="math">\(\mathsf{rseed}\)</span>
in place of
<span class="math">\(\mathsf{rcm^{new}}\!\)</span>
.</p>
<p>For Sapling:</p>
<ul>
<li>
<span class="math">\(\mathsf{rcm^{new}}\)</span>
MUST be derived as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\!\)</span>
.</li>
<li>
<span class="math">\(\mathsf{esk}\)</span>
MUST be derived as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\!\)</span>
.</li>
</ul>
<p>For Orchard:</p>
<ul>
<li>
<span class="math">\(\mathsf{rcm^{new}}\)</span>
MUST be derived as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5] \,||\, \underline{\text{ρ}}))\!\)</span>
.</li>
<li>
<span class="math">\(\mathsf{esk}\)</span>
MUST be derived as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4] \,||\, \underline{\text{ρ}}))\!\)</span>
.</li>
<li>
<span class="math">\(\text{φ}\)</span>
MUST be derived as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([9] \,||\, \underline{\text{ρ}}))\!\)</span>
.</li>
</ul>
<p>where
<span class="math">\(\underline{\text{ρ}} = \mathsf{I2LEOSP}_{256}(\mathsf{nf^{old}}\)</span>
from the same Action description
<span class="math">\(\!)\!\)</span>
.</p>
<aside class="note">
<p>The domain separators
<span class="math">\([4]\)</span>
and
<span class="math">\([5]\)</span>
used in the input to
<span class="math">\(\mathsf{PRF^{expand}_{rseed}}\)</span>
are swapped for Orchard relative to Sapling. This was due to an oversight and there is no good reason for it.</p>
<p>The specified domain separators were corrected to match the deployed implementations in <code>librustzcash</code> and the <code>orchard</code> crate in version 2023.4.0 of the Zcash Protocol Specification, and in this ZIP from December 2023.</p>
</aside>
</section>
<section id="changes-to-the-process-of-receiving-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of receiving notes in Sapling is described in sections 4.19.2 and 4.19.3 of the Zcash Protocol Specification. <a id="footnote-reference-15" class="footnote_reference" href="#protocol-decryptivk">10</a> <a id="footnote-reference-16" class="footnote_reference" href="#protocol-decryptovk">11</a></p>
<p>There is a "grace period" of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte
<span class="math">\(\mathtt{0x01}\)</span>
MUST still be accepted.</p>
<p>Let ActivationHeight be the activation height of this ZIP, and let GracePeriodEndHeight be ActivationHeight + 32256.</p>
<p>The height of a transaction in a mined block is defined as the height of that block. An implementation MAY also decrypt mempool transactions, in which case the height used is the height of the next block at the time of the check. An implementation SHOULD NOT attempt to decrypt mempool transactions without having obtained a best-effort view of the current block chain height.</p>
<p>When the recipient of a note (either using an incoming viewing key or a full viewing key) is able to decrypt a note plaintext, it performs the following check on the plaintext lead byte, based on the height of the containing transaction:</p>
<ul>
<li>If the height is less than ActivationHeight, then only
<span class="math">\(\mathtt{0x01}\)</span>
is accepted as the plaintext lead byte.</li>
<li>If the height is at least ActivationHeight and less than GracePeriodEndHeight, then either
<span class="math">\(\mathtt{0x01}\)</span>
or
<span class="math">\(\mathtt{0x02}\)</span>
is accepted as the plaintext lead byte.</li>
<li>If the height is at least GracePeriodEndHeight, then only
<span class="math">\(\mathtt{0x02}\)</span>
is accepted as the plaintext lead byte.</li>
</ul>
<p>If the plaintext lead byte is not accepted then the note MUST be discarded. However, if an implementation decrypted the note from a mempool transaction and it was accepted at that time, but it is later mined in a block after the end of the grace period, then it MAY be retained.</p>
<p>A note plaintext with lead byte
<span class="math">\(\mathtt{0x02}\)</span>
contains a field
<span class="math">\(\mathsf{rseed}\)</span>
that is a
<span class="math">\(32\!\)</span>
-byte sequence rather than a scalar value
<span class="math">\(\mathsf{rcm}\!\)</span>
. The recipient, during decryption and in any later contexts, will derive
<span class="math">\(\mathsf{rcm}\)</span>
using
<span class="math">\(\mathsf{PRF^{expand}_{rseed}}\)</span>
in the same way as the sender, as described in <a href="#changes-to-the-process-of-sending-sapling-or-orchard-notes">Changes to the process of sending Sapling or Orchard notes</a>. Further, the recipient MUST derive
<span class="math">\(\mathsf{esk}\)</span>
as described in that section and check that
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\!\)</span>
, failing decryption if this check is not satisfied.</p>
</section>
<section id="consensus-rule-change-for-coinbase-transactions"><h3><span class="section-heading">Consensus rule change for coinbase transactions</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rule-change-for-coinbase-transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <a id="footnote-reference-17" class="footnote_reference" href="#zip-0213">17</a>, MUST have note plaintext lead byte equal to
<span class="math">\(\mathtt{0x02}\!\)</span>
.</p>
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="footnote-reference-18" class="footnote_reference" href="#zip-0207">16</a> sent to shielded payment addresses, if there are any.</p>
<p>Since NU5 activates after the end of the grace period <a id="footnote-reference-19" class="footnote_reference" href="#zip-0252">19</a>, Orchard outputs will always require a note plaintext lead byte equal to
<span class="math">\(\mathtt{0x02}\!\)</span>
.</p>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The attack that this prevents is an interactive attack that requires an adversary to be able to break critical soundness properties of the zk-SNARKs underlying Sapling. It is potentially valid to assume that this cannot occur, due to other damaging effects on the system such as undetectable counterfeiting. However, we have attempted to avoid any instance in the protocol where privacy (even against interactive attacks) depended on strong cryptographic assumptions. Acting differently here would be confusing for users that have previously been told that "privacy does not depend on zk-SNARK soundness" or similar claims.</p>
<p>It would have been possible to infringe on the length of the <code>memo</code> field and ask the sender to provide
<span class="math">\(\mathsf{esk}\)</span>
within the existing note plaintext without modifying the transaction format, but this would have harmed users who have come to expect a
<span class="math">\(512\!\)</span>
-byte memo field to be available to them. Changes to the memo field length should be considered in a broader context than changes made for cryptographic purposes.</p>
<p>It would be possible to transmit a signature of knowledge of a correct
<span class="math">\(\mathsf{esk}\)</span>
rather than
<span class="math">\(\mathsf{esk}\)</span>
itself, but this appears to be an unnecessary complication and is likely slower than just supplying
<span class="math">\(\mathsf{esk}\!\)</span>
.</p>
<p>The grace period is intended to mitigate loss-of-funds risk due to non-conformant sending wallet implementations. The intention is that during the grace period (of about 4 weeks), it will be possible to identify wallets that are still sending plaintexts according to the old specification, and cajole their developers to make the required updates. For the avoidance of doubt, such wallets are non-conformant because it is a "MUST" requirement to <em>immediately</em> switch to sending note plaintexts with lead byte
<span class="math">\(\mathtt{0x02}\)</span>
(and the other changes in this specification) at the upgrade. Note that nodes will clear their mempools when the upgrade activates, which will clear all plaintexts with lead byte
<span class="math">\(\mathtt{0x01}\)</span>
that were sent conformantly and not mined before the upgrade.</p>
<p>Historical note: in practice some note plaintexts with lead byte
<span class="math">\(\mathtt{0x01}\)</span>
were non-conformantly sent even after the end of the specified grace period. ZecWallet extended its implementation of the grace period by a further 161280 blocks (approximately 20 weeks) in order to allow for recovery of these funds <a id="footnote-reference-20" class="footnote_reference" href="#zecwallet-grace-extension">20</a>.</p>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub (or Pallas) elliptic curve, for it could perform a linkability attack trivially in that case.</p>
<p>In the naïve case where the protocol is modified so that
<span class="math">\(\mathsf{esk}\)</span>
is supplied directly to the recipient (rather than derived through
<span class="math">\(\mathsf{rseed}\!\)</span>
) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Canopy network upgrade. <a id="footnote-reference-21" class="footnote_reference" href="#zip-0251">18</a></p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In zcashd:</p>
<ul>
<li><a href="https://github.com/zcash/zcash/pull/4578">https://github.com/zcash/zcash/pull/4578</a></li>
</ul>
<p>In librustzcash:</p>
<ul>
<li><a href="https://github.com/zcash/librustzcash/pull/258">https://github.com/zcash/librustzcash/pull/258</a></li>
</ul>
</section>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The discovery that diversified address unlinkability depended on the zk-SNARK knowledge assumption was made by Sean Bowe and Zooko Wilcox.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="bcp14" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/info/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"</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2023.4.0 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-abstractprfs" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#abstractprfs">Zcash Protocol Specification, Version 2023.4.0. Section 4.1.2: Pseudo Random Functions</a></td>
</tr>
</tbody>
</table>
<table id="protocol-abstractcommit" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#abstractcommit">Zcash Protocol Specification, Version 2023.4.0. Section 4.1.8: Commitment</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingkeycomponents" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2023.4.0. Section 4.2.2: Sapling Key Components</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardkeycomponents" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingsend" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2023.4.0. Section 4.7.2: Sending Notes (Sapling)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardsend" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2023.4.0. Section 4.7.3: Sending Notes (Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingandorchardencrypt" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/protocol.pdf#saplingandorchardencrypt">Zcash Protocol Specification, Version 2023.4.0. Section 4.19.1: Encryption (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-decryptivk" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/protocol.pdf#decryptivk">Zcash Protocol Specification, Version 2023.4.0. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-decryptovk" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/protocol.pdf#decryptovk">Zcash Protocol Specification, Version 2023.4.0. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretediversifyhash" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2023.4.0. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretesaplingkeyagreement" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/protocol.pdf#concretesaplingkeyagreement">Zcash Protocol Specification, Version 2023.4.0. Section 5.4.5.3 Sapling Key Agreement</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concreteorchardkeyagreement" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/protocol.pdf#concreteorchardkeyagreement">Zcash Protocol Specification, Version 2023.4.0. Section 5.4.5.5 Orchard Key Agreement</a></td>
</tr>
</tbody>
</table>
<table id="protocol-notept" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="protocol/protocol.pdf#notept">Zcash Protocol Specification, Version 2023.4.0. Section 5.5: Encodings of Note Plaintexts and Memo Fields</a></td>
</tr>
</tbody>
</table>
<table id="zip-0207" class="footnote">
<tbody>
<tr>
<th>16</th>
<td><a href="zip-0207">ZIP 207: Split Founders' Reward</a></td>
</tr>
</tbody>
</table>
<table id="zip-0213" class="footnote">
<tbody>
<tr>
<th>17</th>
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
</tr>
</tbody>
</table>
<table id="zip-0251" class="footnote">
<tbody>
<tr>
<th>18</th>
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0252" class="footnote">
<tbody>
<tr>
<th>19</th>
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zecwallet-grace-extension" class="footnote">
<tbody>
<tr>
<th>20</th>
<td><a href="https://github.com/adityapk00/librustzcash/commit/c31a04a4dbfa5a2ac013139db229f41cd421754d">Commit c31a04a in aditypk00/librustzcash: Move ZIP-212 grace period to end of April</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>