forked from zcash/zips
-
Notifications
You must be signed in to change notification settings - Fork 2
/
zip-0032.html
1161 lines (1161 loc) · 83.8 KB
/
zip-0032.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
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>ZIP 32: Shielded Hierarchical Deterministic Wallets</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: 32
Title: Shielded Hierarchical Deterministic Wallets
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Credits: Sean Bowe
Kris Nuttycombe
Ying Tong Lai
Pieter Wuille
Marek Palatinus
Pavol Rusnak
Status: Final
Category: Standards / Wallet
Created: 2018-05-22
License: MIT</pre>
<p>
<span class="math">\(% This ZIP makes heavy use of mathematical markup. If you can see this, you may want to instead view the rendered version at https://zips.z.cash/zip-0032 .\)</span>
</p>
<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", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#protocol-jubjub">15</a>.</p>
<p>A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">10</a>.</p>
</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 proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id4" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
<p>The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed, for the following shielded pools (which have different internal key structures):</p>
<ul>
<li>Sapling</li>
<li>Orchard</li>
</ul>
<p>Previous versions of this document also defined a similar derivation system for the Sprout shielded pool. This has been removed since it was never used, and is unlikely to be used given that <cite>zcashd</cite> no longer generates Sprout addresses (and neither <cite>Zebra</cite> nor the mobile SDKs have ever done so).</p>
<p>The last part shows how to use these trees in the context of existing BIP 44 <a id="id5" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
<p>This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses notwithstanding).</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>BIP 32 <a id="id6" class="footnote_reference" href="#bip-0032">2</a> is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses <a id="id7" class="footnote_reference" href="#slip-0044">6</a>) generate keys and addresses deterministically. This has several advantages over random generation:</p>
<ul>
<li>Wallets only need to store a single seed (particularly useful for hardware wallets).</li>
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
<li>Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.</li>
<li>Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.</li>
</ul>
<p>At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.</p>
</section>
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification <a id="id9" class="footnote_reference" href="#protocol">9</a>. They are reproduced here for convenience:</p>
<ul>
<li>
<span class="math">\(\mathsf{truncate}_k(S)\)</span>
means the sequence formed from the first
<span class="math">\(k\)</span>
elements of
<span class="math">\(S\)</span>
.</li>
<li>
<span class="math">\(a\,||\,b\)</span>
means the concatenation of sequences
<span class="math">\(a\)</span>
then
<span class="math">\(b\)</span>
.</li>
<li>
<span class="math">\([k] P\)</span>
means scalar multiplication of the elliptic curve point
<span class="math">\(P\)</span>
by the scalar
<span class="math">\(k\)</span>
.</li>
<li>
<span class="math">\(\mathsf{LEOS2IP}_\ell(S)\)</span>
is the integer in range
<span class="math">\(\{ 0\,.\!. 2^\ell - 1 \}\)</span>
represented in little-endian order by the byte sequence
<span class="math">\(S\)</span>
of length
<span class="math">\(\ell/8\)</span>
.</li>
<li>
<span class="math">\(\mathsf{I2LEBSP}_\ell(k)\)</span>
is the sequence of
<span class="math">\(\ell\)</span>
bits representing
<span class="math">\(k\)</span>
in little-endian order.</li>
<li>
<span class="math">\(\mathsf{LEBS2OSP}_\ell(B)\)</span>
is defined as follows when
<span class="math">\(\ell\)</span>
is a multiple of
<span class="math">\(8\)</span>
: convert each group of 8 bits in
<span class="math">\(B\)</span>
to a byte value with the least significant bit first, and concatenate the resulting bytes in the same order as the groups.</li>
<li>
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
is the representation of the Jubjub elliptic curve point
<span class="math">\(P\)</span>
as a bit sequence, defined in <a id="id10" class="footnote_reference" href="#protocol-jubjub">15</a>.</li>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span>
refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
<span class="math">\(p\)</span>
, and input
<span class="math">\(x\)</span>
.</li>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{512}(p, x)\)</span>
refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64 bytes, 16-byte personalization string
<span class="math">\(p\)</span>
, and input
<span class="math">\(x\)</span>
.</li>
<li>
<span class="math">\(\mathsf{PRF^{expand}}(\mathsf{sk}, t) :=\)</span>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“Zcash_ExpandSeed”},\)</span>
<span class="math">\(\mathsf{sk}\,||\,t)\)</span>
</li>
<li>
<span class="math">\(r_\mathbb{J}\)</span>
is the order of the Jubjub large prime subgroup.</li>
<li>
<span class="math">\(r_\mathbb{P}\)</span>
is the order of the Pallas curve.</li>
<li>
<span class="math">\(\mathsf{ToScalar^{Sapling}}(x) :=\)</span>
<span class="math">\(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}\)</span>
.</li>
<li>
<span class="math">\(\mathsf{ToScalar^{Orchard}}(x) :=\)</span>
<span class="math">\(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{P}}\)</span>
.</li>
<li>
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}(d)\)</span>
maps a diversifier
<span class="math">\(d\)</span>
to a base point on the Jubjub elliptic curve, or to
<span class="math">\(\bot\)</span>
if the diversifier is invalid. It is instantiated in <a id="id11" class="footnote_reference" href="#protocol-concretediversifyhash">13</a>.</li>
</ul>
<p>The following algorithm standardized in <a id="id12" class="footnote_reference" href="#nist-sp-800-38g">22</a> is used:</p>
<ul>
<li>
<span class="math">\(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\)</span>
refers to the FF1 encryption algorithm using AES with a 256-bit
<span class="math">\(key\)</span>
, and parameters
<span class="math">\(radix = 2,\)</span>
<span class="math">\(minlen = 88,\)</span>
<span class="math">\(maxlen = 88\)</span>
. It will be used only with the empty string
<span class="math">\(\texttt{“”}\)</span>
as the
<span class="math">\(tweak\)</span>
.
<span class="math">\(x\)</span>
is a sequence of 88 bits, as is the output.</li>
</ul>
<p>We also define the following conversion function:</p>
<ul>
<li>
<span class="math">\(\mathsf{I2LEOSP}_\ell(k)\)</span>
is the byte sequence
<span class="math">\(S\)</span>
of length
<span class="math">\(\ell/8\)</span>
representing in little-endian order the integer
<span class="math">\(k\)</span>
in range
<span class="math">\(\{ 0\,.\!. 2^\ell - 1 \}\)</span>
. It is the reverse operation of
<span class="math">\(\mathsf{LEOS2IP}_\ell(S)\)</span>
.</li>
</ul>
<p>Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.</p>
<p>We adapt the path notation of BIP 32 <a id="id13" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
<span class="math">\('\)</span>
) to indicate hardened derivation (
<span class="math">\(i' = i + 2^{31}\)</span>
) as in BIP 44 <a id="id14" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(\mathsf{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)\)</span>
is written as
<span class="math">\(m_\mathsf{Sapling} / a / b / c\)</span>
.</li>
</ul>
</section>
<section id="specification-sapling-key-derivation"><h2><span class="section-heading">Specification: Sapling key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-sapling-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="sapling-extended-keys"><h3><span class="section-heading">Sapling extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>BIP 32 defines a method to derive a number of child keys from a parent key. In order to prevent these from depending solely on the parent key itself, both the private and public keys are extended with a 32-byte chain code. We similarly extend Sapling keys with a chain code here. However, the concepts of "private" and "public" keys in BIP 32 do not map cleanly to Sapling's key components. We take the following approach:</p>
<ul>
<li>We derive child Sapling expanded spending keys, rather than Sapling spending keys. This enables us to implement both hardened and non-hardened derivation modes (the latter being incompatible with Sapling spending keys).</li>
<li>We do not derive Sapling public keys directly, as this would prevent the use of diversified addresses. Instead, we derive Sapling full viewing keys, from which payment addresses can be generated. This maintains the trust semantics of BIP 32: someone with access to a BIP 32 extended public key is able to view all transactions involving that address, which a Sapling full viewing key also enables.</li>
</ul>
<p>We represent a Sapling extended spending key as
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
, where
<span class="math">\((\mathsf{ask, nsk, ovk})\)</span>
is the normal Sapling expanded spending key,
<span class="math">\(\mathsf{dk}\)</span>
is a diversifier key, and
<span class="math">\(\mathsf{c}\)</span>
is the chain code.</p>
<p>We represent a Sapling extended full viewing key as
<span class="math">\((\mathsf{ak, nk, ovk, dk, c})\)</span>
, where
<span class="math">\((\mathsf{ak, nk, ovk})\)</span>
is the normal Sapling full viewing key,
<span class="math">\(\mathsf{dk}\)</span>
is the same diversifier key as above, and
<span class="math">\(\mathsf{c}\)</span>
is the chain code.</p>
</section>
<section id="sapling-helper-functions"><h3><span class="section-heading">Sapling helper functions</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-helper-functions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Define</p>
<ul>
<li>
<span class="math">\(\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk}) :=\)</span>
<span class="math">\(\mathsf{I2LEOSP}_{256}(\mathsf{ask})\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{256}(\mathsf{nsk})\)</span>
<span class="math">\(||\,\mathsf{ovk}\)</span>
<span class="math">\(||\,\mathsf{dk}\)</span>
</li>
<li>
<span class="math">\(\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=\)</span>
<span class="math">\(\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))\)</span>
<span class="math">\(||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))\)</span>
<span class="math">\(||\,\mathsf{ovk}\)</span>
<span class="math">\(||\,\mathsf{dk}\)</span>
</li>
</ul>
</section>
<section id="sapling-master-key-generation"><h3><span class="section-heading">Sapling master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-master-key-generation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Let
<span class="math">\(S\)</span>
be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.</p>
<ul>
<li>Calculate
<span class="math">\(I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Sapling”}, S)\)</span>
.</li>
<li>Split
<span class="math">\(I\)</span>
into two 32-byte sequences,
<span class="math">\(I_L\)</span>
and
<span class="math">\(I_R\)</span>
.</li>
<li>Use
<span class="math">\(I_L\)</span>
as the master spending key
<span class="math">\(\mathsf{sk}_m\)</span>
, and
<span class="math">\(I_R\)</span>
as the master chain code
<span class="math">\(\mathsf{c}_m\)</span>
.</li>
<li>Calculate
<span class="math">\(\mathsf{ask}_m\)</span>
,
<span class="math">\(\mathsf{nsk}_m\)</span>
, and
<span class="math">\(\mathsf{ovk}_m\)</span>
via the standard Sapling derivation <a id="id15" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>:
<ul>
<li>
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
</li>
<li>
<span class="math">\(\mathsf{nsk}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x01}]))\)</span>
</li>
<li>
<span class="math">\(\mathsf{ovk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x02}]))\)</span>
.</li>
</ul>
</li>
<li>Calculate
<span class="math">\(\mathsf{dk}_m\)</span>
similarly:
<ul>
<li>
<span class="math">\(\mathsf{dk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x10}]))\)</span>
.</li>
</ul>
</li>
<li>Return
<span class="math">\((\mathsf{ask}_m, \mathsf{nsk}_m, \mathsf{ovk}_m, \mathsf{dk}_m, \mathsf{c}_m)\)</span>
as the master extended spending key
<span class="math">\(m_\mathsf{Sapling}\)</span>
.</li>
</ul>
<p>Note that the master extended key is invalid if
<span class="math">\(\mathsf{ask}_m\)</span>
is
<span class="math">\(0\)</span>
, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
<section id="sapling-child-key-derivation"><h3><span class="section-heading">Sapling child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-child-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index
<span class="math">\(i\)</span>
, depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.</p>
<section id="deriving-a-child-extended-spending-key"><h4><span class="section-heading">Deriving a child extended spending key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-spending-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>
<span class="math">\(\mathsf{CDKsk}((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{ask}_i, \mathsf{nsk}_i, \mathsf{ovk}_i, \mathsf{dk}_i, \mathsf{c}_i)\)</span>
</p>
<ul>
<li>Check whether
<span class="math">\(i \geq 2^{31}\)</span>
(whether the child is a hardened key).
<ul>
<li>If so (hardened child): let
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x11}]\)</span>
<span class="math">\(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
.</li>
<li>If not (normal child): let
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]\)</span>
<span class="math">\(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
where
<span class="math">\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)</span>
is the full viewing key derived from
<span class="math">\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)</span>
as described in <a id="id17" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
</ul>
</li>
<li>Split
<span class="math">\(I\)</span>
into two 32-byte sequences,
<span class="math">\(I_L\)</span>
and
<span class="math">\(I_R\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\)</span>
.</li>
<li>Return:
<ul>
<li>
<span class="math">\(\mathsf{ask}_i = (I_\mathsf{ask} + \mathsf{ask}_{par}) \pmod{r_\mathbb{J}}\)</span>
</li>
<li>
<span class="math">\(\mathsf{nsk}_i = (I_\mathsf{nsk} + \mathsf{nsk}_{par}) \pmod{r_\mathbb{J}}\)</span>
</li>
<li>
<span class="math">\(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]\)</span>
<span class="math">\(||\,\mathsf{ovk}_{par}))\)</span>
</li>
<li>
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]\)</span>
<span class="math">\(||\,\mathsf{dk}_{par}))\)</span>
</li>
<li>
<span class="math">\(\mathsf{c}_i = I_R\)</span>
.</li>
</ul>
</li>
</ul>
<p>Note that the child extended key is invalid if
<span class="math">\(\mathsf{ask}_i\)</span>
is
<span class="math">\(0\)</span>
, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
<section id="deriving-a-child-extended-full-viewing-key"><h4><span class="section-heading">Deriving a child extended full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-full-viewing-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{G}^\mathsf{Sapling}\)</span>
be as defined in <a id="id19" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
be as defined in <a id="id20" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
<p>
<span class="math">\(\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\)</span>
</p>
<ul>
<li>Check whether
<span class="math">\(i \geq 2^{31}\)</span>
(whether the child is a hardened key).
<ul>
<li>If so (hardened child): return failure.</li>
<li>If not (normal child): let
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]\)</span>
<span class="math">\(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
.</li>
</ul>
</li>
<li>Split
<span class="math">\(I\)</span>
into two 32-byte sequences,
<span class="math">\(I_L\)</span>
and
<span class="math">\(I_R\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))\)</span>
.</li>
<li>Return:
<ul>
<li>
<span class="math">\(\mathsf{ak}_i = [I_\mathsf{ask}]\,\mathcal{G}^\mathsf{Sapling} + \mathsf{ak}_{par}\)</span>
</li>
<li>
<span class="math">\(\mathsf{nk}_i = [I_\mathsf{nsk}]\,\mathcal{H}^\mathsf{Sapling} + \mathsf{nk}_{par}\)</span>
</li>
<li>
<span class="math">\(\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]\)</span>
<span class="math">\(||\,\mathsf{ovk}_{par}))\)</span>
</li>
<li>
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]\)</span>
<span class="math">\(||\,\mathsf{dk}_{par}))\)</span>
</li>
<li>
<span class="math">\(\mathsf{c}_i = I_R\)</span>
.</li>
</ul>
</li>
</ul>
<p>Note that the child extended key is invalid if
<span class="math">\(\mathsf{ak}_i\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
</section>
<section id="sapling-internal-key-derivation"><h3><span class="section-heading">Sapling internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="id22" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
<section id="deriving-a-sapling-internal-spending-key"><h4><span class="section-heading">Deriving a Sapling internal spending key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-spending-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})\)</span>
be the external spending key.</p>
<ul>
<li>Derive the corresponding
<span class="math">\(\mathsf{ak}\)</span>
and
<span class="math">\(\mathsf{nk}\)</span>
as specified in <a id="id23" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
<li>Let
<span class="math">\(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\)</span>
.</li>
<li>Let
<span class="math">\(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\)</span>
.</li>
<li>Let
<span class="math">\(\mathsf{nsk_{internal}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}\)</span>
.</li>
<li>Split
<span class="math">\(R\)</span>
into two 32-byte sequences,
<span class="math">\(\mathsf{dk_{internal}}\)</span>
and
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
.</li>
<li>Return the internal spending key as
<span class="math">\((\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\)</span>
.</li>
</ul>
<p>Note that the child extended key is invalid if
<span class="math">\(\mathsf{ak}\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk}\)</span>
derived as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
<section id="deriving-a-sapling-internal-full-viewing-key"><h4><span class="section-heading">Deriving a Sapling internal full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-full-viewing-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
be as defined in <a id="id25" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
<p>Let
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
be the external full viewing key.</p>
<ul>
<li>Let
<span class="math">\(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))\)</span>
.</li>
<li>Let
<span class="math">\(R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])\)</span>
.</li>
<li>Let
<span class="math">\(\mathsf{nk_{internal}} = [I_\mathsf{nsk}] \mathcal{H}^\mathsf{Sapling} + \mathsf{nk}\)</span>
.</li>
<li>Split
<span class="math">\(R\)</span>
into two 32-byte sequences,
<span class="math">\(\mathsf{dk_{internal}}\)</span>
and
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
.</li>
<li>Return the internal full viewing key as
<span class="math">\((\mathsf{ak}, \mathsf{nk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})\)</span>
.</li>
</ul>
<p>This design uses the same technique as non-hardened derivation to obtain a full viewing key with the same spend authority (the private key corresponding to
<span class="math">\(\mathsf{ak}\)</span>
) as the original, but viewing authority only for internal transfers.</p>
<p>The values of
<span class="math">\(I\)</span>
,
<span class="math">\(I_\mathsf{nsk}\)</span>
, and
<span class="math">\(R\)</span>
are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:</p>
<figure class="align-center" align="center">
<img width="900px" src="zip-0032-sapling-internal-key-derivation.png" />
<figcaption>Diagram of Sapling internal key derivation</figcaption>
</figure>
<p>(For simplicity, the proof authorizing key is not shown.)</p>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id26" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>Note that the internal extended key is invalid if
<span class="math">\(\mathsf{ak}\)</span>
is the zero point of Jubjub, or if the corresponding
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
derived from the internal full viewing key as specified in <a id="id27" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
<span class="math">\(0\)</span>
.</p>
</section>
</section>
<section id="sapling-diversifier-derivation"><h3><span class="section-heading">Sapling diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-diversifier-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key
<span class="math">\(\mathsf{dk}\)</span>
. To prevent the diversifier leaking how many diversified addresses have already been generated for an account, we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we use FF1-AES256 as a Pseudo-Random Permutation as follows:</p>
<ul>
<li>Let
<span class="math">\(j\)</span>
be the index of the desired diversifier, in the range
<span class="math">\(0\,.\!. 2^{88} - 1\)</span>
.</li>
<li>
<span class="math">\(d_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\)</span>
.</li>
</ul>
<p>A valid diversifier
<span class="math">\(d_j\)</span>
is one for which
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}(d_j) \neq \bot\)</span>
. For a given
<span class="math">\(\mathsf{dk}\)</span>
, approximately half of the possible values of
<span class="math">\(j\)</span>
yield valid diversifiers.</p>
<p>The default diversifier for a Sapling extended key is defined to be
<span class="math">\(d_j\)</span>
, where
<span class="math">\(j\)</span>
is the least nonnegative integer yielding a valid diversifier.</p>
</section>
</section>
<section id="specification-orchard-key-derivation"><h2><span class="section-heading">Specification: Orchard key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-orchard-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The derivation mechanism for Sapling addresses specified above incurs significant complexity to support non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for non-hardened derivation appear. With that in mind, we only support hardened key derivation for Orchard.</p>
<section id="orchard-extended-keys"><h3><span class="section-heading">Orchard extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We represent an Orchard extended spending key as
<span class="math">\((\mathsf{sk, c}),\)</span>
where
<span class="math">\(\mathsf{sk}\)</span>
is the normal Orchard spending key (opaque 32 bytes), and
<span class="math">\(\mathsf{c}\)</span>
is the chain code.</p>
</section>
<section id="orchard-master-key-generation"><h3><span class="section-heading">Orchard master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-master-key-generation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Let
<span class="math">\(S\)</span>
be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.</p>
<ul>
<li>Calculate
<span class="math">\(I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Orchard”}, S)\)</span>
.</li>
<li>Split
<span class="math">\(I\)</span>
into two 32-byte sequences,
<span class="math">\(I_L\)</span>
and
<span class="math">\(I_R\)</span>
.</li>
<li>Use
<span class="math">\(I_L\)</span>
as the master spending key
<span class="math">\(\mathsf{sk}_m\)</span>
.</li>
<li>Use
<span class="math">\(I_R\)</span>
as the master chain code
<span class="math">\(\mathsf{c}_m\)</span>
.</li>
<li>Return
<span class="math">\((\mathsf{sk}_m, \mathsf{c}_m)\)</span>
as the master extended spending key
<span class="math">\(m_\mathsf{Orchard}\)</span>
.</li>
</ul>
</section>
<section id="orchard-child-key-derivation"><h3><span class="section-heading">Orchard child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-child-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>
<span class="math">\(\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)\)</span>
</p>
<ul>
<li>Check whether
<span class="math">\(i \geq 2^{31}\)</span>
(whether the child is a hardened key).
<ul>
<li>If so (hardened child): let
<span class="math">\(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i))\)</span>
.</li>
<li>If not (normal child): return failure.</li>
</ul>
</li>
<li>Split
<span class="math">\(I\)</span>
into two 32-byte sequences,
<span class="math">\(I_L\)</span>
and
<span class="math">\(I_R\)</span>
.</li>
<li>Use
<span class="math">\(I_L\)</span>
as the child spending key
<span class="math">\(\mathsf{sk}_{i}\)</span>
.</li>
<li>Use
<span class="math">\(I_R\)</span>
as the child chain code
<span class="math">\(\mathsf{c}_i\)</span>
.</li>
</ul>
<p>Note that the resulting child spending key may produce an invalid external FVK, as specified in <a id="id28" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.</p>
</section>
<section id="orchard-internal-key-derivation"><h3><span class="section-heading">Orchard internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As in the case of Sapling, for a given external address, we want to produce another address for use by wallets for internal operations such as change and auto-shielding. That is, for any external full viewing key we need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
<p>Let
<span class="math">\(\mathsf{ask}\)</span>
be the spend authorizing key if available, and let
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
be the corresponding external full viewing key, obtained as specified in <a id="id29" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
<p>Define
<span class="math">\(\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
as follows:</p>
<ul>
<li>Let
<span class="math">\(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
.</li>
<li>Let
<span class="math">\(\mathsf{rivk_{internal}} = \mathsf{ToScalar^{Orchard}}(\mathsf{PRF^{expand}}(K, [\mathtt{0x83}] \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{ak}) \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{nk}))\)</span>
.</li>
<li>Return
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk_{internal}})\)</span>
.</li>
</ul>
<p>The result of applying
<span class="math">\(\mathsf{DeriveInternalFVK^{Orchard}}\)</span>
to the external full viewing key is the internal full viewing key. The corresponding expanded internal spending key is
<span class="math">\((\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})\)</span>
,</p>
<p>Unlike <a href="#sapling-internal-key-derivation">Sapling internal key derivation</a>, we do not base this internal key derivation procedure on non-hardened derivation, which is not defined for Orchard. We can obtain the desired separation of viewing authority by modifying only the
<span class="math">\(\mathsf{rivk_{internal}}\)</span>
field relative to the external full viewing key, which results in different
<span class="math">\(\mathsf{dk_{internal}}\)</span>
,
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
and
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
fields being derived, as specified in <a id="id30" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
<figure class="align-center" align="center">
<img width="720px" src="zip-0032-orchard-internal-key-derivation.png" />
<figcaption>Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key</figcaption>
</figure>
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id31" class="footnote_reference" href="#zip-0316">8</a>.</p>
<p>Note that the resulting FVK may be invalid, as specified in <a id="id32" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
</section>
<section id="orchard-diversifier-derivation"><h3><span class="section-heading">Orchard diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-diversifier-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.</p>
<p>Given an Orchard extended spending key
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
:</p>
<ul>
<li>Let
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
be the Orchard full viewing key for
<span class="math">\(\mathsf{sk}_i\)</span>
.</li>
<li>Let
<span class="math">\(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
and let
<span class="math">\(B = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})\)</span>
.</li>
<li>
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(K, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(B)))\)</span>
.</li>
<li>Let
<span class="math">\(j\)</span>
be the index of the desired diversifier, in the range
<span class="math">\(0\,.\!. 2^{88} - 1\)</span>
.</li>
<li>
<span class="math">\(d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\)</span>
.</li>
</ul>
<p>Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of
<span class="math">\(j\)</span>
yield valid diversifiers.</p>
<p>The default diversifier for
<span class="math">\((\mathsf{sk}_i, \mathsf{c}_i)\)</span>
is defined to be
<span class="math">\(d_{i,0}.\)</span>
</p>
</section>
</section>
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id33" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<ul>
<li>
<span class="math">\(purpose\)</span>
: a constant set to
<span class="math">\(32'\)</span>
(or
<span class="math">\(\texttt{0x80000020}\)</span>
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
<li>
<span class="math">\(coin\_type\)</span>
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id34" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
<span class="math">\(coin\_type\)</span>
index
<span class="math">\(1\)</span>
.</li>
<li>
<span class="math">\(account\)</span>
: numbered from index
<span class="math">\(0\)</span>
in sequentially increasing manner. Defined as in BIP 44 <a id="id35" class="footnote_reference" href="#bip-0044">5</a>.</li>
</ul>
<p>Unlike BIP 44, none of the shielded key paths have a
<span class="math">\(change\)</span>
path level. The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. Shielded addresses are never publicly visible in transactions, which means that sending change back to the originating address is indistinguishable from using a change address.</p>
</section>
<section id="sapling-key-path"><h3><span class="section-heading">Sapling key path</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-key-path"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same spending authority. A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
<p>The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Sapling ZIP 32 derivation MUST support the following path for any account in range
<span class="math">\(\{ 0\,.\!. 2^{31} - 1 \}\)</span>
:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account'\)</span>
.</li>
</ul>
<p>Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier as defined above) for any account they support. They MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the user experience of giving a unique address to each recipient.</p>
<p>Note that a given account can have a maximum of approximately
<span class="math">\(2^{87}\)</span>
payment addresses, because each diversifier has around a 50% chance of being invalid.</p>
<p>If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened
<span class="math">\(address\_index\)</span>
path level as in <a id="id36" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
.</li>
</ul>
<p><cite>zcashd</cite> version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account
<span class="math">\(\mathtt{0x7FFFFFFF}\)</span>
, using hardened derivation for
<span class="math">\(address\_index\)</span>
.</p>
</section>
<section id="orchard-key-path"><h3><span class="section-heading">Orchard key path</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-key-path"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.</p>
<p>The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard ZIP 32 derivation MUST support the following path for any account in range
<span class="math">\(\{ 0\,.\!. 2^{31} - 1 \}\)</span>
:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\)</span>
.</li>
</ul>
<p>Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of diversified payment addresses for a given account, if they wish to enable users to give a unique address to each recipient.</p>
<p>Note that a given account can have a maximum of
<span class="math">\(2^{88}\)</span>
payment addresses (unlike Sapling, all Orchard diversifiers are valid).</p>
</section>
</section>
<section id="specification-fingerprints-and-tags"><h2><span class="section-heading">Specification: Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#specification-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(\mathit{FVK}\)</span>
(as specified in <a id="id37" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)</span>
.</li>
</ul>
<p>It MAY be used to uniquely identify a particular Sapling full viewing key.</p>
<p>A "Sapling full viewing key tag" is the first 4 bytes of the corresponding Sapling full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.</p>
</section>
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(\mathit{FVK}\)</span>
(as specified in <a id="id38" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\)</span>
.</li>
</ul>
<p>It MAY be used to uniquely identify a particular Orchard full viewing key.</p>
<p>An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.</p>
</section>
<section id="seed-fingerprints"><h3><span class="section-heading">Seed Fingerprints</span><span class="section-anchor"> <a rel="bookmark" href="#seed-fingerprints"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "seed fingerprint" for the master seed
<span class="math">\(S\)</span>
of a hierarchical deterministic wallet is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_HD_Seed_FP”},\)</span>
<span class="math">\([\mathsf{length}(S)]\,||\,S)\)</span>
.</li>
</ul>
<p>It MAY be used to uniquely identify a particular hierarchical deterministic wallet.</p>
<p>No corresponding short tag is defined.</p>
<p>Note: a previous version of this specification did not have the length byte prefixing the seed. The current specification reflects the implementation in <cite>zcashd</cite>.</p>
</section>
</section>
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a rel="bookmark" href="#specification-key-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id39" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
<section id="sapling-extended-spending-keys"><h3><span class="section-heading">Sapling extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-spending-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Sapling extended spending key
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
, at depth
<span class="math">\(depth\)</span>
, with parent full viewing key tag
<span class="math">\(parent\_fvk\_tag\)</span>
and child number
<span class="math">\(i\)</span>
, is represented as a byte sequence:</p>
<ul>
<li>
<span class="math">\(\mathsf{I2LEOSP}_{8}(depth)\)</span>
<span class="math">\(||\,parent\_fvk\_tag\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i)\)</span>
<span class="math">\(||\,\mathsf{c}\)</span>
<span class="math">\(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk})\)</span>
.</li>
</ul>
<p>For the master extended spending key,
<span class="math">\(depth\)</span>
is
<span class="math">\(0\)</span>
,
<span class="math">\(parent\_fvk\_tag\)</span>
is 4 zero bytes, and
<span class="math">\(i\)</span>
is
<span class="math">\(0\)</span>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-extended-key-main</code> for the production network, or <code>secret-extended-key-test</code> for the test network.</p>
</section>
<section id="sapling-extended-full-viewing-keys"><h3><span class="section-heading">Sapling extended full viewing keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-full-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Sapling extended full viewing key
<span class="math">\((\mathsf{ak, nk, ovk, dk, c})\)</span>
, at depth
<span class="math">\(depth\)</span>
, with parent full viewing key tag
<span class="math">\(parent\_fvk\_tag\)</span>
and child number
<span class="math">\(i\)</span>
, is represented as a byte sequence:</p>
<ul>
<li>
<span class="math">\(\mathsf{I2LEOSP}_{8}(depth)\)</span>
<span class="math">\(||\,parent\_fvk\_tag\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i)\)</span>
<span class="math">\(||\,\mathsf{c}\)</span>
<span class="math">\(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk})\)</span>
.</li>
</ul>
<p>For the master extended full viewing key,
<span class="math">\(depth\)</span>
is
<span class="math">\(0\)</span>
,
<span class="math">\(parent\_fvk\_tag\)</span>
is 4 zero bytes, and
<span class="math">\(i\)</span>
is
<span class="math">\(0\)</span>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>zxviews</code> for the production network, or <code>zxviewtestsapling</code> for the test network.</p>
</section>
<section id="orchard-extended-spending-keys"><h3><span class="section-heading">Orchard extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-extended-spending-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An Orchard extended spending key
<span class="math">\((\mathsf{sk, c})\)</span>
, at depth
<span class="math">\(depth\)</span>
, with parent full viewing key tag
<span class="math">\(parent\_fvk\_tag\)</span>
and child number
<span class="math">\(i\)</span>
, is represented as a byte sequence:</p>
<ul>
<li>
<span class="math">\(\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}\)</span>
.</li>
</ul>
<p>For the master extended spending key,
<span class="math">\(depth\)</span>
is
<span class="math">\(0\)</span>
,
<span class="math">\(parent\_fvk\_tag\)</span>
is 4 zero bytes, and
<span class="math">\(i\)</span>
is
<span class="math">\(0\)</span>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-orchard-extsk-main</code> for Mainnet, or <code>secret-orchard-extsk-test</code> for Testnet.</p>
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id40" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
</section>
</section>
<section id="values-reserved-due-to-previous-specification-for-sprout"><h2><span class="section-heading">Values reserved due to previous specification for Sprout</span><span class="section-anchor"> <a rel="bookmark" href="#values-reserved-due-to-previous-specification-for-sprout"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following values were previously used in the specification of hierarchical derivation for Sprout, and therefore SHOULD NOT be used in future Zcash-related specifications:</p>
<ul>
<li>the
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{512}\)</span>
personalization
<span class="math">\(\texttt{“ZcashIP32_Sprout”}\)</span>
, formerly specified for derivation of the master key of the Sprout tree;</li>
<li>the
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}\)</span>
personalization
<span class="math">\(\texttt{“Zcash_Sprout_AFP”}\)</span>
, formerly specified for generation of Sprout address fingerprints;</li>
<li>the
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
prefix
<span class="math">\(\texttt{0x80}\)</span>
, formerly specified for Sprout child key derivation;</li>
<li>the Bech32 Human-Readable Parts <code>zxsprout</code> and <code>zxtestsprout</code>, formerly specified for Sprout extended spending keys on Mainnet and Testnet respectively.</li>
</ul>
</section>
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBC</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>
<ul>
<li><a href="https://github.com/zcash-hackworks/zip32">https://github.com/zcash-hackworks/zip32</a></li>
<li><a href="https://github.com/zcash/librustzcash/pull/29">https://github.com/zcash/librustzcash/pull/29</a></li>
<li><a href="https://github.com/zcash/zcash/pull/3447">https://github.com/zcash/zcash/pull/3447</a></li>
<li><a href="https://github.com/zcash/zcash/pull/3492">https://github.com/zcash/zcash/pull/3492</a></li>
</ul>
</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="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="bip-0032" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">BIP 32: Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="bip-0039" class="footnote">
<tbody>
<tr>