forked from zcash/zips
-
Notifications
You must be signed in to change notification settings - Fork 0
/
zip-0032.html
1090 lines (1090 loc) · 75.9 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: 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" 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">13</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.11 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">9</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" 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>Sprout (for compatibility, effectively unused)</li>
<li>Orchard</li>
</ul>
<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" 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>View authority or spend 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" 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">8</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">13</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">\(\mathsf{ToScalar}(x) :=\)</span>
<span class="math">\(\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}\)</span>
.</li>
<li>
<span class="math">\(\mathsf{DiversifyHash}(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">11</a>.</li>
</ul>
<p>The following algorithm standardized in <a id="id12" class="footnote_reference" href="#nist-sp-800-38g">20</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{CDKsk}(\mathsf{CDKsk}(\mathsf{CDKsk}(m_\mathsf{Sprout}, a'), b), c)\)</span>
is written as
<span class="math">\(m_\mathsf{Sprout} / a' / b / c\)</span>
</li>
<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" 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" 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" 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" 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">10</a>:
<ul>
<li>
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
</li>
<li>
<span class="math">\(\mathsf{nsk}_m = \mathsf{ToScalar}(\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>
</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" 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" 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="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">10</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}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar}(\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>
</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" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Let
<span class="math">\(\mathcal{G}\)</span>
be as defined in <a id="id17" class="footnote_reference" href="#protocol-concretespendauthsig">12</a> and let
<span class="math">\(\mathcal{H}\)</span>
be as defined in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">10</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}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))\)</span>
.</li>
<li>Let
<span class="math">\(I_\mathsf{nsk} = \mathsf{ToScalar}(\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{ak}_{par}\)</span>
</li>
<li>
<span class="math">\(\mathsf{nk}_i = [I_\mathsf{nsk}]\,\mathcal{H} + \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>
</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" 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}(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-sprout-key-derivation"><h2><span class="section-heading">Specification: Sprout key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#specification-sprout-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>For completeness, we define a system for deriving a tree of Sprout key components. It is unlikely that this will garner much usage once Sapling activates, but is presented for those users who may require it.</p>
<section id="sprout-extended-keys"><h3><span class="section-heading">Sprout extended keys</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-extended-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Due to the way Sprout keys are constructed and used, it is not possible to derive incoming viewing keys or payment addresses in parallel with spending keys. Nor is it possible to implement non-hardened derivation. We therefore only define and derive Sprout extended spending keys.</p>
<p>We represent a Sprout extended spending key as
<span class="math">\((\mathsf{a_{sk}, c})\)</span>
, where
<span class="math">\(\mathsf{a_{sk}}\)</span>
is the normal Sprout spending key, and
<span class="math">\(\mathsf{c}\)</span>
is the chain code.</p>
</section>
<section id="sprout-helper-functions"><h3><span class="section-heading">Sprout helper functions</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-helper-functions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Let
<span class="math">\(\mathsf{EncodeASK}(\mathsf{a_{sk}})\)</span>
be the 32-byte encoding of
<span class="math">\(\mathsf{a_{sk}}\)</span>
in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in <a id="id19" class="footnote_reference" href="#protocol-sproutspendingkeyencoding">15</a>.</p>
<p>Let
<span class="math">\(\mathsf{DecodeASK}(ASK)\)</span>
be the result of clearing the 4 most significant bits of the first byte of
<span class="math">\(ASK\)</span>
, and decoding the 32-byte result according to the inverse of
<span class="math">\(\mathsf{EncodeASK}\)</span>
.</p>
</section>
<section id="sprout-master-key-generation"><h3><span class="section-heading">Sprout master key generation</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-master-key-generation"><img width="24" height="24" 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{“ZcashIP32_Sprout”}, 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">\(\mathsf{DecodeASK}(I_L)\)</span>
as the master spending key
<span class="math">\(\mathsf{a}_{\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>
</ul>
</section>
<section id="sprout-child-key-derivation"><h3><span class="section-heading">Sprout child key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-child-key-derivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>
<span class="math">\(\mathsf{CDKsk}((\mathsf{a}_{\mathsf{sk},par}, \mathsf{c}_{par}), i)\)</span>
<span class="math">\(\rightarrow (\mathsf{a}_{\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{0x80}]\)</span>
<span class="math">\(||\,\mathsf{EncodeASK}(\mathsf{a}_{\mathsf{sk},par})\)</span>
<span class="math">\(||\,\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">\(\mathsf{DecodeASK}(I_L)\)</span>
as the child spending key
<span class="math">\(\mathsf{a}_{\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>
</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" 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 define Orchard key derivation very similarly to Sprout above: only hardened derivation is supported.</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" 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" 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" 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>
</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" 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">\(\mathsf{K} = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
and let
<span class="math">\(\mathsf{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}}(\mathsf{K}, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(\mathsf{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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id20" 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" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sprout, 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 cybercoin 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="id21" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cybercoin 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="id22" 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" 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="id23" 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>
</section>
<section id="sprout-key-path"><h3><span class="section-heading">Sprout key path</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Wallets implementing Sprout ZIP 32 derivation MUST support the following path:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sprout} / purpose' / coin\_type' / account' / address\_index\)</span>
.</li>
</ul>
</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" 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" 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" 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="id24" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">16</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="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
<span class="math">\(\mathit{ADDR}\)</span>
(as specified in <a id="id25" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">14</a>, including the lead bytes) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})\)</span>
.</li>
</ul>
<p>It MAY be used to uniquely identify a particular Sprout payment address.</p>
<p>A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address fingerprint. It is intended for optimizing performance of address lookups, and MUST NOT be assumed to uniquely identify a particular address.</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" 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="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</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" 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" 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="id27" 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" 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" 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="sprout-extended-spending-keys"><h3><span class="section-heading">Sprout extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Sprout extended spending key
<span class="math">\((\mathsf{a_{sk}, c})\)</span>
, at depth
<span class="math">\(depth\)</span>
, with parent address tag
<span class="math">\(parent\_addr\_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\_addr\_tag\)</span>
<span class="math">\(||\,\mathsf{I2LEOSP}_{32}(i)\)</span>
<span class="math">\(||\,\mathsf{c}\)</span>
<span class="math">\(||\,\mathsf{EncodeASK}(\mathsf{a_{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\_addr\_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>zxsprout</code> for the production network, or <code>zxtestsprout</code> for the test network. Sprout extended spending keys are encoded using Bech32 even though other Sprout keys and addresses are encoded using Base58Check.</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" 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="id28" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">19</a>.</p>
</section>
</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" 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" 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" 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>
<th>3</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki">BIP 39: Mnemonic code for generating deterministic keys</a></td>
</tr>
</tbody>
</table>
<table id="bip-0043" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki">BIP 43: Purpose Field for Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="bip-0044" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki">BIP 44: Multi-Account Hierarchy for Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="slip-0044" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://github.com/satoshilabs/slips/blob/master/slip-0044.md">SLIP 44: Registered coin types for BIP-0044</a></td>
</tr>
</tbody>
</table>
<table id="bip-0173" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki">BIP 173: Base32 address format for native v0-16 witness outputs</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2020.1.24 or later [NU5 proposal]</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingkeycomponents" class="footnote">
<tbody>