Compare commits
1989 Commits
2018.0-bet
...
master
Author | SHA1 | Date |
---|---|---|
|
4966a64340 | |
|
3152ed67b0 | |
|
54359a8809 | |
|
5980676b05 | |
|
fcf78b974c | |
|
22370345a1 | |
|
87c5aca5f3 | |
|
69939334f0 | |
|
5618352447 | |
|
e2ccfc11b2 | |
|
30ee914674 | |
|
43c9df8ba6 | |
|
57f2abf5bd | |
|
b4761037a4 | |
|
1be8793401 | |
|
9db08c218f | |
|
adce640cb0 | |
|
7fe898c231 | |
|
a02401a61e | |
|
e84ce9423f | |
|
840674803f | |
|
984c14da9e | |
|
8bc9244a47 | |
|
8d9b70b0e4 | |
|
2336f6f345 | |
|
b12bb61103 | |
|
17042258cd | |
|
22b7191bc3 | |
|
a0767f42fe | |
|
32870a93af | |
|
a25f2b92a7 | |
|
ffc0ed95fa | |
|
1905603579 | |
|
43f1404974 | |
|
78f61ebc25 | |
|
e4ed372840 | |
|
aec1fef7cd | |
|
ed82b5bf85 | |
|
be7df83b10 | |
|
2d2508d06c | |
|
dbd7339c3f | |
|
0c53d8815f | |
|
9000614a63 | |
|
11b44b4490 | |
|
3c3da6d6dc | |
|
deafb410de | |
|
99b881e8f2 | |
|
d9ab7909ec | |
|
fb223c206d | |
|
b870363ae6 | |
|
d4324bb8cb | |
|
ae1180f6d3 | |
|
5aabc86e21 | |
|
9a742b3e6c | |
|
aa084d4c89 | |
|
bc9427282a | |
|
12ff90a307 | |
|
0f84a7234e | |
|
2d538c4888 | |
|
dec7e4423b | |
|
34c0c8212b | |
|
a223dfd931 | |
|
f6e044429d | |
|
a5a3ffa19c | |
|
6b8fca949c | |
|
634e274df6 | |
|
c7ad527f38 | |
|
5d3b4ef038 | |
|
e381ded490 | |
|
e123584794 | |
|
c506a972ac | |
|
8f77f6f1df | |
|
27f5bb1e68 | |
|
5c7c728e63 | |
|
a2efd493bb | |
|
c94c2a5517 | |
|
6bf7703684 | |
|
28a3404ce0 | |
|
0275b41fb0 | |
|
73dc201033 | |
|
ba9137def1 | |
|
f56cf0d38e | |
|
81af218ef3 | |
|
0bfb157db3 | |
|
dba647f121 | |
|
8e2215c577 | |
|
2a4ab049b9 | |
|
7bd2845dbd | |
|
de6dcad4df | |
|
4075c18cc4 | |
|
43c8cae266 | |
|
8734965d0c | |
|
df0f9e6bee | |
|
8b8b3f7c5d | |
|
c562b100f8 | |
|
ca302f40ef | |
|
2b5c860df5 | |
|
61223ae9b0 | |
|
d27d2fd836 | |
|
4683507160 | |
|
7b70d343b7 | |
|
79e6a10f0a | |
|
98515d003f | |
|
d2b0f2d861 | |
|
82c59282fe | |
|
81858fff41 | |
|
6c32c7c7ea | |
|
dcc5532d61 | |
|
24cfab0b55 | |
|
4ef578706b | |
|
0cdab5071b | |
|
ac9dd97f77 | |
|
2ae8fc6cec | |
|
1b30e57bde | |
|
509b7a2b0c | |
|
8e74c62a21 | |
|
9e12b49e03 | |
|
aef6aad4fc | |
|
0ada3050af | |
|
3ba7b5f246 | |
|
30ff9f6ddb | |
|
a3a86b4a44 | |
|
bdfe15bb3f | |
|
2671741042 | |
|
68b6147c02 | |
|
89f46c2d99 | |
|
c2585a4fc9 | |
|
daac926497 | |
|
2442192519 | |
|
8572075604 | |
|
02adb44328 | |
|
b57f6d1487 | |
|
cf1995c2ed | |
|
59a220d59e | |
|
b6e00e0d41 | |
|
1571c1b345 | |
|
75ae51c6b2 | |
|
ae78770474 | |
|
cfba8e4c59 | |
|
abb898f484 | |
|
dfd7a5a561 | |
|
ee70cc53c3 | |
|
1d75ed6548 | |
|
200e243e14 | |
|
fbad8acac0 | |
|
2d5159361e | |
|
b7e69cc10a | |
|
e8df7fbb65 | |
|
06b945bfe7 | |
|
22840e1fc5 | |
|
1a59063e81 | |
|
227db1e047 | |
|
12a1678681 | |
|
4a23875519 | |
|
96c5ad3f69 | |
|
110fe1a84e | |
|
682308e33b | |
|
0db40ef927 | |
|
d325f0b3b4 | |
|
0e83a55a05 | |
|
208d9b39c1 | |
|
026977744c | |
|
78b7d8489f | |
|
dfdb4242f5 | |
|
9a4df93e97 | |
|
5c402793c3 | |
|
880bf02301 | |
|
b85a249a59 | |
|
4d0477ce5f | |
|
4d536ff421 | |
|
9dbe0a50f7 | |
|
ea53ac9d6f | |
|
c3dac4e458 | |
|
82c4e49155 | |
|
d6a33fc056 | |
|
67a4b35dcd | |
|
eab1ef1a1a | |
|
36252cebf6 | |
|
089a9cb8be | |
|
4da403f470 | |
|
e539eeb9a8 | |
|
49df75d888 | |
|
2398e1e012 | |
|
474330a8f4 | |
|
d1909fb05a | |
|
52abb0c609 | |
|
5ced374bf1 | |
|
1ac6d917b8 | |
|
feb864b672 | |
|
b1a707e963 | |
|
bab61e8ecf | |
|
97fa264611 | |
|
7bf094e827 | |
|
06706937d5 | |
|
b8f83aac4b | |
|
5688e5cbbd | |
|
d4cddc0615 | |
|
a31336c9c6 | |
|
f8529b3186 | |
|
96277a1a14 | |
|
39998c226c | |
|
0e057c3c8c | |
|
17229163f9 | |
|
067befbb08 | |
|
a00006d7bd | |
|
ed4ba8d38b | |
|
2d20028ecf | |
|
460c5b2ccc | |
|
d6a32d4757 | |
|
986b9dedfe | |
|
0c14637429 | |
|
cf0219cd67 | |
|
6611f7a245 | |
|
043672cc07 | |
|
e309225495 | |
|
49faaafe4d | |
|
9c47cbe6ec | |
|
763a9cdd4f | |
|
f4cb2806a7 | |
|
2630966bc4 | |
|
db418a5dd5 | |
|
195b8147eb | |
|
4af8a9684d | |
|
e4c68a0e7a | |
|
d12f31bbb9 | |
|
14326d0f9a | |
|
dcb4c4e89a | |
|
c871d448ce | |
|
21f384dcda | |
|
a5c4f139c9 | |
|
a918bbc6d7 | |
|
0d2b01e602 | |
|
b7f0a0bd0d | |
|
324c9ae7b9 | |
|
7e5272e70b | |
|
42e05529a4 | |
|
93e5ec04fe | |
|
7dc6682326 | |
|
e179eb88c7 | |
|
fc6e752b05 | |
|
a9fa1f4d18 | |
|
955a81e9bd | |
|
40bf218f1b | |
|
acf3d949eb | |
|
df6aff4313 | |
|
11b8688a1d | |
|
784c889d00 | |
|
57e0f6035d | |
|
9d61bec954 | |
|
e77ba6bbf0 | |
|
473306e4d0 | |
|
b5e5276c4a | |
|
3ebba2652a | |
|
8f8ef49618 | |
|
01dbecefea | |
|
219a4ef253 | |
|
8718157af0 | |
|
b2e0184fe5 | |
|
cdb30d10ca | |
|
88bc08b6e3 | |
|
0ae051226e | |
|
045a3a9e54 | |
|
a6fd0153d2 | |
|
8b8761b302 | |
|
1aefc848bf | |
|
cecfb9b0e4 | |
|
411f39e231 | |
|
5e0769d295 | |
|
5d98ec714a | |
|
8c510a1415 | |
|
36e2059de0 | |
|
ffd97926a8 | |
|
e628134536 | |
|
819761ef67 | |
|
8c7b2f2a95 | |
|
0ad0d3d57a | |
|
f97ef3ae72 | |
|
65ff47a022 | |
|
fed2bc0438 | |
|
af1bee056f | |
|
9d6fa7d8ec | |
|
f0858810a2 | |
|
fb83397ad7 | |
|
2814e00a1a | |
|
4821afe9ba | |
|
172573e686 | |
|
55052e4e54 | |
|
3f9ede243b | |
|
7102635fc6 | |
|
3159602dfc | |
|
1ed8e47d56 | |
|
0b7aeae33e | |
|
c33e23e0c2 | |
|
a39618ff66 | |
|
bcb9845f00 | |
|
076af3f055 | |
|
75e2ae585d | |
|
7f04e327ad | |
|
b3aad58459 | |
|
4c118b813e | |
|
9eec2ec378 | |
|
27dc2a5fc4 | |
|
671451008a | |
|
b4928747cc | |
|
c6247f4bd5 | |
|
ca6d988177 | |
|
3d5f16a0a5 | |
|
33c7ac6b3f | |
|
4e138b244e | |
|
ab2ec000c2 | |
|
38fe5c3b10 | |
|
e433e8ae4e | |
|
aec18d6aa8 | |
|
dea48add07 | |
|
00074e8084 | |
|
048c1bf24c | |
|
7a8b12d945 | |
|
ad8bd025b1 | |
|
5503f766fd | |
|
4ca7409f6f | |
|
5dff090737 | |
|
f31b335fe9 | |
|
6055cca71e | |
|
1fd7c73f68 | |
|
7421696ffa | |
|
1458078183 | |
|
9dba127d7c | |
|
721dd2483f | |
|
ea0f196a92 | |
|
09f944d90c | |
|
321eed99b4 | |
|
6e6fd1605e | |
|
a893eca4d9 | |
|
4fbf8e5da2 | |
|
5a87ccd87d | |
|
604c40a5c0 | |
|
f0c438de9b | |
|
814ad87b40 | |
|
cc71722eca | |
|
ebd54d5ad6 | |
|
d25f3c1f47 | |
|
7d2480648a | |
|
0a985b9c13 | |
|
106e73e461 | |
|
e3667dc30d | |
|
577bb20832 | |
|
8f3f36fef5 | |
|
ccaa100141 | |
|
99e5d92843 | |
|
c4b65c39cc | |
|
9bc46070f3 | |
|
5fa8a60b08 | |
|
6a0c15df29 | |
|
f4a0a1284e | |
|
9e2938b555 | |
|
530f00e150 | |
|
5a925a44fe | |
|
cbf2878cbe | |
|
ce13aeb945 | |
|
15457d4198 | |
|
35f42b8a49 | |
|
c63b6c9c42 | |
|
2f7954abc3 | |
|
5b5dd20516 | |
|
72d37b803c | |
|
e81037731b | |
|
43b03a7a98 | |
|
4ff6ec345f | |
|
6ec85a6014 | |
|
587e8f7e70 | |
|
f15f263023 | |
|
1b5786ea38 | |
|
864e1eaa8d | |
|
50e4914b01 | |
|
a756260c05 | |
|
16f48e70d2 | |
|
b4386f93b8 | |
|
44ad348ce6 | |
|
c3f48359e6 | |
|
572a0d6e4f | |
|
0ab0bcb7cb | |
|
eb5a018396 | |
|
b6e50f8252 | |
|
e7ec658413 | |
|
c90528fa5c | |
|
9f948307cf | |
|
67cea8589a | |
|
c5589648c1 | |
|
79d1a477db | |
|
3f3195eb5c | |
|
2b520f41f9 | |
|
97aa1be78e | |
|
9ccd44743f | |
|
12fa6ffa8e | |
|
8d21457112 | |
|
8e6b15e9e9 | |
|
0cda82ce0f | |
|
6b1db880c8 | |
|
f42dfd4260 | |
|
935b3ea767 | |
|
615a4e0505 | |
|
becbec175c | |
|
0bc4726a79 | |
|
d023ef8220 | |
|
622179e574 | |
|
e9430c3752 | |
|
74c83f6d59 | |
|
205b2f5861 | |
|
d0caaa2ee9 | |
|
330254c9ca | |
|
296b8e6543 | |
|
1db1224657 | |
|
4353accc0e | |
|
e4af6e42a0 | |
|
639a554a04 | |
|
d7bd67900a | |
|
00c39b73e0 | |
|
38b740aad2 | |
|
4804f6040e | |
|
748e6f8f37 | |
|
35c8af6e47 | |
|
58add67726 | |
|
2cf14204ae | |
|
ac16945288 | |
|
3034a2a662 | |
|
adc28d2bb1 | |
|
c9470820b7 | |
|
f22a6d4151 | |
|
eea56aa173 | |
|
419c7e4ff4 | |
|
b30e1b6568 | |
|
528eb6685d | |
|
36643173bf | |
|
b7e72d020c | |
|
3246eddc69 | |
|
4dfd956819 | |
|
4f391743ab | |
|
76c8a4689a | |
|
4f590fb8cd | |
|
21d3c13d4f | |
|
71a19e7484 | |
|
27aa7c484a | |
|
ecba2451bc | |
|
4dbf2f02d4 | |
|
710fee607a | |
|
10710d92a6 | |
|
9a1334a454 | |
|
89f5a20d6d | |
|
827637cc17 | |
|
1e955a803a | |
|
0168ce7ec3 | |
|
24957b6745 | |
|
6caaca962d | |
|
cec980b004 | |
|
95f596ea16 | |
|
fbdbead6d5 | |
|
f4a3b99589 | |
|
3de014d33c | |
|
cb141ac91e | |
|
4c081eaa54 | |
|
ef5f47ca08 | |
|
2e6cdb3945 | |
|
0cfeea2ecb | |
|
1c46e9aa5d | |
|
c4d7331191 | |
|
65590101a8 | |
|
3d230f8d26 | |
|
15d59f11c4 | |
|
119abe37c3 | |
|
1df0f60deb | |
|
65ebb2266d | |
|
572338f01a | |
|
20053e286c | |
|
151e8c9661 | |
|
fb9c5514bd | |
|
761485e6c6 | |
|
e23cc72ac6 | |
|
88c338b9e1 | |
|
18fbfdefe5 | |
|
cc9c41a598 | |
|
1f041f955a | |
|
4f50d5e515 | |
|
46fefcaf56 | |
|
e4cc1f7f82 | |
|
db3b2f72d4 | |
|
404248cb92 | |
|
a0d048ed1e | |
|
417076e50d | |
|
1eec1f9832 | |
|
49f3b206f5 | |
|
41580ec06d | |
|
c367a22098 | |
|
3a312dc5a9 | |
|
6c3099843d | |
|
3826d43930 | |
|
de0bc97bb2 | |
|
bb985e039a | |
|
ec6c10fc5c | |
|
6c8f9fb478 | |
|
e1f105eaa1 | |
|
3a55af9b1f | |
|
7bfdce2d6a | |
|
1097313feb | |
|
cce172ace8 | |
|
f45b6b5d66 | |
|
ecb2ccd3f4 | |
|
0eca13f809 | |
|
89596379ff | |
|
e0b08fd576 | |
|
1bed047c0e | |
|
c9f9d0b36b | |
|
31e8b03491 | |
|
b0c65971d7 | |
|
0dd2982ec3 | |
|
6ecba03a2a | |
|
f7461d62e5 | |
|
e936a21a6b | |
|
02fd26fc1f | |
|
64484cb945 | |
|
0d67dcf681 | |
|
5c6ab07f15 | |
|
37479f7a11 | |
|
b16cf169e4 | |
|
306c575b87 | |
|
17818f0b32 | |
|
96efd54702 | |
|
4b2af700ef | |
|
f202b83a9d | |
|
e4bc6ad354 | |
|
b0180c76f8 | |
|
d713d35f54 | |
|
0f427feb5b | |
|
f66887cdee | |
|
3898e2f571 | |
|
b4aac633f4 | |
|
17a6a72974 | |
|
2f246ce24d | |
|
aa86282e16 | |
|
c50bdbd9ce | |
|
b27213dfd3 | |
|
cd1b4de8f9 | |
|
74dfa80194 | |
|
4d3204b8e1 | |
|
bbc6131f29 | |
|
212fdc8752 | |
|
5e55821889 | |
|
55af963e53 | |
|
eff39611f8 | |
|
3d386eeec0 | |
|
5fef9270e2 | |
|
bfc6a8e33c | |
|
a68c7d24d0 | |
|
fa2b1c6ce9 | |
|
ab0e248036 | |
|
9d62142142 | |
|
5d15a3d91e | |
|
7ccbf44c30 | |
|
4d983aa855 | |
|
e5336bb536 | |
|
8f1ff76417 | |
|
591c7e45cc | |
|
2e50a09e97 | |
|
b7d61884e1 | |
|
c11c329beb | |
|
20478ae40d | |
|
b14c332910 | |
|
54a0894acf | |
|
02db965036 | |
|
41afbd3c66 | |
|
7752911cb6 | |
|
14b975622b | |
|
2ec19b5fcc | |
|
44c45004df | |
|
218196f8dd | |
|
e1bdfce3bc | |
|
75b94ce063 | |
|
00864688d2 | |
|
75a8a944d4 | |
|
a859014b98 | |
|
781ec6896d | |
|
3e160d6ecb | |
|
9af5978852 | |
|
78e3d68539 | |
|
ed81c92365 | |
|
de694d4509 | |
|
eecb7dc43e | |
|
4e32c8da28 | |
|
2cbfb93ac9 | |
|
14fa0591c7 | |
|
a4e93decc7 | |
|
8ac3fa19ea | |
|
45d6cdc3d8 | |
|
ebe3800b2b | |
|
f0fa13761e | |
|
3b558b2146 | |
|
c5c34cf93c | |
|
0b8a4b3d90 | |
|
e31f33c678 | |
|
867d0cc712 | |
|
c9b918a654 | |
|
17518632e1 | |
|
0dfe5df5e3 | |
|
9ab9857bba | |
|
6abc86fb98 | |
|
09597dd1ee | |
|
9627ad7c49 | |
|
fbddfafef4 | |
|
cec8b904c5 | |
|
36074af67b | |
|
27a39088d6 | |
|
bed110f816 | |
|
ad032d456a | |
|
37d8221c4d | |
|
d79de34b4a | |
|
7cc31111bb | |
|
f6fb3c80d7 | |
|
6ac5901a42 | |
|
dae8852187 | |
|
e62d57959e | |
|
6453611314 | |
|
68cb4c6d5f | |
|
a81cfdb693 | |
|
ad9c631ee0 | |
|
6215dce577 | |
|
0b6faf673d | |
|
300df42bf3 | |
|
c2c4160151 | |
|
7cf44fe6bc | |
|
b336b8936d | |
|
18d30f3f82 | |
|
1c663f53cd | |
|
5df826f0f6 | |
|
65ce3b9c55 | |
|
58b4f05984 | |
|
4e2e7a64e8 | |
|
7e21ab57ac | |
|
45e175512e | |
|
81136fe7ab | |
|
559291b192 | |
|
f06f5539d8 | |
|
e95695d3bf | |
|
9a4b2e9afe | |
|
0fc45a53ca | |
|
ecec91883b | |
|
62c31fda89 | |
|
e40bb506ab | |
|
e79401a10c | |
|
dd8b82f567 | |
|
9cae4aeedc | |
|
95ea11de9d | |
|
2ae31ccdb7 | |
|
6fa961877c | |
|
630280869e | |
|
2961726557 | |
|
6631754e19 | |
|
9fd129ff86 | |
|
ca326ab40e | |
|
f2eb24ae6e | |
|
7350f94b0e | |
|
8a1fd5f469 | |
|
b18bc9eeb5 | |
|
cfc8b116fd | |
|
a55581bae5 | |
|
286af0335c | |
|
35b04b3115 | |
|
98bfb28fe7 | |
|
c0632d26a3 | |
|
2318a5c823 | |
|
faf27e276d | |
|
ed25876e21 | |
|
96b8fd1e35 | |
|
9663e146a9 | |
|
62dca39483 | |
|
afc3ae4d1b | |
|
65026436b7 | |
|
267bced55a | |
|
1dbc893db5 | |
|
98982f63a7 | |
|
5b5b6c2759 | |
|
52e448556b | |
|
ab71570ad7 | |
|
3e2310d017 | |
|
2834b6d2ae | |
|
143dc209a8 | |
|
28a9136d70 | |
|
0b63982042 | |
|
3baafb5d50 | |
|
d2c1d9b910 | |
|
c075253206 | |
|
a6ea584c0b | |
|
2fae6cdb3b | |
|
5a92818183 | |
|
368890ae8f | |
|
4b5ce259d1 | |
|
feda12fab6 | |
|
d610b8ca17 | |
|
566be18f40 | |
|
a779c1043d | |
|
c4a863096c | |
|
acf88b883c | |
|
fd63a498f2 | |
|
506c3d0df3 | |
|
cdb7144519 | |
|
62331bbbb6 | |
|
a424153462 | |
|
4b8a78c51b | |
|
90e83ad754 | |
|
4da60ce58b | |
|
862f0e8ed0 | |
|
7f7bf5f04b | |
|
3bc233bafb | |
|
e3729e8e7c | |
|
7558c6995d | |
|
7fbe3780d9 | |
|
c693ab88bd | |
|
56dd669368 | |
|
c689a58731 | |
|
becda9c543 | |
|
08fcc0c1f0 | |
|
08faa9f8f8 | |
|
e1558317bb | |
|
05f86c7cc5 | |
|
381b67a650 | |
|
71e90991e8 | |
|
cfe018c3b3 | |
|
4f1ce394fe | |
|
894c979a3d | |
|
adced97391 | |
|
6dc375e9ec | |
|
9bc9823a23 | |
|
3751c9973d | |
|
a5b78961f4 | |
|
0bd8580d1a | |
|
1ddc19ffaa | |
|
34de56533f | |
|
1556f34277 | |
|
68527a38c6 | |
|
8abbcbf33f | |
|
62eaddbd8f | |
|
6f34b9fed2 | |
|
1bb2f5fab8 | |
|
ec7d7928f1 | |
|
744aca3136 | |
|
d62bf4065f | |
|
4a36917e50 | |
|
3a2adec658 | |
|
0aa739fd43 | |
|
4051868b09 | |
|
67bbc459cb | |
|
755d79f4f2 | |
|
79afded365 | |
|
8639b3e3da | |
|
ba7eb97b04 | |
|
38d0a8c95f | |
|
2dae307127 | |
|
1b4698c960 | |
|
730d2b45b0 | |
|
6bb093a0ec | |
|
fc3f63a5ae | |
|
9b321cf200 | |
|
c02bb0cf8b | |
|
147cae0059 | |
|
ea4ff4b713 | |
|
5ec589fb9b | |
|
842d1e3d00 | |
|
dc52b7e6e6 | |
|
8049d103dc | |
|
4210404693 | |
|
0795dd67cf | |
|
9e663595eb | |
|
549403dad5 | |
|
a39730ce76 | |
|
ccef71edef | |
|
adaf4cf84a | |
|
ccbb876fe8 | |
|
f4c6935530 | |
|
bd1e9b2631 | |
|
bb2acb6c14 | |
|
05a6e97aab | |
|
a62c68a5ec | |
|
0973905d60 | |
|
3cf9d11da8 | |
|
4b33cd97cf | |
|
3eb098fb26 | |
|
a492c3a4bb | |
|
8382a31fae | |
|
c05613af27 | |
|
947f0b6649 | |
|
a3189affb2 | |
|
ec045af263 | |
|
1ea9859e14 | |
|
9a4ebc97ba | |
|
8c289078cb | |
|
806076c48c | |
|
8b311e9651 | |
|
ca17b7f5f2 | |
|
6f2a534deb | |
|
03e57714c1 | |
|
ef94502ba3 | |
|
1d30b9fe88 | |
|
c762d1ca67 | |
|
c136527758 | |
|
3274aa10de | |
|
9a8f72c5e3 | |
|
7999296d7d | |
|
6e3c173538 | |
|
c278c2f93a | |
|
9257be1d1f | |
|
917dbf5c46 | |
|
94ec65564c | |
|
71cee89a18 | |
|
775b5f3b5d | |
|
9c9ad74fad | |
|
0ed38ec775 | |
|
a5db85828c | |
|
924fd97422 | |
|
85b8f1647b | |
|
2f75f92fea | |
|
901f807125 | |
|
a34ef1a152 | |
|
07c18efafc | |
|
ff8d70ae6f | |
|
8095727eaf | |
|
6f94cb6b70 | |
|
2c5ab50526 | |
|
9a6f61bc95 | |
|
6aa2e03ef6 | |
|
18e8643953 | |
|
da9e9af6ef | |
|
3a72b4cf60 | |
|
e63f046675 | |
|
b7f9fbb06b | |
|
e72404eeaf | |
|
482f0267ed | |
|
03675c4c4a | |
|
b4fc3dcb9e | |
|
15f8fb70ac | |
|
3327bdd2dc | |
|
9d6684aa5b | |
|
b882644b01 | |
|
cbbc1f9d4c | |
|
c41d94d53d | |
|
8c4e0b5e14 | |
|
b7c849f85c | |
|
ebe3839640 | |
|
e82757b7a6 | |
|
45f7c632d2 | |
|
a9a78b6e3d | |
|
eee512bda4 | |
|
c195d8877b | |
|
bc6a1a0554 | |
|
099c389046 | |
|
bcfafc268d | |
|
5e15a53b22 | |
|
9cc2a8200d | |
|
eab1de360a | |
|
87659ef23b | |
|
b3355cc2f2 | |
|
061b212274 | |
|
374a3fb812 | |
|
48830325ce | |
|
6317563dbd | |
|
794e8a88f7 | |
|
d572d086f5 | |
|
42a707193c | |
|
fb73913e1d | |
|
1102c225e6 | |
|
fe0c5a294c | |
|
042cf998cb | |
|
1b1e4d3808 | |
|
64d75e3643 | |
|
b3f1e773ee | |
|
23fee236a4 | |
|
aa4c219af4 | |
|
b39847f3db | |
|
4df4efa9bc | |
|
5757acc67e | |
|
07dc209557 | |
|
caaa34d883 | |
|
26b80bf3c2 | |
|
a78a1291fa | |
|
70e5729e79 | |
|
e4e589a223 | |
|
05daae97ac | |
|
ae5ebe4b54 | |
|
57cd724f71 | |
|
e2ffce08e3 | |
|
27ac9af545 | |
|
0fd0a89fd3 | |
|
38b45cdac2 | |
|
b8ed65ad39 | |
|
7a8b2c345e | |
|
3dc98a86ce | |
|
b44c11e8c7 | |
|
1f50661820 | |
|
5e30adb94e | |
|
7f75d91dbf | |
|
61338366a3 | |
|
2a08b20ba3 | |
|
78b4fadd6c | |
|
43315630b7 | |
|
f9be8c6a70 | |
|
4f8c148e67 | |
|
766376664a | |
|
127c387e99 | |
|
689e5a9501 | |
|
e9f7b48e41 | |
|
49b7eae44f | |
|
14630b1c44 | |
|
5d9e790e17 | |
|
cb5a29f355 | |
|
bb8dc9acba | |
|
3f571ce717 | |
|
c08ae12d85 | |
|
f99ae34685 | |
|
22cf2a2465 | |
|
917c85380c | |
|
858984ae0b | |
|
80d1fa8c2e | |
|
fb84bd8084 | |
|
e02cc853d9 | |
|
4533e07cdc | |
|
3e6886705a | |
|
3efc1217bd | |
|
40cd0eca63 | |
|
8a6db78df2 | |
|
312ef45964 | |
|
9b5f4824d1 | |
|
890eda3bd0 | |
|
de2429ac00 | |
|
36b35dbf4a | |
|
906838f3b6 | |
|
4d00112f5d | |
|
c7180872a3 | |
|
ea59cda07f | |
|
b3da7a14ee | |
|
87a0670225 | |
|
1ce341565f | |
|
5cdc09daa4 | |
|
017c0c6662 | |
|
fee786080f | |
|
e783a1bf72 | |
|
043d08473c | |
|
639226dd50 | |
|
b73265fd09 | |
|
cf50caf4da | |
|
b2a7e1deb0 | |
|
850e7ea019 | |
|
d9e23f194b | |
|
f6dcf0fe78 | |
|
3c031e0c8b | |
|
566711de46 | |
|
7bd8753fa5 | |
|
335f9d0a69 | |
|
5929112c4d | |
|
f029a1a675 | |
|
b919012b1e | |
|
626aee93ec | |
|
243de7399d | |
|
9dee5a8700 | |
|
6e5278ed95 | |
|
bd755610ac | |
|
e975aacb0e | |
|
de0b5de140 | |
|
b83f2b9542 | |
|
e1cac0c48a | |
|
19ba684f2c | |
|
55c51715b5 | |
|
7032c07fb8 | |
|
d117273977 | |
|
9dbac78f29 | |
|
6fbe17da59 | |
|
1d71f6cb31 | |
|
e1037ff046 | |
|
d11304c7d1 | |
|
a651ad7fe7 | |
|
fd2416d9ea | |
|
fb64b2e430 | |
|
17def33bf8 | |
|
ff3c7c2bce | |
|
13b6f0e120 | |
|
31b844c37c | |
|
6a4b1f5f6c | |
|
408a0a744c | |
|
bcd1e282d2 | |
|
9a6aa31d93 | |
|
60db5fe85d | |
|
c25fc6e899 | |
|
8116ff7b90 | |
|
03be5a67c0 | |
|
63922ecb63 | |
|
4b1e4829b8 | |
|
f8930bb489 | |
|
b0fcda8dfd | |
|
97aa6bf1ca | |
|
206ac7e65f | |
|
96f0747e17 | |
|
d5336ffecc | |
|
25f24bd457 | |
|
6d5f557c7d | |
|
1e6b2f8815 | |
|
b2f033f84d | |
|
bc809dae5d | |
|
0248a44a05 | |
|
baad229598 | |
|
5d2a48ce9d | |
|
a67b74aede | |
|
9473b9d4af | |
|
0bfbbd54e2 | |
|
4d148920ae | |
|
5e8ae9bb89 | |
|
3e3bf8a79b | |
|
e87177f97f | |
|
3f41a13087 | |
|
32a55b0939 | |
|
5504c17ab0 | |
|
a83a64fefc | |
|
bbb2bac1ac | |
|
9acf1b6667 | |
|
844afbd2ae | |
|
b398183fb0 | |
|
9321a0d9fc | |
|
553be0f9eb | |
|
cbf4cb52f1 | |
|
47a2c78990 | |
|
5689d59d32 | |
|
9b55332fc2 | |
|
b915222d96 | |
|
154da511c6 | |
|
a7f7befe24 | |
|
e4315ad6a7 | |
|
b16f8c8909 | |
|
7a0e41021d | |
|
98b854de95 | |
|
327746929e | |
|
d229f7b9ce | |
|
c29d801825 | |
|
03dd67c296 | |
|
a194f13466 | |
|
f8b6b259e2 | |
|
e5dd57d588 | |
|
23f3c31086 | |
|
42404ba4c3 | |
|
160feb10b6 | |
|
20fa2c5544 | |
|
233cf43dd8 | |
|
5c7ec37c04 | |
|
565ceecfb4 | |
|
1ee4ba1409 | |
|
f4fe8fea10 | |
|
26d4d827d8 | |
|
0b2941372e | |
|
1f001c06ee | |
|
fe0574906f | |
|
a396f5b973 | |
|
6ea4d05e76 | |
|
b2d405ced0 | |
|
2aabd172bd | |
|
1e21aeb83e | |
|
5dc732e7ef | |
|
47eb8924c9 | |
|
fcf68b6200 | |
|
e3af1254c5 | |
|
33a2d8f35f | |
|
11e51b6349 | |
|
becff6ffdd | |
|
4a8cce90b7 | |
|
30d06746c9 | |
|
2a7d10c053 | |
|
437100c81c | |
|
5723b79f69 | |
|
569aa36450 | |
|
bba80b5b0b | |
|
513e6ef89a | |
|
909b60e942 | |
|
e8e41470f8 | |
|
1c5281f906 | |
|
8574f3df93 | |
|
201609ad7e | |
|
8bfa5e60b4 | |
|
481436cc00 | |
|
3c534067bf | |
|
81fc443ec1 | |
|
e0ec6d5eff | |
|
8f11e9dee1 | |
|
03932d2335 | |
|
a333649a4e | |
|
3ce9bd9823 | |
|
66acf80d18 | |
|
45c2b616e2 | |
|
3e98e63a6c | |
|
a3e4403f50 | |
|
3567634837 | |
|
af41efa40c | |
|
eb222b4fe0 | |
|
8ccd4e656b | |
|
6e781c5905 | |
|
ec5eda1d9c | |
|
43e4e71989 | |
|
4f063850d5 | |
|
1a24d6232c | |
|
1f0052d62e | |
|
be9733228f | |
|
b9f87da380 | |
|
f1a4631b9f | |
|
d0d4abac2e | |
|
673be69531 | |
|
aaf0c04f79 | |
|
c367f32ab8 | |
|
956bf5bcd9 | |
|
5ef8079d32 | |
|
fb8b435b4c | |
|
a93aa6d142 | |
|
cf70811274 | |
|
092e79e017 | |
|
c6a925a30b | |
|
99a55bf3c9 | |
|
0a773f1b50 | |
|
1fafff988a | |
|
e38d52c46f | |
|
3d8b0363c7 | |
|
84f962e857 | |
|
564d7f630e | |
|
b9fb26f5d5 | |
|
e61e2460a0 | |
|
9bac0682c3 | |
|
d53ab5fcbc | |
|
dbe5b9a36e | |
|
b1bd2f49a7 | |
|
dbfdf2ea00 | |
|
da3eb7d5c7 | |
|
479a0f6bdf | |
|
39d236f76c | |
|
65864c0bde | |
|
1be6f06c5e | |
|
4f2d353bae | |
|
cbba3507f9 | |
|
c9fd9f2bd5 | |
|
9f3548602f | |
|
ed85d1ff39 | |
|
0a57e268ca | |
|
330a1d5e3f | |
|
3cfc9660d4 | |
|
21c556e4a2 | |
|
73b3ccb65c | |
|
dfed189b26 | |
|
cd60f6891a | |
|
2465eb6fd8 | |
|
65443520b5 | |
|
fe37d147c3 | |
|
c29c57c8e7 | |
|
38da0790b8 | |
|
e4d9d2cace | |
|
66ba1aad3e | |
|
092e6092ef | |
|
8d19a94716 | |
|
c8e08b0e96 | |
|
3ce628ab73 | |
|
7372acfd64 | |
|
441d66dd3d | |
|
2425a5bf7a | |
|
62a1d5c103 | |
|
66a41077ca | |
|
198241c077 | |
|
456c899627 | |
|
2af6223455 | |
|
dd31106723 | |
|
f856210617 | |
|
92349aa776 | |
|
d8951f74f5 | |
|
a3f0295cb6 | |
|
9c0bf830e5 | |
|
95240be273 | |
|
681fbec905 | |
|
36c4eb4dae | |
|
228108ea6b | |
|
894b839502 | |
|
1b56c887db | |
|
69ef14ce8a | |
|
c79a0cff92 | |
|
882aeb9aa5 | |
|
6c6843154d | |
|
b9968a3bca | |
|
f0ba5495d5 | |
|
ca802490a5 | |
|
df126fb35b | |
|
9f8ddba41e | |
|
3fad940acf | |
|
283480c802 | |
|
604532cca1 | |
|
2c37d28a82 | |
|
ae834f371e | |
|
79b932e841 | |
|
3693c9edd6 | |
|
ec7b435480 | |
|
5182e212d0 | |
|
27accd4cc3 | |
|
d3784f64c4 | |
|
5fa56e83bf | |
|
edc43904c9 | |
|
9ac5984f54 | |
|
9ce78b04f5 | |
|
1ec5ac7281 | |
|
b70ba3406d | |
|
c9ae7af581 | |
|
3cca1cc108 | |
|
1f77e08d4f | |
|
0bd85486fe | |
|
4fd8f06bc1 | |
|
0a26121691 | |
|
624ce6d6b0 | |
|
e73e517fbf | |
|
83abb5f5d3 | |
|
45833a1588 | |
|
0fdd5de149 | |
|
272f085f8c | |
|
6526ebb088 | |
|
811fb7e0ce | |
|
3fc7a9a2b8 | |
|
829060aad6 | |
|
711a88b545 | |
|
bbe73d0893 | |
|
6cce68e02a | |
|
577a5048f0 | |
|
ff9c8cf7cd | |
|
2e896d322c | |
|
9a9b7f1a44 | |
|
981f3b20de | |
|
e0c2123b05 | |
|
7196ab330c | |
|
238d00275e | |
|
fbf0575252 | |
|
a8adb58654 | |
|
7fd9cc9f73 | |
|
4b08221dd2 | |
|
32cb319cc7 | |
|
a593018417 | |
|
161c9d05f8 | |
|
9d7f700c35 | |
|
2fefae9e47 | |
|
32a0709ffc | |
|
0dc531d04c | |
|
731ddfd9f6 | |
|
892bdfde1b | |
|
ef78d9d94c | |
|
69562802cf | |
|
70cc1347f6 | |
|
afae0efdb8 | |
|
37277c3ef7 | |
|
19bfc96a0c | |
|
e87feda358 | |
|
60485864f9 | |
|
5edc36cff1 | |
|
702cfc9d80 | |
|
03dac17d2a | |
|
62e4a4228d | |
|
b2c36ca621 | |
|
9641e2fc0b | |
|
6a03fed583 | |
|
9dfbb58dce | |
|
86dbc09fc3 | |
|
fd151499d5 | |
|
94f8cdcae5 | |
|
1aa17db44e | |
|
3c91090657 | |
|
42cdefaf35 | |
|
9aa520bbb3 | |
|
053e86f87f | |
|
a9ce93846a | |
|
2093c1c2e9 | |
|
c4457ae78f | |
|
ef987f67b2 | |
|
ab4898c500 | |
|
6d471d6cff | |
|
564ef9461a | |
|
b25ab9caa1 | |
|
9b87a3ef00 | |
|
1af5d1a076 | |
|
5e4a71e367 | |
|
7b98f97f5d | |
|
f503789adf | |
|
bf159d1221 | |
|
9eee0edd0c | |
|
1ad94f26c7 | |
|
d5e033bba9 | |
|
069fa9c179 | |
|
5fd74c8a14 | |
|
c8193992d4 | |
|
6d64ce0c87 | |
|
5b411837f4 | |
|
a627029132 | |
|
1ef1388501 | |
|
be5dd9c66e | |
|
a239b8e3c9 | |
|
f04f47f251 | |
|
630a4160f2 | |
|
893d06ab9b | |
|
b5b545f088 | |
|
752f2c2c01 | |
|
7032b92143 | |
|
5aa4db445c | |
|
f569d2863d | |
|
609a15c8e4 | |
|
14709c4fa2 | |
|
0ac23578de | |
|
8f3339dfc8 | |
|
d159df6791 | |
|
626de177c7 | |
|
f5d399ba46 | |
|
cccbcad5d6 | |
|
88e643e805 | |
|
f724bdef18 | |
|
0449b3583e | |
|
5195bd4ab1 | |
|
d44cf352ba | |
|
88f4db3c6a | |
|
09b3f6955c | |
|
2575a8b805 | |
|
29e39136ca | |
|
e9aeb94611 | |
|
cd7558ab84 | |
|
ac05aa3bf6 | |
|
9838693599 | |
|
4aea56d915 | |
|
1a0d105a2c | |
|
c040121fc1 | |
|
4392f80542 | |
|
12b3f0e25f | |
|
de48022622 | |
|
c3dad3f1ed | |
|
a27f08ab90 | |
|
a6567d6377 | |
|
ef117e9874 | |
|
36cf64abc3 | |
|
a0aa25c407 | |
|
9e45264d9d | |
|
51224cbca1 | |
|
dbd3001774 | |
|
573ea33397 | |
|
36efce62ac | |
|
e2de904356 | |
|
5811fadeef | |
|
8cfeb65925 | |
|
f7229384d9 | |
|
d3d52c75fe | |
|
7448bba530 | |
|
4f5f2aa4c3 | |
|
206ff55aff | |
|
2e5aad23a1 | |
|
2e26bb072d | |
|
35d34967ee | |
|
258c3729de | |
|
7af527675b | |
|
849d9435ae | |
|
0d582758dd | |
|
ed6baf0fef | |
|
0a3ef33991 | |
|
62251dc54f | |
|
20d506168b | |
|
8a6dc9c9fe | |
|
3e7d58efe7 | |
|
5651875ca8 | |
|
168b4e49ab | |
|
70596553a2 | |
|
124476baa4 | |
|
d388e80a53 | |
|
4781183ab9 | |
|
84517efcd1 | |
|
84bbeaaed4 | |
|
83e8313045 | |
|
c7d1afe2ab | |
|
5d9b1b747d | |
|
b09b53bea1 | |
|
8e80fff644 | |
|
0823b3f85a | |
|
c0631d6488 | |
|
6d8c63916f | |
|
119b7c8ca1 | |
|
45cf08e21d | |
|
9e203fca7e | |
|
4311620e41 | |
|
9cbd29042a | |
|
e609e7be46 | |
|
60d4e8c8b9 | |
|
37351710da | |
|
36b707451e | |
|
e1fde7fda1 | |
|
6fe1065ffd | |
|
2b62e7574b | |
|
25ada6f826 | |
|
d724d9e6e3 | |
|
c87ac8a92a | |
|
f0a898c6e3 | |
|
3a0c82234f | |
|
b506217b2b | |
|
0c0d2f04e2 | |
|
fb8dafb3d8 | |
|
c29e582944 | |
|
fc0cb8af7c | |
|
2c84f207dc | |
|
72a8e7a802 | |
|
09091814b5 | |
|
25d295ea38 | |
|
694b4948e3 | |
|
feca6f4b26 | |
|
c01c5defb1 | |
|
20ebcf4a27 | |
|
6674a859d1 | |
|
242148b92d | |
|
775d718d87 | |
|
136835232a | |
|
803aea13f3 | |
|
9dc6913989 | |
|
f7806f03c4 | |
|
c3635e6406 | |
|
b9b5ffc646 | |
|
2db3287d57 | |
|
aa6c2df6f5 | |
|
5e44e622a7 | |
|
6a86d4a853 | |
|
befd65d99d | |
|
8ed505a6c9 | |
|
fe161c5537 | |
|
a23752742b | |
|
642f7c6f1a | |
|
e6a5a5380c | |
|
46690175b9 | |
|
08f48b1b9b | |
|
f20542877c | |
|
cfe18281eb | |
|
cafed14a2e | |
|
901c1a7963 | |
|
d81c846af0 | |
|
3aba19102e | |
|
a8d7af462b | |
|
41ec7e7820 | |
|
f1230509d8 | |
|
b2c58d414c | |
|
54624a8a6f | |
|
de0d60efff | |
|
149dfcdb53 | |
|
624aa9eaa1 | |
|
7f55b54b7c | |
|
e4ebd818d6 | |
|
374ef5c5fc | |
|
b739429387 | |
|
5871bc3f4f | |
|
588b7cb392 | |
|
8c327e6a4c | |
|
367862f968 | |
|
3154bd7fdf | |
|
9400bfea47 | |
|
3ce38d841f | |
|
e2dfec033f | |
|
4c3d52b342 | |
|
46a1dbbfd3 | |
|
2b59d069fb | |
|
9b21100974 | |
|
db98f093ea | |
|
5bfd63a7f7 | |
|
d7e673ff87 | |
|
d3f95d6df5 | |
|
2d38080008 | |
|
5db9d91870 | |
|
08e5ee6d5b | |
|
3d60f88bfa | |
|
f7a3f3ea12 | |
|
dad1b516cf | |
|
f1b392c7c9 | |
|
2d16ce3037 | |
|
078bc24c37 | |
|
71b454d1a9 | |
|
aabd16d911 | |
|
04e844ea6d | |
|
bf5cfa4806 | |
|
c458556923 | |
|
46dcc1a626 | |
|
885f99b30a | |
|
c559e51df9 | |
|
39606562f9 | |
|
9ceeeddaea | |
|
82f4327fb3 | |
|
a14b7ecb4a | |
|
666aca0fe5 | |
|
a4f857bd3d | |
|
50ac7ca9f8 | |
|
ee0215cc88 | |
|
9bfc711287 | |
|
f36e0320a2 | |
|
22b350cf20 | |
|
feeb659064 | |
|
f39dfae9ee | |
|
42df5af63e | |
|
698a826c78 | |
|
f97027827d | |
|
5b9a851bec | |
|
02ddf95e05 | |
|
63a9da281f | |
|
9213bb5e17 | |
|
4ce5018fb3 | |
|
6d88eef819 | |
|
f0f22b5005 | |
|
98155b9eb5 | |
|
00ed0aecea | |
|
331098ae10 | |
|
0651307139 | |
|
31b35d5a88 | |
|
ac7594e6ca | |
|
d5a6735bdc | |
|
07102cf762 | |
|
348ae34c78 | |
|
9a0173e086 | |
|
8d536a262f | |
|
549f2300b3 | |
|
bd404bae69 | |
|
500513c9be | |
|
caa95026c3 | |
|
aca7029cfa | |
|
a3516758ef | |
|
990d5db7a9 | |
|
8bbe71f5d7 | |
|
7226b805e2 | |
|
c13faee763 | |
|
707e7509a2 | |
|
80c8bc8913 | |
|
af094bdcb3 | |
|
286679b5ac | |
|
874010a2c3 | |
|
07cd5145b9 | |
|
30f418c4c6 | |
|
ae47544e49 | |
|
b7dc78cf3e | |
|
3d792d49d2 | |
|
41582539ee | |
|
0fc5a6f9b0 | |
|
a43deabd7a | |
|
dc23447dfd | |
|
627487f356 | |
|
3e8e6e9a9e | |
|
8827ef0815 | |
|
98b01feeb0 | |
|
2ea3609133 | |
|
3c63d327a7 | |
|
1db4f4efe1 | |
|
4b20dd87bb | |
|
5bf0ca45c4 | |
|
a213e2863f | |
|
77df9d90c9 | |
|
4d66799a1b | |
|
8deea8dbe8 | |
|
209718e956 | |
|
5fd8a3069b | |
|
cece2e3538 | |
|
62e61fd1ac | |
|
e34b79e6b9 | |
|
25bfae89ba | |
|
725acfafc1 | |
|
841b2920ac | |
|
52e2876add | |
|
49e63fe239 | |
|
3c35f28272 | |
|
66eb89c7f3 | |
|
90ad18ff22 | |
|
821bd9f8f1 | |
|
f78cade025 | |
|
5199cdcc0b | |
|
7b7b8ecb05 | |
|
a3e5153e98 | |
|
2277417172 | |
|
6265c0009a | |
|
da2761d81d | |
|
1c288d7922 | |
|
a43b8a4e7f | |
|
0b32b51ff1 | |
|
ef1b750c95 | |
|
2df1c61e06 | |
|
f7e6215524 | |
|
ba9e5cf21f | |
|
8496471750 | |
|
eef0b96916 | |
|
96d5f3a79d | |
|
4e7886498c | |
|
8e1c43b50a | |
|
89de83447a | |
|
59aabd6fb5 | |
|
a5eef5d9fc | |
|
746bcca4b3 | |
|
a4c521a96c | |
|
4326655e59 | |
|
07417709da | |
|
080cfb00bf | |
|
3b111df058 | |
|
d69d5e1a0c | |
|
8c6eb6c741 | |
|
e0ddb5ed54 | |
|
9dfa6a981b | |
|
81767ac18f | |
|
175986b0a2 | |
|
b5b89264d3 | |
|
0c7fcf636b | |
|
b25a4e6889 | |
|
72ca40e99d | |
|
b215c96a34 | |
|
2815bee6f9 | |
|
9040eed545 | |
|
5a4c216568 | |
|
485942ecdf | |
|
b7e6c187d4 | |
|
bcf8705de1 | |
|
496b291fbb | |
|
e32e960b22 | |
|
a7ea92955a | |
|
0c060a7a4e | |
|
6a92b3459e | |
|
c62ebaa504 | |
|
ae16d11150 | |
|
f21cd8eb1b | |
|
1c7a9abee6 | |
|
1cea0d7786 | |
|
8253c352b2 | |
|
8e21be9a73 | |
|
1147fe4eff | |
|
588bc39a77 | |
|
ccac68b60f | |
|
7ea6510a05 | |
|
fbacfdc358 | |
|
7985249119 | |
|
cad4baf2e1 | |
|
6dc1d7fff0 | |
|
3201fab5ab | |
|
d3e49e42c7 | |
|
c333fe2b0b | |
|
878b38116d | |
|
d23c9b9d97 | |
|
5be384497d | |
|
c61640143c | |
|
60adcd0e5c | |
|
fcdde6f89a | |
|
65af4c7de4 | |
|
ccc989e91c | |
|
d90238c971 | |
|
58c50ad351 | |
|
3669cb1d79 | |
|
4ee74f4322 | |
|
1e0a45b9ba | |
|
4c1939cc39 | |
|
baefc22e49 | |
|
b8e255775c | |
|
a189090b8a | |
|
562c78f29b | |
|
f56419d47c | |
|
c8f535c401 | |
|
012fcc676f | |
|
3ccf1c37d1 | |
|
2825f8767e | |
|
fd499bc3a8 | |
|
dcb22488f7 | |
|
e793368cf5 | |
|
b026aecfc1 | |
|
179c1a9b69 | |
|
d9763c0a1c | |
|
48f5d2636e | |
|
44b7eb851b | |
|
8d9e729a25 | |
|
d1a0afb8a6 | |
|
af6b9096d7 | |
|
6d5a6ccae3 | |
|
a884fad84d | |
|
3329a7caca | |
|
fa484ecbeb | |
|
8d14678190 | |
|
7e8ff18f82 | |
|
70e920e1c8 | |
|
b684ce88e2 | |
|
9ac2beeed8 | |
|
8e52e03761 | |
|
4379eaf89c | |
|
caa5da0cc2 | |
|
d3bebc6c49 | |
|
c15eb07d9e | |
|
960c5b4820 | |
|
8579893230 | |
|
4eed11f925 | |
|
234e0faf0b | |
|
0ab4949653 | |
|
8570f6f5a6 | |
|
7656d39204 | |
|
76bfab70a1 | |
|
fe92918c87 | |
|
77ebb8614a | |
|
6e2b8f0ebf | |
|
a5e5f3e307 | |
|
8adfcb5ce0 | |
|
fca48cf94f | |
|
3e027d2126 | |
|
95f07ed666 | |
|
a9ec23b50d | |
|
f5117e74fd | |
|
fc896078f7 | |
|
784973277a | |
|
1c7fdad7b1 | |
|
7b7eb100b4 | |
|
ecc92df195 | |
|
8fddbe438c | |
|
847a002eff | |
|
f4f4682d57 | |
|
2379ba88d7 | |
|
2766855113 | |
|
6e3ff4364e | |
|
a1cb36a19a | |
|
af95317ce7 | |
|
2cd929c225 | |
|
4f067aeb6c | |
|
591ffa642a | |
|
3031d1bbf9 | |
|
acff8a6825 | |
|
607ccaa732 | |
|
d39ed004f6 | |
|
7152d677c8 | |
|
c699bd4ba1 | |
|
9e2d6352d9 | |
|
c0c5f35af2 | |
|
756c9cdd49 | |
|
98bcfd9ab4 | |
|
426ed5e77d | |
|
8e6881730f | |
|
d530096d09 | |
|
b3f3977906 | |
|
da380e579a | |
|
1798ad5681 | |
|
b510cafc3d | |
|
614fdd6d7e | |
|
e599a1f65c | |
|
8b0d50586e | |
|
a7683fbca6 | |
|
f7eec5124d | |
|
482f4c0468 | |
|
4861f55830 | |
|
d7bed44d73 | |
|
cee6562813 | |
|
5f50fe0fca | |
|
0a202f8c35 | |
|
6c47fbc21a | |
|
bc6ee29250 | |
|
df70f410f3 | |
|
fcb49762f1 | |
|
40e609444d | |
|
6e32abdfaa | |
|
07334dad30 | |
|
1a00b68e7e | |
|
ea346eaca8 | |
|
65d43bfac4 | |
|
1258385ab5 | |
|
feae1e7e12 | |
|
5e5413f536 | |
|
b934946949 | |
|
7e35c0a763 | |
|
18523f8b0c | |
|
35cb6b6d78 | |
|
7f17eaaab1 | |
|
395af7f309 | |
|
18184803f4 | |
|
6d714ee508 | |
|
81b9eaf515 | |
|
4faaf8d305 | |
|
b4e384cb22 | |
|
e47ed372d4 | |
|
3c0fd3f56c | |
|
13b84cdb0f | |
|
03e3e19a4f | |
|
cca702c505 | |
|
79dcd1d36f | |
|
081abeb616 | |
|
07405b4089 | |
|
352f77d1da | |
|
cde0876c79 | |
|
c7c5b894e8 | |
|
50cd043d99 | |
|
4e748c8262 | |
|
4e0d11f3b2 | |
|
192907b9fc | |
|
5986a2e2ad | |
|
1db43e879f | |
|
c7cd1904da | |
|
bb306ec6b3 | |
|
159d1a6976 | |
|
9584e4c879 | |
|
a46ee1f99e | |
|
207fbcec47 | |
|
731cfe6f3e | |
|
845ca0f811 | |
|
8af142b670 | |
|
3158debe54 | |
|
584531e5b8 | |
|
4036974dba | |
|
b720dee526 | |
|
30ecac8148 | |
|
4aefbb8a17 | |
|
f4ffdb3c60 | |
|
f61e720c02 | |
|
d22670e43a | |
|
0105afc51f | |
|
ee74933826 | |
|
7c9bbc7a36 | |
|
331e487a2b | |
|
998047b350 | |
|
04f4c32dda | |
|
14da9191fb | |
|
10b35bdd19 | |
|
e83b59b645 | |
|
d6181913b8 | |
|
9c65d64012 | |
|
d4e37652ad | |
|
de2002a63e | |
|
ce803ea0b4 | |
|
86319cfe89 | |
|
5cf59663d9 | |
|
4284a49a20 | |
|
fa41eae110 | |
|
d6ed011d5e | |
|
2fc1b8cc9c | |
|
0f32bd8494 | |
|
4a9eb35910 | |
|
d7d12b82b5 | |
|
34967ee7c5 | |
|
e01760a60d | |
|
1fa1a91f32 | |
|
5097fc7c4e | |
|
7f435cd37d | |
|
f3c5ed99e2 | |
|
06725e94b9 | |
|
95d95bc4c4 | |
|
8e9171d512 | |
|
c57d51d7a0 | |
|
d84390beb6 | |
|
3ef1646c6e | |
|
0b626b087a | |
|
ba949107ab | |
|
2dc3a10bfe | |
|
64c268fdd7 | |
|
fb9faa3835 | |
|
0988966fdc | |
|
e17905a0a3 | |
|
d4a9158323 | |
|
d18edb4abc | |
|
0d8430799c | |
|
36eeeba15e | |
|
9a7ebd326e | |
|
c7e79e2909 | |
|
95f9ef67af | |
|
3322acf19e | |
|
2f0817d567 | |
|
0e5701144a | |
|
e2b5431316 | |
|
6b02900eb4 | |
|
c4bfbb4f4a | |
|
ee39523b75 | |
|
c5513d6de1 | |
|
36d4481d7e | |
|
cffde64533 | |
|
4b8685cdd9 | |
|
2d62a442f5 | |
|
2c7b2d4dbd | |
|
60bdbd0686 | |
|
0575989ddb | |
|
41e077a354 | |
|
2c4989a120 | |
|
363decd737 | |
|
3ecf6c8134 | |
|
93487a1d9b | |
|
2250e3355e | |
|
4ae1207623 | |
|
812a5ac710 | |
|
be04f70d5b | |
|
f825dfe042 | |
|
b69910c141 | |
|
79e4f07586 | |
|
232234ec86 | |
|
7a66cf8d4e | |
|
5a6d585a9d | |
|
fb1d0e6f41 | |
|
9515d73aac | |
|
680af418cf | |
|
af17ba2485 | |
|
9aba6af281 | |
|
538d1f1eb0 | |
|
79b3d81e42 | |
|
5531006f08 | |
|
7419c0a366 | |
|
39b498fed9 | |
|
0835c3837e | |
|
2f868aca8d | |
|
c7d08a269c | |
|
e4a74b9d0e | |
|
ede1215566 | |
|
35478ad138 | |
|
43e83effb4 | |
|
e24f7cede5 | |
|
066d424d3a | |
|
9ed3c3d455 | |
|
f6f47a0ecd | |
|
34c6a5c0d6 | |
|
c04c0542e8 | |
|
bb52ce246c | |
|
223b8db3a7 | |
|
da7c6fe190 | |
|
25b64382e4 | |
|
2a7002a010 | |
|
bc48ebe898 | |
|
74c39f073d | |
|
691922ebd1 | |
|
dc81e21c2b | |
|
5524822ed5 | |
|
dc41de37f3 | |
|
975a2aaa64 | |
|
cb1e663836 | |
|
888681c0b0 | |
|
606abd14e2 | |
|
44e9c03d45 | |
|
1f7b5120f1 | |
|
a414e4e7d3 | |
|
55e3cd177e | |
|
ace2fbe622 | |
|
88e255b63f | |
|
3ecbe6b903 | |
|
b909f2a482 | |
|
a1f90a56cf | |
|
bfc9ba5b21 | |
|
5fd898adea | |
|
5361fc591e | |
|
2cf4dfacef | |
|
2eec56d936 | |
|
08b8427e91 | |
|
2aee30ca10 | |
|
37da8b64e4 | |
|
b4abd7fb9b | |
|
111d0a5cd7 | |
|
58a12371d1 | |
|
3049a53843 | |
|
4d1cb63baf | |
|
8364aff29c | |
|
ad0479ac77 | |
|
bc6a430edc | |
|
813a8891d1 | |
|
511c2eb1e0 | |
|
eb60b41f20 | |
|
5cdc69196a | |
|
3018efc0f3 | |
|
777d82a26f | |
|
6f966489b8 | |
|
1b04d74cde | |
|
6e9a79604c | |
|
42506f08bd | |
|
ebecd8c1ff | |
|
5881d3c211 | |
|
7002be59fa | |
|
ba56f26b4d | |
|
5788c120e7 | |
|
633436cff6 | |
|
d65629f7a1 | |
|
0034331888 | |
|
918ea38834 | |
|
b9e6ed7e1a | |
|
3e884f9579 | |
|
52eac8c2c1 | |
|
0fc7c704a7 | |
|
6f85acb9b1 | |
|
b3c051eb4f | |
|
8a49de84f6 | |
|
de065cf344 | |
|
ff5affbc77 | |
|
f94b9a4c67 | |
|
1b3ea422fe | |
|
3f2815838e | |
|
da683d31b9 | |
|
9596aedaa0 | |
|
a01dbbbcbc | |
|
f07b6d2613 | |
|
efd68a4474 | |
|
aa36706f38 | |
|
c73733ae13 | |
|
4ed0316834 | |
|
a5309ed60e | |
|
9a87098e0c | |
|
22338aa775 | |
|
868b619a2f | |
|
7e29b5d22f | |
|
6e25e6bb09 | |
|
fdddcfde7b |
|
@ -0,0 +1 @@
|
|||
../../../Dockerfile
|
|
@ -0,0 +1,7 @@
|
|||
name: Render Zcash Protocol Specification
|
||||
description: GitHub Action to compile Zcash Protocol Specification LaTeX documents
|
||||
author: Deirdre Connolly
|
||||
runs:
|
||||
using: docker
|
||||
# Runs `make all` or something like it
|
||||
image: Dockerfile
|
|
@ -0,0 +1,10 @@
|
|||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: github-actions
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: daily
|
||||
timezone: America/New_York
|
||||
open-pull-requests-limit: 10
|
||||
labels:
|
||||
- "A-CI"
|
|
@ -0,0 +1,19 @@
|
|||
name: Render pdfs
|
||||
|
||||
on: workflow_dispatch
|
||||
|
||||
jobs:
|
||||
|
||||
render:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Set up Git repository
|
||||
uses: actions/checkout@v3.0.2
|
||||
|
||||
- name: Compile Zcash Protocol Specification
|
||||
uses: ./.github/actions/render-protocol-pdf
|
||||
|
||||
- uses: EndBug/add-and-commit@v9.0.0
|
||||
with:
|
||||
add: '**/*.pdf'
|
||||
default_author: github_actions
|
|
@ -3,6 +3,7 @@
|
|||
*.log
|
||||
*.bbl
|
||||
*.blg
|
||||
*.brf
|
||||
*.out
|
||||
*.toc
|
||||
*.synctex.gz
|
||||
|
@ -10,11 +11,22 @@
|
|||
*.fls
|
||||
*.bcf
|
||||
*.run.xml
|
||||
*.dvi
|
||||
|
||||
# Temporary files
|
||||
.emacs.desktop
|
||||
.~lock.*
|
||||
*.swp
|
||||
*.save
|
||||
*.save.*
|
||||
|
||||
.Makefile.uptodate
|
||||
.zipfilelist.*
|
||||
|
||||
protocol/aux/
|
||||
protocol/html/
|
||||
protocol/saplinghtml/
|
||||
|
||||
protocol/heartwood.pdf
|
||||
protocol/protocol.ver
|
||||
*~
|
||||
|
|
|
@ -0,0 +1,15 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>COPYING</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<p>Copyright (c) 2016-2020 The Zcash Core developers</p>
|
||||
<p>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:</p>
|
||||
<p>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.</p>
|
||||
<p>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</p>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -1,4 +1,4 @@
|
|||
Copyright (c) 2016 The Zcash Core developers
|
||||
Copyright (c) 2016-2020 The Zcash Core developers
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
|
@ -0,0 +1,23 @@
|
|||
FROM debian:latest
|
||||
|
||||
RUN apt-get update \
|
||||
&& apt-get install -y \
|
||||
gawk \
|
||||
perl \
|
||||
sed \
|
||||
git \
|
||||
python3 \
|
||||
python3-pip \
|
||||
pandoc \
|
||||
biber \
|
||||
latexmk \
|
||||
texlive \
|
||||
texlive-science \
|
||||
texlive-fonts-extra \
|
||||
texlive-plain-generic \
|
||||
texlive-bibtex-extra
|
||||
|
||||
RUN pip3 install rst2html5
|
||||
|
||||
WORKDIR "/zips"
|
||||
ENTRYPOINT ["make", "all"]
|
|
@ -0,0 +1,59 @@
|
|||
# Dependencies:
|
||||
# sudo apt-get install python3-pip pandoc perl sed
|
||||
# sudo pip3 install rst2html5
|
||||
|
||||
.PHONY: all all-zips release protocol discard
|
||||
all-zips: .Makefile.uptodate
|
||||
find . -name 'zip-*.rst' -o -name 'zip-*.md' |sort >.zipfilelist.new
|
||||
diff .zipfilelist.current .zipfilelist.new || cp -f .zipfilelist.new .zipfilelist.current
|
||||
rm -f .zipfilelist.new
|
||||
$(MAKE) README.rst
|
||||
$(MAKE) index.html $(addsuffix .html,$(filter-out README,$(basename $(sort $(wildcard *.rst) $(wildcard *.md)))))
|
||||
|
||||
all: all-zips protocol
|
||||
|
||||
release:
|
||||
$(MAKE) -C protocol release
|
||||
|
||||
protocol:
|
||||
$(MAKE) -C protocol
|
||||
|
||||
discard:
|
||||
git checkout -- '*.html' 'protocol/*.pdf'
|
||||
|
||||
.Makefile.uptodate: Makefile
|
||||
$(MAKE) clean
|
||||
touch .Makefile.uptodate
|
||||
|
||||
define PROCESSRST
|
||||
$(eval TITLE := $(shell echo '$(basename $<)' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||'))
|
||||
rst2html5 -v --title="$(TITLE)" $< >$@
|
||||
./edithtml.sh --rst $@
|
||||
endef
|
||||
|
||||
define PROCESSMD
|
||||
$(eval TITLE := $(shell echo '$(basename $<)' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||'))
|
||||
pandoc --from=markdown --to=html $< --output=$@
|
||||
./edithtml.sh --md $@ "${TITLE}"
|
||||
endef
|
||||
|
||||
index.html: README.rst edithtml.sh
|
||||
$(PROCESSRST)
|
||||
|
||||
%.html: %.rst edithtml.sh
|
||||
$(PROCESSRST)
|
||||
|
||||
%.html: %.md edithtml.sh
|
||||
$(PROCESSMD)
|
||||
|
||||
README.rst: .zipfilelist.current makeindex.sh README.template $(sort $(wildcard zip-*.rst) $(wildcard zip-*.md))
|
||||
./makeindex.sh | cat README.template - >README.rst
|
||||
|
||||
.PHONY: linkcheck
|
||||
linkcheck: all-zips
|
||||
$(MAKE) -C protocol all-specs
|
||||
./links_and_dests.py --check $(filter-out $(wildcard draft-*.html),$(wildcard *.html)) protocol/protocol.pdf protocol/canopy.pdf protocol/heartwood.pdf protocol/blossom.pdf protocol/sapling.pdf
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f .zipfilelist.* README.rst index.html $(addsuffix .html,$(basename $(sort $(wildcard *.rst) $(wildcard *.md))))
|
14
README.md
|
@ -1,14 +0,0 @@
|
|||
zips
|
||||
====
|
||||
|
||||
Specifications and Zcash Improvement Proposals for the
|
||||
[Zcash cryptocurrency](https://z.cash/).
|
||||
|
||||
Participation in the Zcash project is subject to a
|
||||
[Code of Conduct](https://github.com/zcash/zcash/blob/master/code_of_conduct.md).
|
||||
|
||||
License
|
||||
-------
|
||||
|
||||
The contents of this repository are released under the terms of the MIT license.
|
||||
See [COPYING](COPYING) for more information or see http://opensource.org/licenses/MIT.
|
|
@ -0,0 +1,160 @@
|
|||
.. Title: Specifications and Zcash Improvement Proposals
|
||||
|
||||
|
||||
What are ZIPs?
|
||||
--------------
|
||||
|
||||
Zcash Improvement Proposals (ZIPs) are the way to:
|
||||
|
||||
* propose new features for the `Zcash cryptocurrency <https://z.cash/>`__ and their rationale,
|
||||
* specify the implementation details of the feature,
|
||||
* collect community input on the proposal, and
|
||||
* document design decisions.
|
||||
|
||||
|
||||
Contributing
|
||||
------------
|
||||
|
||||
The authors of a ZIP are responsible for building consensus within the community
|
||||
and documenting / addressing dissenting opinions.
|
||||
|
||||
Anyone can write a ZIP! We encourage community contributions and decentralization
|
||||
of work on the Zcash protocol. If you’d like to bounce ideas off people before formally
|
||||
writing a ZIP, we encourage it! Visit the `ZcashCommunity Discord chat <https://discord.gg/kdjfvps>`__
|
||||
to talk about your idea.
|
||||
|
||||
Participation in the Zcash project is subject to a `Code of
|
||||
Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__.
|
||||
|
||||
The Zcash protocol is documented in its `Protocol Specification <protocol/protocol.pdf>`__.
|
||||
|
||||
To start contributing, first read `ZIP 0 <zip-0000.rst>`__ which documents the ZIP process.
|
||||
Then clone `this repo <https://github.com/zcash/zips>`__ from GitHub, and start adding
|
||||
your draft ZIP, formatted either as reStructuredText or as Markdown.
|
||||
|
||||
For example, if using reStructuredText, use a filename matching ``draft-*.rst``.
|
||||
Use ``make`` to check that you are using correct
|
||||
`reStructuredText <https://docutils.sourceforge.io/rst.html>`__ or
|
||||
`Markdown <https://pandoc.org/MANUAL.html#pandocs-markdown>`__ syntax,
|
||||
and double-check the generated ``draft-*.html`` file before filing a Pull Request.
|
||||
|
||||
|
||||
NU5 ZIPs
|
||||
--------
|
||||
|
||||
This is the list of ZIPs relevant to the NU5 Upgrade, which `activated on 31st May 2022 <https://z.cash/upgrade/nu5/>`__:
|
||||
|
||||
- `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`__ (updated)
|
||||
- `ZIP 203: Transaction Expiry <zip-0203.rst>`__ (updated)
|
||||
- `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <zip-0209.rst>`__ (updated)
|
||||
- `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <zip-0212.rst>`__ (updated)
|
||||
- `ZIP 213: Shielded Coinbase <zip-0213.rst>`__ (updated)
|
||||
- `ZIP 216: Require Canonical Jubjub Point Encodings <zip-0216.rst>`__
|
||||
- `ZIP 221: FlyClient - Consensus-Layer Changes <zip-0221.rst>`__ (updated)
|
||||
- `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`__
|
||||
- `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`__
|
||||
- `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`__
|
||||
- `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`__
|
||||
- `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`__
|
||||
- `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.rst>`__
|
||||
- `ZIP 401: Addressing Mempool Denial-of-Service <zip-0401.rst>`__ (clarified)
|
||||
|
||||
|
||||
License
|
||||
-------
|
||||
|
||||
Unless otherwise stated in this repository’s individual files, the
|
||||
contents of this repository are released under the terms of the MIT
|
||||
license. See `COPYING <COPYING.rst>`__ for more information or see
|
||||
https://opensource.org/licenses/MIT .
|
||||
|
||||
Index of ZIPs
|
||||
-------------
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<embed><table>
|
||||
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
|
||||
<tr> <td>0</td> <td class="left"><a href="zip-0000.rst">ZIP Process</a></td> <td>Active</td>
|
||||
<tr> <td><span class="reserved">1</span></td> <td class="left"><a class="reserved" href="zip-0001.rst">Network Upgrade Policy and Scheduling</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">2</span></td> <td class="left"><a class="reserved" href="zip-0002.rst">Design Considerations for Network Upgrades</a></td> <td>Reserved</td>
|
||||
<tr> <td>32</td> <td class="left"><a href="zip-0032.rst">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">76</span></td> <td class="left"><a class="reserved" href="zip-0076.rst">Transaction Signature Validation before Overwinter</a></td> <td>Reserved</td>
|
||||
<tr> <td>143</td> <td class="left"><a href="zip-0143.rst">Transaction Signature Validation for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>155</td> <td class="left"><a href="zip-0155.rst">addrv2 message</a></td> <td>Proposed</td>
|
||||
<tr> <td>173</td> <td class="left"><a href="zip-0173.rst">Bech32 Format</a></td> <td>Final</td>
|
||||
<tr> <td>200</td> <td class="left"><a href="zip-0200.rst">Network Upgrade Mechanism</a></td> <td>Final</td>
|
||||
<tr> <td>201</td> <td class="left"><a href="zip-0201.rst">Network Peer Management for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>202</td> <td class="left"><a href="zip-0202.rst">Version 3 Transaction Format for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>203</td> <td class="left"><a href="zip-0203.rst">Transaction Expiry</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">204</span></td> <td class="left"><a class="reserved" href="zip-0204.rst">Zcash P2P Network Protocol</a></td> <td>Reserved</td>
|
||||
<tr> <td>205</td> <td class="left"><a href="zip-0205.rst">Deployment of the Sapling Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>206</td> <td class="left"><a href="zip-0206.rst">Deployment of the Blossom Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>207</td> <td class="left"><a href="zip-0207.rst">Funding Streams</a></td> <td>Final</td>
|
||||
<tr> <td>208</td> <td class="left"><a href="zip-0208.rst">Shorter Block Target Spacing</a></td> <td>Final</td>
|
||||
<tr> <td>209</td> <td class="left"><a href="zip-0209.rst">Prohibit Negative Shielded Chain Value Pool Balances</a></td> <td>Final</td>
|
||||
<tr> <td><strike>210</strike></td> <td class="left"><strike><a href="zip-0210.rst">Sapling Anchor Deduplication within Transactions</a></strike></td> <td>Withdrawn</td>
|
||||
<tr> <td>211</td> <td class="left"><a href="zip-0211.rst">Disabling Addition of New Value to the Sprout Chain Value Pool</a></td> <td>Final</td>
|
||||
<tr> <td>212</td> <td class="left"><a href="zip-0212.rst">Allow Recipient to Derive Ephemeral Secret from Note Plaintext</a></td> <td>Final</td>
|
||||
<tr> <td>213</td> <td class="left"><a href="zip-0213.rst">Shielded Coinbase</a></td> <td>Final</td>
|
||||
<tr> <td>214</td> <td class="left"><a href="zip-0214.rst">Consensus rules for a Zcash Development Fund</a></td> <td>Final</td>
|
||||
<tr> <td>215</td> <td class="left"><a href="zip-0215.rst">Explicitly Defining and Modifying Ed25519 Validation Rules</a></td> <td>Final</td>
|
||||
<tr> <td>216</td> <td class="left"><a href="zip-0216.rst">Require Canonical Jubjub Point Encodings</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">217</span></td> <td class="left"><a class="reserved" href="zip-0217.rst">Aggregate Signatures</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">219</span></td> <td class="left"><a class="reserved" href="zip-0219.rst">Disabling Addition of New Value to the Sapling Chain Value Pool</a></td> <td>Reserved</td>
|
||||
<tr> <td><strike>220</strike></td> <td class="left"><strike><a href="zip-0220.rst">Zcash Shielded Assets</a></strike></td> <td>Withdrawn</td>
|
||||
<tr> <td>221</td> <td class="left"><a href="zip-0221.rst">FlyClient - Consensus-Layer Changes</a></td> <td>Final</td>
|
||||
<tr> <td>222</td> <td class="left"><a href="zip-0222.rst">Transparent Zcash Extensions</a></td> <td>Draft</td>
|
||||
<tr> <td>224</td> <td class="left"><a href="zip-0224.rst">Orchard Shielded Protocol</a></td> <td>Final</td>
|
||||
<tr> <td>225</td> <td class="left"><a href="zip-0225.rst">Version 5 Transaction Format</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226.rst">Zcash Shielded Assets - Transfers and Burns</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227.rst">Zcash Shielded Assets - Issuance</a></td> <td>Reserved</td>
|
||||
<tr> <td>239</td> <td class="left"><a href="zip-0239.rst">Relay of Version 5 Transactions</a></td> <td>Final</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>244</td> <td class="left"><a href="zip-0244.rst">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
|
||||
<tr> <td>245</td> <td class="left"><a href="zip-0245.rst">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
|
||||
<tr> <td>250</td> <td class="left"><a href="zip-0250.rst">Deployment of the Heartwood Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>251</td> <td class="left"><a href="zip-0251.rst">Deployment of the Canopy Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>252</td> <td class="left"><a href="zip-0252.rst">Deployment of the NU5 Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>300</td> <td class="left"><a href="zip-0300.rst">Cross-chain Atomic Transactions</a></td> <td>Proposed</td>
|
||||
<tr> <td>301</td> <td class="left"><a href="zip-0301.rst">Zcash Stratum Protocol</a></td> <td>Final</td>
|
||||
<tr> <td>302</td> <td class="left"><a href="zip-0302.rst">Standardized Memo Field Format</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">303</span></td> <td class="left"><a class="reserved" href="zip-0303.rst">Sprout Payment Disclosure</a></td> <td>Reserved</td>
|
||||
<tr> <td>304</td> <td class="left"><a href="zip-0304.rst">Sapling Address Signatures</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">305</span></td> <td class="left"><a class="reserved" href="zip-0305.rst">Best Practices for Hardware Wallets supporting Sapling</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">306</span></td> <td class="left"><a class="reserved" href="zip-0306.rst">Security Considerations for Anchor Selection</a></td> <td>Reserved</td>
|
||||
<tr> <td>307</td> <td class="left"><a href="zip-0307.rst">Light Client Protocol for Payment Detection</a></td> <td>Draft</td>
|
||||
<tr> <td>308</td> <td class="left"><a href="zip-0308.rst">Sprout to Sapling Migration</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">309</span></td> <td class="left"><a class="reserved" href="zip-0309.rst">Blind Off-chain Lightweight Transactions (BOLT)</a></td> <td>Reserved</td>
|
||||
<tr> <td>310</td> <td class="left"><a href="zip-0310.rst">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">311</span></td> <td class="left"><a class="reserved" href="zip-0311.rst">Sapling Payment Disclosure</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">312</span></td> <td class="left"><a class="reserved" href="zip-0312.rst">Shielded Multisignatures using FROST</a></td> <td>Reserved</td>
|
||||
<tr> <td>313</td> <td class="left"><a href="zip-0313.rst">Reduce Conventional Transaction Fee to 1000 zatoshis</a></td> <td>Active</td>
|
||||
<tr> <td><span class="reserved">314</span></td> <td class="left"><a class="reserved" href="zip-0314.rst">Privacy upgrades to the Zcash light client protocol</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">315</span></td> <td class="left"><a class="reserved" href="zip-0315.rst">Best Practices for Wallet Handling of Multiple Pools</a></td> <td>Reserved</td>
|
||||
<tr> <td>316</td> <td class="left"><a href="zip-0316.rst">Unified Addresses and Unified Viewing Keys</a></td> <td>Final</td>
|
||||
<tr> <td>321</td> <td class="left"><a href="zip-0321.rst">Payment Request URIs</a></td> <td>Proposed</td>
|
||||
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322.rst">Generic Signed Message Format</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323.rst">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339.rst">Wallet Recovery Words</a></td> <td>Reserved</td>
|
||||
<tr> <td>400</td> <td class="left"><a href="zip-0400.rst">Wallet.dat format</a></td> <td>Draft</td>
|
||||
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402.rst">New Wallet Database Format</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403.rst">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416.rst">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
|
||||
<tr> <td><strike>1001</strike></td> <td class="left"><strike><a href="zip-1001.rst">Keep the Block Distribution as Initially Defined — 90% to Miners</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1002</strike></td> <td class="left"><strike><a href="zip-1002.rst">Opt-in Donation Feature</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1003</strike></td> <td class="left"><strike><a href="zip-1003.rst">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1004</strike></td> <td class="left"><strike><a href="zip-1004.rst">Miner-Directed Dev Fund</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1005</strike></td> <td class="left"><strike><a href="zip-1005.rst">Zcash Community Funding System</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1006</strike></td> <td class="left"><strike><a href="zip-1006.rst">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1007</strike></td> <td class="left"><strike><a href="zip-1007.rst">Enforce Development Fund Commitments with a Legal Charter</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1008</strike></td> <td class="left"><strike><a href="zip-1008.rst">Fund ECC for Two More Years</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1009</strike></td> <td class="left"><strike><a href="zip-1009.rst">Five-Entity Strategic Council</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1010</strike></td> <td class="left"><strike><a href="zip-1010.rst">Compromise Dev Fund Proposal With Diverse Funding Streams</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1011</strike></td> <td class="left"><strike><a href="zip-1011.rst">Decentralize the Dev Fee</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1012</strike></td> <td class="left"><strike><a href="zip-1012.rst">Dev Fund to ECC + ZF + Major Grants</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1013</strike></td> <td class="left"><strike><a href="zip-1013.rst">Keep It Simple, Zcashers: 10% to ECC, 10% to ZF</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td>1014</td> <td class="left"><a href="zip-1014.rst">Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td> <td>Active</td>
|
||||
<tr> <td>guide</td> <td class="left"><a href="zip-guide.rst">{Something Short and To the Point}</a></td> <td>Draft</td>
|
||||
</table></embed>
|
|
@ -0,0 +1,69 @@
|
|||
.. Title: Specifications and Zcash Improvement Proposals
|
||||
|
||||
|
||||
What are ZIPs?
|
||||
--------------
|
||||
|
||||
Zcash Improvement Proposals (ZIPs) are the way to:
|
||||
|
||||
* propose new features for the `Zcash cryptocurrency <https://z.cash/>`__ and their rationale,
|
||||
* specify the implementation details of the feature,
|
||||
* collect community input on the proposal, and
|
||||
* document design decisions.
|
||||
|
||||
|
||||
Contributing
|
||||
------------
|
||||
|
||||
The authors of a ZIP are responsible for building consensus within the community
|
||||
and documenting / addressing dissenting opinions.
|
||||
|
||||
Anyone can write a ZIP! We encourage community contributions and decentralization
|
||||
of work on the Zcash protocol. If you’d like to bounce ideas off people before formally
|
||||
writing a ZIP, we encourage it! Visit the `ZcashCommunity Discord chat <https://discord.gg/kdjfvps>`__
|
||||
to talk about your idea.
|
||||
|
||||
Participation in the Zcash project is subject to a `Code of
|
||||
Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__.
|
||||
|
||||
The Zcash protocol is documented in its `Protocol Specification <protocol/protocol.pdf>`__.
|
||||
|
||||
To start contributing, first read `ZIP 0 <zip-0000.rst>`__ which documents the ZIP process.
|
||||
Then clone `this repo <https://github.com/zcash/zips>`__ from GitHub, and start adding
|
||||
your draft ZIP, formatted either as reStructuredText or as Markdown.
|
||||
|
||||
For example, if using reStructuredText, use a filename matching ``draft-*.rst``.
|
||||
Use ``make`` to check that you are using correct
|
||||
`reStructuredText <https://docutils.sourceforge.io/rst.html>`__ or
|
||||
`Markdown <https://pandoc.org/MANUAL.html#pandocs-markdown>`__ syntax,
|
||||
and double-check the generated ``draft-*.html`` file before filing a Pull Request.
|
||||
|
||||
|
||||
NU5 ZIPs
|
||||
--------
|
||||
|
||||
This is the list of ZIPs relevant to the NU5 Upgrade, which `activated on 31st May 2022 <https://z.cash/upgrade/nu5/>`__:
|
||||
|
||||
- `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`__ (updated)
|
||||
- `ZIP 203: Transaction Expiry <zip-0203.rst>`__ (updated)
|
||||
- `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <zip-0209.rst>`__ (updated)
|
||||
- `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <zip-0212.rst>`__ (updated)
|
||||
- `ZIP 213: Shielded Coinbase <zip-0213.rst>`__ (updated)
|
||||
- `ZIP 216: Require Canonical Jubjub Point Encodings <zip-0216.rst>`__
|
||||
- `ZIP 221: FlyClient - Consensus-Layer Changes <zip-0221.rst>`__ (updated)
|
||||
- `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`__
|
||||
- `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`__
|
||||
- `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`__
|
||||
- `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`__
|
||||
- `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`__
|
||||
- `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.rst>`__
|
||||
- `ZIP 401: Addressing Mempool Denial-of-Service <zip-0401.rst>`__ (clarified)
|
||||
|
||||
|
||||
License
|
||||
-------
|
||||
|
||||
Unless otherwise stated in this repository’s individual files, the
|
||||
contents of this repository are released under the terms of the MIT
|
||||
license. See `COPYING <COPYING.rst>`__ for more information or see
|
||||
https://opensource.org/licenses/MIT .
|
|
@ -0,0 +1,3 @@
|
|||
theme: jekyll-theme-tactile
|
||||
url: "https://zips.z.cash"
|
||||
markdown: GFM
|
|
@ -0,0 +1,6 @@
|
|||
<https://commons.wikimedia.org/wiki/File:Chain_link_icon.svg>
|
||||
|
||||
(c) Mun May Tee-Galloway <https://commons.wikimedia.org/wiki/User:MGalloway_(WMF)>
|
||||
This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.
|
||||
|
||||
The image was rotated, changed from black to blue, and converted to PNG.
|
After Width: | Height: | Size: 3.0 KiB |
|
@ -0,0 +1,59 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="24"
|
||||
height="24"
|
||||
version="1.1"
|
||||
viewBox="0 0 24 24"
|
||||
id="svg867"
|
||||
sodipodi:docname="Chain_link_icon.svg"
|
||||
inkscape:version="0.92.4 (5da689c313, 2019-01-14)">
|
||||
<defs
|
||||
id="defs871" />
|
||||
<sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="2055"
|
||||
inkscape:window-height="1409"
|
||||
id="namedview869"
|
||||
showgrid="false"
|
||||
inkscape:zoom="67.875"
|
||||
inkscape:cx="12.618785"
|
||||
inkscape:cy="12"
|
||||
inkscape:window-x="1611"
|
||||
inkscape:window-y="94"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="svg867" />
|
||||
<metadata
|
||||
id="metadata863">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<path
|
||||
d="m 19.69017,15.294217 c -0.03449,-2.099683 -1.958927,-3.568298 -3.383399,-5.045063 0.0033,0.199971 0.108205,0.498283 0.113147,0.798247 0.0082,0.499927 -0.08355,1.001514 -0.275302,1.504736 0.813065,0.78676 1.72611,1.571867 1.745817,2.771687 0.0099,0.599914 -0.278604,1.30478 -0.670333,1.811291 -0.983415,1.016296 -2.583239,1.042603 -3.599535,0.0592 l -2.642427,-2.556933 c -0.406518,-0.393366 -0.719635,-1.188325 -0.729521,-1.788274 -0.02302,-1.399811 0.865337,-2.114499 1.956992,-2.632533 L 10.884393,8.9380967 C 9.3977837,9.7626206 8.3176231,10.980582 8.3472099,12.780342 c 0.019729,1.199842 0.5377421,2.291476 1.3491637,2.978263 l 2.6424274,2.556934 c 0.914681,0.885087 2.024408,1.466936 3.324212,1.445528 2.196435,-0.236184 4.063292,-2.267133 4.027101,-4.466807 z M 7.5208098,11.193398 6.606129,10.308312 C 6.1996034,9.9149385 5.8864942,9.1199867 5.8766079,8.5200385 5.8667434,7.9201253 6.155212,7.2152587 6.5469407,6.7087476 7.5303551,5.6924515 9.2301515,5.6645014 10.146476,6.6495597 l 2.642427,2.556933 c 0.406519,0.3933659 0.719635,1.1883253 0.729522,1.7882733 0.02302,1.399812 -0.965316,2.116137 -1.956992,2.632534 l 1.321212,1.278467 C 14.369262,14.081249 15.449416,12.863281 15.419829,11.06352 15.4001,9.8636796 14.882088,8.7720451 14.070665,8.0852572 L 11.428238,5.528324 C 9.7004916,3.8564778 7.00084,3.9008687 5.4291065,5.6269689 3.8556574,7.2530283 3.8016512,10.054367 5.5261077,11.526129 L 7.4570845,13.39463 C 7.3521665,13.096317 7.347234,12.796362 7.3422954,12.496397 7.3340785,11.99647 7.3274984,11.596514 7.520921,11.193256 Z"
|
||||
id="path865"
|
||||
inkscape:connector-curvature="0"
|
||||
inkscape:export-filename="/home/daira/zips/assets/images/section-anchor.png"
|
||||
inkscape:export-xdpi="450"
|
||||
inkscape:export-ydpi="450"
|
||||
style="fill:#0097c1;fill-opacity:1" />
|
||||
</svg>
|
After Width: | Height: | Size: 3.2 KiB |
|
@ -0,0 +1,370 @@
|
|||
@media (prefers-color-scheme: light) {
|
||||
body {
|
||||
background: #ffffff;
|
||||
color: #212529;
|
||||
}
|
||||
span.reserved {
|
||||
color: #606060;
|
||||
}
|
||||
a, a:visited {
|
||||
color: #0097c1;
|
||||
}
|
||||
a:hover, a.reserved:hover {
|
||||
color: #00556c;
|
||||
}
|
||||
a.reserved, a.reserved:visited {
|
||||
color: #606060;
|
||||
}
|
||||
#index-of-zips table tr:hover {
|
||||
background-color: #eff1f2;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
body {
|
||||
background: #111111;
|
||||
color: #eeeeee;
|
||||
}
|
||||
img {
|
||||
background: #bbbbbb;
|
||||
}
|
||||
img.section-anchor {
|
||||
background: #111111;
|
||||
}
|
||||
span.reserved {
|
||||
color: #a0a0a0;
|
||||
}
|
||||
a, a:visited {
|
||||
color: #00b7e1;
|
||||
}
|
||||
a:hover, a.reserved:hover {
|
||||
color: #00e2f5;
|
||||
}
|
||||
a.reserved, a.reserved:visited {
|
||||
color: #a0a0a0;
|
||||
}
|
||||
#index-of-zips table tr:hover {
|
||||
background-color: #303030;
|
||||
}
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: robotolight;
|
||||
src: url('../assets/fonts/Roboto-Light-webfont.woff') format('woff');
|
||||
font-weight: 100;
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: robotoregular;
|
||||
src: url('../assets/fonts/Roboto-Regular-webfont.woff') format('woff');
|
||||
font-weight: normal;
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: robotomedium;
|
||||
src: url('../assets/fonts/Roboto-Medium-webfont.woff') format('woff');
|
||||
font-weight: normal;
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
body, body > section {
|
||||
margin: 0 auto;
|
||||
padding: 1.5rem 0 3rem;
|
||||
}
|
||||
|
||||
body {
|
||||
font-family: 'robotoregular',Arial,Helvetica Neue,Helvetica,sans-serif;
|
||||
line-height: 1.5;
|
||||
max-width: 1140px;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
body > section {
|
||||
max-width: 83.33333%;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, h6, h7, h8 {
|
||||
margin: 1.875rem 0 1rem;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4 {
|
||||
font-family: 'robotolight',Arial,Helvetica Neue,Helvetica,sans-serif;
|
||||
line-height: 1.3;
|
||||
font-weight: 100;
|
||||
}
|
||||
|
||||
h5, h6, h7, h8 {
|
||||
font-family: 'robotomedium',Arial,Helvetica Neue,Helvetica,sans-serif;
|
||||
line-height: 1.3;
|
||||
font-weight: 125;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 2.5rem;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 2.125rem;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 1.85rem;
|
||||
}
|
||||
|
||||
h3 code {
|
||||
font-size: 1.5rem;
|
||||
}
|
||||
|
||||
h4 {
|
||||
font-size: 1.5rem;
|
||||
}
|
||||
|
||||
h4 code {
|
||||
font-size: 1.35rem;
|
||||
}
|
||||
|
||||
h5 {
|
||||
font-size: 1.3rem;
|
||||
}
|
||||
|
||||
h6 {
|
||||
font-size: 1.3rem;
|
||||
bottom-padding: 2rem;
|
||||
}
|
||||
|
||||
h7 {
|
||||
font-size: 1.25rem;
|
||||
bottom-padding: 2rem;
|
||||
}
|
||||
|
||||
h8 {
|
||||
font-size: 1.2rem;
|
||||
bottom-padding: 2rem;
|
||||
}
|
||||
|
||||
blockquote {
|
||||
margin: 0 1rem 1rem 1rem;
|
||||
padding: 0;
|
||||
overflow-x: auto;
|
||||
}
|
||||
|
||||
p, ul, ol, li, table {
|
||||
margin-top: 0;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
li {
|
||||
margin-bottom: 0.2rem;
|
||||
}
|
||||
|
||||
li ul {
|
||||
margin-top: 0.625rem;
|
||||
}
|
||||
|
||||
ul, ol, table {
|
||||
margin-bottom: calc( 0.5rem + 0.5ex );
|
||||
}
|
||||
|
||||
p, ul, ol, dl, table {
|
||||
font-size: 1.125rem;
|
||||
line-height: 1.625;
|
||||
}
|
||||
|
||||
pre {
|
||||
display: block;
|
||||
overflow-x: auto;
|
||||
overflow-y: hidden;
|
||||
border: 1px solid #e6e7e8;
|
||||
padding: 0.625rem;
|
||||
font-size: 0.9375rem;
|
||||
}
|
||||
|
||||
span.math {
|
||||
transform: scale(1, 1.03);
|
||||
-moz-transform: scale(1, 1.03);
|
||||
-ms-transform: scale(1, 1.03);
|
||||
-webkit-transform: scale(1, 1.03);
|
||||
-o-transform: scale(1, 1.03);
|
||||
font-size: 0.97rem;
|
||||
}
|
||||
|
||||
div.math {
|
||||
display: block;
|
||||
overflow-x: auto;
|
||||
overflow-y: hidden;
|
||||
margin: 0 1rem 1rem 1rem;
|
||||
text-align: center;
|
||||
padding: 0;
|
||||
font-size: 0.75rem;
|
||||
}
|
||||
|
||||
a, a:visited {
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
a:hover, a.reserved:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
a.reserved, a.reserved:visited {
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
span.section-anchor {
|
||||
opacity: 0;
|
||||
}
|
||||
|
||||
span.section-anchor:hover {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
span.section-heading:hover + span {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
a.footnote_reference::before {
|
||||
content: "[";
|
||||
}
|
||||
a.footnote_reference::after {
|
||||
content: "]";
|
||||
}
|
||||
|
||||
strong, b {
|
||||
font-family: 'robotomedium',Arial,Helvetica Neue,Helvetica,sans-serif;
|
||||
font-weight: normal;
|
||||
}
|
||||
|
||||
hr {
|
||||
border-top: 1px solid #e6e7e8;
|
||||
margin: 1.875rem 0;
|
||||
}
|
||||
|
||||
|
||||
table {
|
||||
border-collapse: collapse;
|
||||
border: 0 none transparent;
|
||||
}
|
||||
|
||||
th, td {
|
||||
border: 1px solid #212529;
|
||||
}
|
||||
|
||||
th, td {
|
||||
padding-left: 0.7rem;
|
||||
padding-right: 0.75rem;
|
||||
padding-top: 0.4rem;
|
||||
padding-bottom: 0.4rem;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
td:first-child {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
#index-of-zips table td:first-child + td {
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
#index-of-zips table a {
|
||||
display: block;
|
||||
padding-left: 0.7rem;
|
||||
padding-right: 0.75rem;
|
||||
padding-top: 0.4rem;
|
||||
padding-bottom: 0.4rem;
|
||||
}
|
||||
|
||||
#references table, #references th, #references td {
|
||||
border: 0 none transparent;
|
||||
font-size: 1.125rem;
|
||||
}
|
||||
|
||||
#references table {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
#references th::before {
|
||||
content: "[";
|
||||
}
|
||||
#references th::after {
|
||||
content: "]";
|
||||
}
|
||||
|
||||
@media (max-width: 576px) {
|
||||
table:not(.footnote) {
|
||||
display: block;
|
||||
}
|
||||
pre, div.math {
|
||||
font-size: 0.5rem;
|
||||
}
|
||||
table {
|
||||
font-size: 0.6rem;
|
||||
}
|
||||
}
|
||||
|
||||
@media (min-width: 576px) {
|
||||
body > section {
|
||||
max-width: initial;
|
||||
width: 510px;
|
||||
}
|
||||
pre, div.math {
|
||||
font-size: 0.5rem;
|
||||
}
|
||||
table {
|
||||
font-size: 0.6rem;
|
||||
}
|
||||
}
|
||||
|
||||
@media (min-width: 768px) {
|
||||
body > section {
|
||||
width: 690px;
|
||||
}
|
||||
pre, div.math {
|
||||
font-size: 0.55rem;
|
||||
}
|
||||
table {
|
||||
font-size: 0.7rem;
|
||||
}
|
||||
}
|
||||
|
||||
@media (min-width: 992px) {
|
||||
body > section {
|
||||
width: 770px;
|
||||
}
|
||||
pre, div.math {
|
||||
font-size: 0.6rem;
|
||||
}
|
||||
table {
|
||||
font-size: 0.8rem;
|
||||
}
|
||||
}
|
||||
|
||||
@media (min-width: 1200px) {
|
||||
body > section {
|
||||
max-width: initial;
|
||||
width: 920px;
|
||||
}
|
||||
pre, div.math {
|
||||
font-size: 0.68rem;
|
||||
}
|
||||
table {
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
}
|
||||
|
||||
@media (min-width: 1390px) {
|
||||
body > section {
|
||||
max-width: initial;
|
||||
width: 1200px;
|
||||
}
|
||||
pre, div.math {
|
||||
font-size: 0.75rem;
|
||||
}
|
||||
table {
|
||||
font-size: 1rem;
|
||||
}
|
||||
}
|
|
@ -1,453 +0,0 @@
|
|||
<pre>
|
||||
ZIP: 0
|
||||
Title: ZIP Purpose and Guidelines
|
||||
Author: Daira Hopwood
|
||||
Status: Active
|
||||
Category: Process
|
||||
Created: 2011-08-19
|
||||
</pre>
|
||||
|
||||
==Terminology==
|
||||
|
||||
The following ... RFC 2119.
|
||||
|
||||
==What is a ZIP?==
|
||||
|
||||
ZIP stands for Zcash Improvement Proposal. A ZIP is a design document providing
|
||||
information to the Zcash community, or describing a new feature for Zcash or its
|
||||
processes or environment. The ZIP should provide a concise technical specification
|
||||
of the feature and a rationale for the feature.
|
||||
|
||||
We intend ZIPs to be the primary mechanisms for proposing new features, for
|
||||
collecting community input on an issue, and for documenting the design decisions
|
||||
that have gone into Zcash. The ZIP authors are responsible for building consensus
|
||||
within the community and documenting dissenting opinions.
|
||||
|
||||
ZIPs go through a sequence of versions as described under `ZIP Versioning`_.
|
||||
|
||||
ZIP Categories
|
||||
==============
|
||||
|
||||
There are three kinds of ZIP:
|
||||
|
||||
* A Standards Track ZIP describes any change that affects most or all Zcash
|
||||
implementations, such as a change to the network protocol, a change in block
|
||||
or transaction validity rules, or any change or addition that affects the
|
||||
interoperability of applications using Zcash. In particular, ZIPs that
|
||||
propose changes to consensus MUST be Standards Track.
|
||||
|
||||
* An Informational ZIP describes a Zcash design issue, or provides general
|
||||
guidelines or information to the Zcash community, but does not propose a
|
||||
new feature. Informational ZIPs do not necessarily represent a Zcash
|
||||
community consensus or recommendation, so users and implementors are free
|
||||
to ignore Informational ZIPs or follow their advice.
|
||||
|
||||
* A Process ZIP describes a process surrounding Zcash, or proposes a change
|
||||
to (or an event in) a process. Examples include procedures, guidelines,
|
||||
changes to the decision-making process, and changes to the tools or
|
||||
environment used in Zcash development. All Process ZIPs, and only
|
||||
Process ZIPs, have numbers less than 100.
|
||||
|
||||
|
||||
ZIP Work Flow
|
||||
=============
|
||||
|
||||
The ZIP process begins with a new idea for Zcash. ZIPs do not replace the
|
||||
`Zcash issue tracker`_; typically, an idea will first have been proposed as an issue on that
|
||||
tracker, and will be discussed there. Only when and if an idea has progressed to the point
|
||||
where it is useful to propose a more formal specification, will a ZIP be written.
|
||||
|
||||
.. _`Zcash issue tracker`: https://github.com/zcash/zcash/issues
|
||||
|
||||
Each potential ZIP must have one or more *authors* -- people who write the ZIP using the
|
||||
style and format described below, shepherd the discussions in the appropriate forums, and
|
||||
attempt to build community consensus around the idea. The authors of a ZIP are authorized
|
||||
to make ... The `ZIP Editors`_
|
||||
|
||||
Vetting an idea publicly before going as far as writing a ZIP is meant to save both the
|
||||
potential authors and the wider community time. The Zcash issue tracker contains many ideas
|
||||
for changing Zcash that have been rejected for various reasons. Searching this tracker and
|
||||
asking the Zcash community first if an idea is original helps prevent too much time being
|
||||
spent on something that is guaranteed to be rejected based on prior discussions. It also
|
||||
helps to make sure the idea is applicable to the entire community and not just the authors.
|
||||
Just because an idea sounds good to the authors does not mean it will work for most people
|
||||
in most areas where Zcash is used.
|
||||
|
||||
Small enhancements or patches often don't require a ZIP. These should typically be
|
||||
injected into the relevant Zcash development work flow with a pull request to the
|
||||
`Zcash issue tracker`_.
|
||||
|
||||
A ZIP should be a clear and complete description of the proposed enhancement.
|
||||
Technical aesthetics and security auditability are important considerations.
|
||||
|
||||
ZIPs need not, and generally SHOULD NOT, propose an implementation. (Note that this differs
|
||||
from common practice for Bitcoin Improvement Proposals.) They SHOULD, however, discuss
|
||||
non-trivial implementation considerations whenever appropriate.
|
||||
|
||||
The original form of a ZIP is written in (any regional variation of) English, but
|
||||
translations are encouraged and MAY be placed alongside the original by the ZIP Editor.
|
||||
|
||||
|
||||
Versioning
|
||||
==========
|
||||
|
||||
ZIPs are strictly versioned. The versioning scheme starts with "Draft 1", "Draft 2",
|
||||
etc., for how ever many drafts are needed. When and if the document is considered by
|
||||
its authors and the `ZIP Editor`_ to be stable, it becomes "Version 1". Any particular
|
||||
ZIP might not reach this stage. Subsequent revisions, if any, are called "Version 2",
|
||||
etc. for how ever many revisions are needed.
|
||||
|
||||
A ZIP also has a "Change history", separate from the document itself, giving a brief
|
||||
summary of the changes made in each version. See `Structure of the ZIPs Repository`_
|
||||
for detail on how the versions are represented.
|
||||
|
||||
The source files for a ZIP are maintained under revision control in the `ZIPs
|
||||
Repository`_, but the revision history of that repository MAY contain intermediate
|
||||
commits that do not correspond to document versions.
|
||||
|
||||
|
||||
ZIP Editors
|
||||
===========
|
||||
|
||||
The ZIP Editors are tasked with managing the process of accepting ZIPs, maintaining
|
||||
the ZIPs Repository, assigning ZIP numbers, and performing minor editing tasks on the
|
||||
content and metadata of ZIPs. Any major editing SHOULD instead be performed by the
|
||||
author(s) of a ZIP.
|
||||
|
||||
There is presently a single ZIP Editor, Daira Hopwood (but this document still
|
||||
uses "ZIP Editors" for generality). If there is more than one ZIP Editor at a
|
||||
given time, they make decisions by informal consensus.
|
||||
|
||||
A Process ZIP describing procedures for selecting new ZIP Editors as and when that
|
||||
becomes necessary SHOULD be submitted before January 1st, 2017.
|
||||
|
||||
The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for
|
||||
any of the following reasons:
|
||||
|
||||
* it violates the `Zcash Code of Conduct`_;
|
||||
* it appears too unfocussed or broad;
|
||||
* it duplicates effort in other ZIPs without sufficient technical justification
|
||||
(however, alternative proposals to address similar or overlapping problems
|
||||
are not excluded for this reason);
|
||||
* it has manifest security flaws (including being unrealistically dependent
|
||||
on user vigilance to avoid security weaknesses);
|
||||
* it disregards compatibility with the existing Zcash blockchain or ecosystem;
|
||||
* it is manifestly unimplementable;
|
||||
* it includes buggy code, pseudocode, or algorithms;
|
||||
* it manifestly violates common expectations of a significant portion of the
|
||||
Zcash community;
|
||||
* it updates a Draft ZIP to Released when there is significant community
|
||||
opposition to its content (however, Draft ZIPs explicitly may describe
|
||||
proposals to which there is, or could be expected, significant community
|
||||
opposition);
|
||||
* in the case of a Released ZIP, the update makes a substantive change to
|
||||
which there is significant community opposition;
|
||||
* it is dependent on a patent that could potentially be an obstacle to
|
||||
adoption of the ZIP;
|
||||
* it includes commercial advertising;
|
||||
* it disregards formatting rules;
|
||||
* it makes non-editorial edits to previous entries in a ZIP's Change history;
|
||||
* an update to an existing ZIP extends or changes its scope to an extent
|
||||
that would be better handled as a separate ZIP;
|
||||
* a new ZIP has been proposed for a category that does not reflect its content,
|
||||
or an update would change a ZIP to an inappropriate category;
|
||||
* it updates a Released ZIP to Draft when the specification is already
|
||||
implemented and has been in common use;
|
||||
* it violates any specific "MUST" or "MUST NOT" rule in this document;
|
||||
* the expressed political views of an author of the document are inimical
|
||||
to the `Zcash Code of Conduct`_ (except in the case of an update removing
|
||||
that author);
|
||||
* it is not authorized by the stated ZIP Authors;
|
||||
* it removes an author without their consent (unless the reason for removal
|
||||
is directly related to a breach of the Code of Conduct by that author);
|
||||
* it is spam.
|
||||
|
||||
.. _`Zcash Contributor Code of Conduct`: https://github.com/zcash/zcash/blob/master/code_of_conduct.md
|
||||
|
||||
The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update
|
||||
that does not violate any of these criteria. If they refuse a proposal or update,
|
||||
they MUST give an explanation of which of the criteria were violated, with the
|
||||
exception that spam may be deleted without an explanation.
|
||||
|
||||
Note that it is not the primary responsibility of the ZIP Editors to review
|
||||
proposals for security, correctness, or implementability.
|
||||
|
||||
Please send all ZIP-related communications either by email to <zips@z.cash>, or by
|
||||
opening an issue on the `ZIPs issue tracker`_. However if a communication concerns
|
||||
a potential security vulnerability that could affect Zcash users, the
|
||||
`Coordinated Security Disclosure Procedure`_ SHOULD be followed.
|
||||
|
||||
.. _`ZIPs issue tracker`: https://github.com/zcash/zips/issues
|
||||
|
||||
Authors of proposed ZIPs MUST NOT self-assign ZIP numbers. Proposals and updates
|
||||
SHOULD be made as pull requests to the ZIPs Repository. A proposal for a new ZIP
|
||||
MUST indicate whether it is intended to be Standards Track, Informational, or
|
||||
Process. It is also possible to update an Informational ZIP to be Standards Track
|
||||
or vice-versa, with the approval of the ZIP Editors. It is not possible to change
|
||||
a Process ZIP to another category of ZIP, or vice versa. Each ZIP MUST be initially
|
||||
proposed as a Draft.
|
||||
|
||||
A ZIP author may at any time withdraw their authorship on any or all versions
|
||||
of a ZIP (even if this results in there being no authors for a given version).
|
||||
Withdrawal of authorship is recorded in the ZIP metadata. An author who has
|
||||
changed their name, formally or informally, can also ask for their name to be
|
||||
updated on the ZIP metadata; the result will not include their previous name
|
||||
unless they ask for it to. (As a technical caveat, the previous name may still
|
||||
be visible in previous git revisions of the `ZIPs Repository`_ that remain
|
||||
publically accessible, although it may be possible to fix that by a force-push.)
|
||||
|
||||
|
||||
Relation to the Zcash Protocol Specification
|
||||
============================================
|
||||
|
||||
The `Zcash Protocol Specification`_ describes aspects of the
|
||||
|
||||
The canonical description of Zcash consensus and security requirements is the
|
||||
protocol specification. It is the responsibility of the ZIP Editors and the
|
||||
authors of the protocol specification to maintain consistency between the
|
||||
specification and ZIPs that overlap its scope.
|
||||
|
||||
The protocol specification SHOULD explicitly reference ZIPs that describe
|
||||
proposals that are incorporated into it. Duplication between the protocol
|
||||
specification and such ZIPs is inevitable and acceptable.
|
||||
|
||||
To minimize the risk of unintended discrepancies, a ZIP that proposes to change
|
||||
consensus behaviour SHOULD express its proposal in terms of specific text to be
|
||||
added or changed in the specification (in addition to motivation, history,
|
||||
alternative approaches that were not adopted, etc., which may not be appropriate
|
||||
for the specification).
|
||||
|
||||
|
||||
|
||||
It is highly recommended that a single ZIP contain a single key proposal or new
|
||||
idea. The more focussed the ZIP, the more successful it is likely to be. If in
|
||||
doubt, split your ZIP into several well-focussed ones.
|
||||
|
||||
Both initial proposals and updates to ZIPs SHOULD be submitted by an author of
|
||||
the document as a pull request to the `ZIPs repository`_.
|
||||
|
||||
A ZIP can also be assigned status "Deferred". The ZIP author or editor can assign
|
||||
the ZIP this status when no progress is being made on the ZIP. Once a ZIP is
|
||||
deferred, the ZIP editor can re-assign it to draft status.
|
||||
|
||||
A ZIP can also be "Rejected". Perhaps after all is said and done it was not a good
|
||||
idea. It is still important to have a record of this fact.
|
||||
|
||||
The possible paths of the status of ZIPs are as follows:
|
||||
|
||||
<img src=ZIP-0001/process.png></img>
|
||||
|
||||
Some Informational and Process ZIPs may also have a status of "Active" if they are
|
||||
never meant to be completed. E.g. ZIP 1 (this ZIP).
|
||||
|
||||
==What belongs in a successful ZIP?==
|
||||
|
||||
Each ZIP should have the following parts:
|
||||
|
||||
* Preamble -- RFC 822 style headers containing meta-data about the ZIP, including
|
||||
the ZIP number, a short descriptive title (limited to a maximum of 44 characters),
|
||||
the names, and optionally the contact info for each author, etc.
|
||||
|
||||
* Abstract -- a short description of the issue being addressed.
|
||||
|
||||
* Copyright -- Each ZIP MUST be licensed under the MIT License, unless the
|
||||
ZIP Editor makes an explicit exception to resolve a license incompatibility
|
||||
with a work from which the ZIP is derived. In the latter case the license
|
||||
MUST be explicitly stated in the ZIP metadata and MUST satisfy the
|
||||
`Open Source Definition`_ (interpreted to apply to documentation).
|
||||
|
||||
.. _`Open Source Definition`: https://opensource.org/osd-annotated
|
||||
|
||||
|
||||
* Specification -- The technical specification should describe the syntax and
|
||||
semantics of any new feature. The specification should be detailed enough to allow
|
||||
competing, interoperable implementations in principle (whether or not multiple
|
||||
implementations exist).
|
||||
|
||||
* Motivation -- The motivation is critical for ZIPs that want to change the Zcash
|
||||
protocol. It should clearly explain why the existing protocol specification is
|
||||
inadequate to address the problem that the ZIP solves. ZIP submissions without
|
||||
sufficient motivation may be rejected outright.
|
||||
|
||||
* Rationale -- The rationale fleshes out the specification by describing what
|
||||
motivated the design and why particular design decisions were made. It should
|
||||
describe alternate designs that were considered and related work.
|
||||
|
||||
* The rationale should provide evidence of consensus within the community and
|
||||
discuss important objections or concerns raised during discussion.
|
||||
|
||||
* Backwards Compatibility -- All ZIPs that introduce backwards incompatibilities
|
||||
MUST include a section describing these incompatibilities and their severity. The
|
||||
ZIP MUST explain how the author proposes to deal with these incompatibilities.
|
||||
|
||||
|
||||
Formatting Rules
|
||||
================
|
||||
|
||||
The metadata of a ZIP MUST be represented as a reStructuredText file.
|
||||
This file includes:
|
||||
|
||||
* a Change history ...
|
||||
* the current authors.
|
||||
|
||||
Each Change history entry includes:
|
||||
|
||||
* a description of what was changed (this can be just "initial draft" or
|
||||
similar in the case of the first draft).
|
||||
* a link to the main reStructuredText or LaTeX source file for that
|
||||
version.
|
||||
* a link to a rendered PDF file for that version.
|
||||
* the new authors, if this is the first draft or the authors have changed.
|
||||
|
||||
|
||||
ZIPs can be represented in either `reStructuredText`_ or `LaTeX`_ format.
|
||||
|
||||
Images and diagrams can be included ..., provided that a rendering to
|
||||
a PNG image is included. SVG is a preferred source format.
|
||||
The ZIP Editor MAY accept other formats. Formats that depend on proprietary
|
||||
software are strongly discouraged.
|
||||
|
||||
|
||||
Rules specific to reStructuredText
|
||||
----------------------------------
|
||||
|
||||
The source for the `rst` file MUST be readable in an editor window set to
|
||||
90 columns, except possibly where prevented by reStructuredText technical
|
||||
limitations (such as avoiding wrapping of URLs).
|
||||
|
||||
The document MAY include images in .png format.
|
||||
|
||||
|
||||
Rules specific to LaTeX
|
||||
-----------------------
|
||||
|
||||
The ZIP directory MUST contain a ``Makefile``, the default target of
|
||||
which produces a PDF file.
|
||||
|
||||
The README.rst file MUST include instructions to build the PDF (including
|
||||
build dependencies for at least Debian-like systems).
|
||||
|
||||
The typographical conventions used by a LaTeX-formatted ZIP SHOULD be
|
||||
consistent, as far as possible, with those used in the `Zcash protocol specification`_.
|
||||
It is desirable, but not strictly necessary, that the macros used in
|
||||
the protocol specification also be used in LaTeX-formatted ZIPs. This
|
||||
facilitates editing accepted proposals into the main specification.
|
||||
|
||||
|
||||
===ZIP Header Preamble===
|
||||
|
||||
Each ZIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
|
||||
|
||||
<pre>
|
||||
ZIP: <ZIP number>
|
||||
Title: <ZIP title>
|
||||
Author: <list of authors' real names and optionally, email addrs>
|
||||
* Discussions-To: <email address>
|
||||
Status: <Draft | Active | Accepted | Deferred | Rejected |
|
||||
Withdrawn | Final | Superseded>
|
||||
Type: <Standards Track | Informational | Process>
|
||||
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
|
||||
* Post-History: <dates of postings to Zcash mailing list>
|
||||
* Replaces: <ZIP number>
|
||||
* Superseded-By: <ZIP number>
|
||||
* Resolution: <url>
|
||||
</pre>
|
||||
|
||||
The Author header lists the names, and optionally the email addresses of all the authors/owners of the ZIP. The format of the Author header value must be
|
||||
|
||||
Random J. User <address@dom.ain>
|
||||
|
||||
if the email address is included, and just
|
||||
|
||||
Random J. User
|
||||
|
||||
if the address is not given.
|
||||
|
||||
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
|
||||
|
||||
Note: The Resolution header is required for Standards Track ZIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the ZIP is made.
|
||||
|
||||
While a ZIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the ZIP is being discussed. No Discussions-To header is necessary if the ZIP is being discussed privately with the author, or on the bitcoin email mailing lists.
|
||||
|
||||
The Type header specifies the type of ZIP: Standards Track, Informational, or Process.
|
||||
|
||||
The Created header records the date that the ZIP was assigned a number, while Post-History is used to record the dates of when new versions of the ZIP are posted to Zcash mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
|
||||
|
||||
ZIPs may have a Requires header, indicating the ZIP numbers that this ZIP depends on.
|
||||
|
||||
ZIPs may also have a Superseded-By header indicating that a ZIP has been rendered obsolete by a later document; the value is the number of the ZIP that replaces the current document. The newer ZIP must have a Replaces header containing the number of the ZIP that it rendered obsolete.
|
||||
|
||||
===Auxiliary Files===
|
||||
|
||||
ZIPs may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that ZIP. Auxiliary files must be named ZIP-XXXX-Y.ext, where "XXXX" is the ZIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").
|
||||
|
||||
==Transferring ZIP Ownership==
|
||||
|
||||
It occasionally becomes necessary to transfer ownership of ZIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred ZIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the ZIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ZIP. We try to build consensus around a ZIP, but if that's not possible, you can always submit a competing ZIP.
|
||||
|
||||
If you are interested in assuming ownership of a ZIP, send a message asking to take over, addressed to both the original author and the ZIP editor. If the original author doesn't respond to email in a timely manner, the ZIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
|
||||
|
||||
==ZIP Editors==
|
||||
|
||||
The current ZIP editor is Luke Dashjr who can be contacted at [[mailto:luke_ZIPeditor@dashjr.org|luke_ZIPeditor@dashjr.org]].
|
||||
|
||||
==ZIP Editor Responsibilities & Workflow==
|
||||
|
||||
The ZIP editor subscribes to the Zcash development mailing list. All ZIP-related
|
||||
correspondence should be sent (or CC'd) to luke_ZIPeditor@dashjr.org.
|
||||
|
||||
For each new ZIP that comes in an editor does the following:
|
||||
|
||||
* Read the ZIP to check if it is ready: sound and complete. The ideas must make technical
|
||||
sense, even if they don't seem likely to be accepted.
|
||||
* The title should accurately describe the content.
|
||||
* Edit the ZIP for language (spelling, grammar, sentence structure, etc.),
|
||||
markup, code style (examples should match ZIP 8 & 7).
|
||||
|
||||
If the ZIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
|
||||
|
||||
Once the ZIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/Zcash/ZIPs Zcash/ZIPs] repository on GitHub where it may get further feedback.
|
||||
|
||||
The ZIP Editors will:
|
||||
|
||||
* Assign a ZIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.
|
||||
|
||||
* Merge the pull request when the author is ready (allowing some time for further peer review).
|
||||
|
||||
* List the ZIP in [[README.mediawiki]]
|
||||
|
||||
* Send email back to the ZIP author with next steps (post to Zcash-dev mailing list).
|
||||
|
||||
The ZIP editors are intended to fulfill administrative and editorial responsibilities. The ZIP editors monitor ZIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
|
||||
|
||||
==History==
|
||||
|
||||
This document is derived heavily from Bitcoin's BIP 1, authored by Amir Taaki,
|
||||
which in turn was derived from Python's PEP-0001. In many places text was simply
|
||||
copied and modified. The authors of PEP-0001 (Barry Warsaw, Jeremy Hylton, and
|
||||
David Goodger) and BIP 1 (Amir Taaki) are not responsible for any use of their
|
||||
text or ideas in the Zcash Improvement Process. The `I2P Proposal Process`_
|
||||
and the RFC Process also influenced this document.
|
||||
|
||||
Please direct all comments to the ZIP Editors by email to <zips@z.cash> or by
|
||||
filing an issue in the `ZIPs issue tracker`_.
|
||||
|
||||
|
||||
|
||||
Change history (move this to metadata)
|
||||
==============
|
||||
|
||||
Draft 1
|
||||
-------
|
||||
|
||||
Initial version based mainly on BIP 1. Changes include:
|
||||
|
||||
* Obvious renamings.
|
||||
* Changes of forum, e.g. Zcash development uses GitHub repositories
|
||||
and issue tracking to a greater extent than Bitcoin, and does not
|
||||
rely on mailing lists.
|
||||
* We use "ZIP Editors" even though that is currently only one person.
|
||||
Similarly a given ZIP may have more than one author, and authors
|
||||
have equal status.
|
||||
* The list of potential reasons for rejection of a ZIP is expanded
|
||||
from the corresponding reasons for a BIP, and more precisely defined.
|
|
@ -0,0 +1,41 @@
|
|||
#!/bin/sh
|
||||
|
||||
if ! ( ( [ "x$1" = "x--rst" ] && [ $# -eq 2 ] ) || ( [ "x$1" = "x--md" ] && [ $# -eq 3 ] ) ); then
|
||||
echo "Usage: edithtml.sh --rst <htmlfile>"
|
||||
echo " or: edithtml.sh --md <htmlfile> <title>"
|
||||
exit
|
||||
fi
|
||||
|
||||
if ! [ -f "$2" ]; then
|
||||
echo File not found: "$2"
|
||||
exit
|
||||
fi
|
||||
|
||||
if [ "x$1" = "x--rst" ]; then
|
||||
sed -i.sedbak 's|</head>|<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>|' $2
|
||||
sed -i.sedbak 's|http://cdn.mathjax.org/mathjax/latest/MathJax.js|https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js|' $2
|
||||
else
|
||||
cat - "$2" >"$2".prefix <<EOF
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>$3</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>
|
||||
EOF
|
||||
cat "$2.prefix" - >"$2" <<EOF
|
||||
</body>
|
||||
</html>
|
||||
EOF
|
||||
rm -f "$2".prefix
|
||||
fi
|
||||
|
||||
sed -i.sedbak 's|<a \(class=[^ ]* \)*href="\([^":]*\)\.rst\(\#[^"]*\)*">|<a \1href="\2\3">|g' "$2"
|
||||
sed -i.sedbak 's|<\(https:[^&]*\)>|\<<a href="\1">\1</a>\>|g' "$2"
|
||||
|
||||
perl -i.sedbak -p0e 's|<section id="([^"]*)">\s*.?\s*<h([1-9])>([^<]*(?:<code>[^<]*</code>[^<]*)?)</h([1-9])>|<section id="\1"><h\2><span class="section-heading">\3</span><span class="section-anchor"> <a rel="bookmark" href="#\1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h\4>|g' "$2"
|
||||
|
||||
rm -f *.sedbak
|
|
@ -0,0 +1,137 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>README: Specifications and Zcash Improvement Proposals</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<!-- Title: Specifications and Zcash Improvement Proposals -->
|
||||
<section id="what-are-zips"><h2><span class="section-heading">What are ZIPs?</span><span class="section-anchor"> <a rel="bookmark" href="#what-are-zips"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash Improvement Proposals (ZIPs) are the way to:</p>
|
||||
<ul>
|
||||
<li>propose new features for the <a href="https://z.cash/">Zcash cryptocurrency</a> and their rationale,</li>
|
||||
<li>specify the implementation details of the feature,</li>
|
||||
<li>collect community input on the proposal, and</li>
|
||||
<li>document design decisions.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="contributing"><h2><span class="section-heading">Contributing</span><span class="section-anchor"> <a rel="bookmark" href="#contributing"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The authors of a ZIP are responsible for building consensus within the community and documenting / addressing dissenting opinions.</p>
|
||||
<p>Anyone can write a ZIP! We encourage community contributions and decentralization of work on the Zcash protocol. If you’d like to bounce ideas off people before formally writing a ZIP, we encourage it! Visit the <a href="https://discord.gg/kdjfvps">ZcashCommunity Discord chat</a> to talk about your idea.</p>
|
||||
<p>Participation in the Zcash project is subject to a <a href="https://github.com/zcash/zcash/blob/master/code_of_conduct.md">Code of Conduct</a>.</p>
|
||||
<p>The Zcash protocol is documented in its <a href="protocol/protocol.pdf">Protocol Specification</a>.</p>
|
||||
<p>To start contributing, first read <a href="zip-0000">ZIP 0</a> which documents the ZIP process. Then clone <a href="https://github.com/zcash/zips">this repo</a> from GitHub, and start adding your draft ZIP, formatted either as reStructuredText or as Markdown.</p>
|
||||
<p>For example, if using reStructuredText, use a filename matching <code>draft-*.rst</code>. Use <code>make</code> to check that you are using correct <a href="https://docutils.sourceforge.io/rst.html">reStructuredText</a> or <a href="https://pandoc.org/MANUAL.html#pandocs-markdown">Markdown</a> syntax, and double-check the generated <code>draft-*.html</code> file before filing a Pull Request.</p>
|
||||
</section>
|
||||
<section id="nu5-zips"><h2><span class="section-heading">NU5 ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-zips"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This is the list of ZIPs relevant to the NU5 Upgrade, which <a href="https://z.cash/upgrade/nu5/">activated on 31st May 2022</a>:</p>
|
||||
<ul>
|
||||
<li><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a> (updated)</li>
|
||||
<li><a href="zip-0203">ZIP 203: Transaction Expiry</a> (updated)</li>
|
||||
<li><a href="zip-0209">ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances</a> (updated)</li>
|
||||
<li><a href="zip-0212">ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext</a> (updated)</li>
|
||||
<li><a href="zip-0213">ZIP 213: Shielded Coinbase</a> (updated)</li>
|
||||
<li><a href="zip-0216">ZIP 216: Require Canonical Jubjub Point Encodings</a></li>
|
||||
<li><a href="zip-0221">ZIP 221: FlyClient - Consensus-Layer Changes</a> (updated)</li>
|
||||
<li><a href="zip-0224">ZIP 224: Orchard Shielded Protocol</a></li>
|
||||
<li><a href="zip-0225">ZIP 225: Version 5 Transaction Format</a></li>
|
||||
<li><a href="zip-0239">ZIP 239: Relay of Version 5 Transactions</a></li>
|
||||
<li><a href="zip-0244">ZIP 244: Transaction Identifier Non-Malleability</a></li>
|
||||
<li><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></li>
|
||||
<li><a href="zip-0316">ZIP 316: Unified Addresses and Unified Viewing Keys</a></li>
|
||||
<li><a href="zip-0401">ZIP 401: Addressing Mempool Denial-of-Service</a> (clarified)</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="license"><h2><span class="section-heading">License</span><span class="section-anchor"> <a rel="bookmark" href="#license"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Unless otherwise stated in this repository’s individual files, the contents of this repository are released under the terms of the MIT license. See <a href="COPYING">COPYING</a> for more information or see <a href="https://opensource.org/licenses/MIT">https://opensource.org/licenses/MIT</a> .</p>
|
||||
</section>
|
||||
<section id="index-of-zips"><h2><span class="section-heading">Index of ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#index-of-zips"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<embed><table>
|
||||
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
|
||||
<tr> <td>0</td> <td class="left"><a href="zip-0000">ZIP Process</a></td> <td>Active</td>
|
||||
<tr> <td><span class="reserved">1</span></td> <td class="left"><a class="reserved" href="zip-0001">Network Upgrade Policy and Scheduling</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">2</span></td> <td class="left"><a class="reserved" href="zip-0002">Design Considerations for Network Upgrades</a></td> <td>Reserved</td>
|
||||
<tr> <td>32</td> <td class="left"><a href="zip-0032">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">76</span></td> <td class="left"><a class="reserved" href="zip-0076">Transaction Signature Validation before Overwinter</a></td> <td>Reserved</td>
|
||||
<tr> <td>143</td> <td class="left"><a href="zip-0143">Transaction Signature Validation for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>155</td> <td class="left"><a href="zip-0155">addrv2 message</a></td> <td>Proposed</td>
|
||||
<tr> <td>173</td> <td class="left"><a href="zip-0173">Bech32 Format</a></td> <td>Final</td>
|
||||
<tr> <td>200</td> <td class="left"><a href="zip-0200">Network Upgrade Mechanism</a></td> <td>Final</td>
|
||||
<tr> <td>201</td> <td class="left"><a href="zip-0201">Network Peer Management for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>202</td> <td class="left"><a href="zip-0202">Version 3 Transaction Format for Overwinter</a></td> <td>Final</td>
|
||||
<tr> <td>203</td> <td class="left"><a href="zip-0203">Transaction Expiry</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">204</span></td> <td class="left"><a class="reserved" href="zip-0204">Zcash P2P Network Protocol</a></td> <td>Reserved</td>
|
||||
<tr> <td>205</td> <td class="left"><a href="zip-0205">Deployment of the Sapling Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>206</td> <td class="left"><a href="zip-0206">Deployment of the Blossom Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>207</td> <td class="left"><a href="zip-0207">Funding Streams</a></td> <td>Final</td>
|
||||
<tr> <td>208</td> <td class="left"><a href="zip-0208">Shorter Block Target Spacing</a></td> <td>Final</td>
|
||||
<tr> <td>209</td> <td class="left"><a href="zip-0209">Prohibit Negative Shielded Chain Value Pool Balances</a></td> <td>Final</td>
|
||||
<tr> <td><strike>210</strike></td> <td class="left"><strike><a href="zip-0210">Sapling Anchor Deduplication within Transactions</a></strike></td> <td>Withdrawn</td>
|
||||
<tr> <td>211</td> <td class="left"><a href="zip-0211">Disabling Addition of New Value to the Sprout Chain Value Pool</a></td> <td>Final</td>
|
||||
<tr> <td>212</td> <td class="left"><a href="zip-0212">Allow Recipient to Derive Ephemeral Secret from Note Plaintext</a></td> <td>Final</td>
|
||||
<tr> <td>213</td> <td class="left"><a href="zip-0213">Shielded Coinbase</a></td> <td>Final</td>
|
||||
<tr> <td>214</td> <td class="left"><a href="zip-0214">Consensus rules for a Zcash Development Fund</a></td> <td>Final</td>
|
||||
<tr> <td>215</td> <td class="left"><a href="zip-0215">Explicitly Defining and Modifying Ed25519 Validation Rules</a></td> <td>Final</td>
|
||||
<tr> <td>216</td> <td class="left"><a href="zip-0216">Require Canonical Jubjub Point Encodings</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">217</span></td> <td class="left"><a class="reserved" href="zip-0217">Aggregate Signatures</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">219</span></td> <td class="left"><a class="reserved" href="zip-0219">Disabling Addition of New Value to the Sapling Chain Value Pool</a></td> <td>Reserved</td>
|
||||
<tr> <td><strike>220</strike></td> <td class="left"><strike><a href="zip-0220">Zcash Shielded Assets</a></strike></td> <td>Withdrawn</td>
|
||||
<tr> <td>221</td> <td class="left"><a href="zip-0221">FlyClient - Consensus-Layer Changes</a></td> <td>Final</td>
|
||||
<tr> <td>222</td> <td class="left"><a href="zip-0222">Transparent Zcash Extensions</a></td> <td>Draft</td>
|
||||
<tr> <td>224</td> <td class="left"><a href="zip-0224">Orchard Shielded Protocol</a></td> <td>Final</td>
|
||||
<tr> <td>225</td> <td class="left"><a href="zip-0225">Version 5 Transaction Format</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226">Zcash Shielded Assets - Transfers and Burns</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227">Zcash Shielded Assets - Issuance</a></td> <td>Reserved</td>
|
||||
<tr> <td>239</td> <td class="left"><a href="zip-0239">Relay of Version 5 Transactions</a></td> <td>Final</td>
|
||||
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
|
||||
<tr> <td>244</td> <td class="left"><a href="zip-0244">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
|
||||
<tr> <td>245</td> <td class="left"><a href="zip-0245">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
|
||||
<tr> <td>250</td> <td class="left"><a href="zip-0250">Deployment of the Heartwood Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>251</td> <td class="left"><a href="zip-0251">Deployment of the Canopy Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>252</td> <td class="left"><a href="zip-0252">Deployment of the NU5 Network Upgrade</a></td> <td>Final</td>
|
||||
<tr> <td>300</td> <td class="left"><a href="zip-0300">Cross-chain Atomic Transactions</a></td> <td>Proposed</td>
|
||||
<tr> <td>301</td> <td class="left"><a href="zip-0301">Zcash Stratum Protocol</a></td> <td>Final</td>
|
||||
<tr> <td>302</td> <td class="left"><a href="zip-0302">Standardized Memo Field Format</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">303</span></td> <td class="left"><a class="reserved" href="zip-0303">Sprout Payment Disclosure</a></td> <td>Reserved</td>
|
||||
<tr> <td>304</td> <td class="left"><a href="zip-0304">Sapling Address Signatures</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">305</span></td> <td class="left"><a class="reserved" href="zip-0305">Best Practices for Hardware Wallets supporting Sapling</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">306</span></td> <td class="left"><a class="reserved" href="zip-0306">Security Considerations for Anchor Selection</a></td> <td>Reserved</td>
|
||||
<tr> <td>307</td> <td class="left"><a href="zip-0307">Light Client Protocol for Payment Detection</a></td> <td>Draft</td>
|
||||
<tr> <td>308</td> <td class="left"><a href="zip-0308">Sprout to Sapling Migration</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">309</span></td> <td class="left"><a class="reserved" href="zip-0309">Blind Off-chain Lightweight Transactions (BOLT)</a></td> <td>Reserved</td>
|
||||
<tr> <td>310</td> <td class="left"><a href="zip-0310">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">311</span></td> <td class="left"><a class="reserved" href="zip-0311">Sapling Payment Disclosure</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">312</span></td> <td class="left"><a class="reserved" href="zip-0312">Shielded Multisignatures using FROST</a></td> <td>Reserved</td>
|
||||
<tr> <td>313</td> <td class="left"><a href="zip-0313">Reduce Conventional Transaction Fee to 1000 zatoshis</a></td> <td>Active</td>
|
||||
<tr> <td><span class="reserved">314</span></td> <td class="left"><a class="reserved" href="zip-0314">Privacy upgrades to the Zcash light client protocol</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">315</span></td> <td class="left"><a class="reserved" href="zip-0315">Best Practices for Wallet Handling of Multiple Pools</a></td> <td>Reserved</td>
|
||||
<tr> <td>316</td> <td class="left"><a href="zip-0316">Unified Addresses and Unified Viewing Keys</a></td> <td>Final</td>
|
||||
<tr> <td>321</td> <td class="left"><a href="zip-0321">Payment Request URIs</a></td> <td>Proposed</td>
|
||||
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322">Generic Signed Message Format</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339">Wallet Recovery Words</a></td> <td>Reserved</td>
|
||||
<tr> <td>400</td> <td class="left"><a href="zip-0400">Wallet.dat format</a></td> <td>Draft</td>
|
||||
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
|
||||
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402">New Wallet Database Format</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
|
||||
<tr> <td><strike>1001</strike></td> <td class="left"><strike><a href="zip-1001">Keep the Block Distribution as Initially Defined — 90% to Miners</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1002</strike></td> <td class="left"><strike><a href="zip-1002">Opt-in Donation Feature</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1003</strike></td> <td class="left"><strike><a href="zip-1003">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1004</strike></td> <td class="left"><strike><a href="zip-1004">Miner-Directed Dev Fund</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1005</strike></td> <td class="left"><strike><a href="zip-1005">Zcash Community Funding System</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1006</strike></td> <td class="left"><strike><a href="zip-1006">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1007</strike></td> <td class="left"><strike><a href="zip-1007">Enforce Development Fund Commitments with a Legal Charter</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1008</strike></td> <td class="left"><strike><a href="zip-1008">Fund ECC for Two More Years</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1009</strike></td> <td class="left"><strike><a href="zip-1009">Five-Entity Strategic Council</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1010</strike></td> <td class="left"><strike><a href="zip-1010">Compromise Dev Fund Proposal With Diverse Funding Streams</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1011</strike></td> <td class="left"><strike><a href="zip-1011">Decentralize the Dev Fee</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1012</strike></td> <td class="left"><strike><a href="zip-1012">Dev Fund to ECC + ZF + Major Grants</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td><strike>1013</strike></td> <td class="left"><strike><a href="zip-1013">Keep It Simple, Zcashers: 10% to ECC, 10% to ZF</a></strike></td> <td>Obsolete</td>
|
||||
<tr> <td>1014</td> <td class="left"><a href="zip-1014">Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td> <td>Active</td>
|
||||
<tr> <td>guide</td> <td class="left"><a href="zip-guide">{Something Short and To the Point}</a></td> <td>Draft</td>
|
||||
</table></embed></section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,224 @@
|
|||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
|
||||
from urllib.request import build_opener, HTTPCookieProcessor, HTTPSHandler, Request
|
||||
from urllib.error import URLError, HTTPError
|
||||
from os.path import relpath
|
||||
from collections import deque
|
||||
import sys
|
||||
from time import sleep
|
||||
import ssl
|
||||
from io import BytesIO
|
||||
|
||||
try:
|
||||
from bs4 import BeautifulSoup
|
||||
import html5lib
|
||||
import certifi
|
||||
except ImportError:
|
||||
print("Please install the BeautifulSoup, html5lib, and certifi libraries using `pip install bs4 html5lib certifi`.\n")
|
||||
raise
|
||||
|
||||
if [int(v) for v in certifi.__version__.split('.')] < [2021, 5, 30]:
|
||||
print("Please upgrade certifi using `pip install --upgrade certifi`.\n")
|
||||
sys.exit(1)
|
||||
|
||||
def get_links_and_destinations_from_pdf(f):
|
||||
try:
|
||||
from PyPDF2 import PdfFileReader
|
||||
except ImportError:
|
||||
print("Please install the PyPDF2 library using `pip install PyPDF2`.\n")
|
||||
raise
|
||||
|
||||
# Based on <https://stackoverflow.com/a/5978161/393146>
|
||||
pdf = PdfFileReader(f)
|
||||
|
||||
links = set()
|
||||
for pg in range(pdf.getNumPages()):
|
||||
obj = pdf.getPage(pg).getObject()
|
||||
|
||||
for annotation in obj.get('/Annots', []):
|
||||
uri = annotation.getObject().get('/A', {}).get('/URI', None)
|
||||
if uri is not None and uri not in links:
|
||||
links.add(uri)
|
||||
|
||||
dests = pdf.getNamedDestinations().keys()
|
||||
|
||||
return (links, dests)
|
||||
|
||||
|
||||
def get_links_and_destinations_from_html(f):
|
||||
links = set()
|
||||
internal = set()
|
||||
dests = set()
|
||||
|
||||
soup = BeautifulSoup(f.read(), "html5lib")
|
||||
for link in soup.find_all('a'):
|
||||
if link.has_attr('href'):
|
||||
url = link['href']
|
||||
(internal if url.startswith('#') else links).add(url)
|
||||
|
||||
if link.has_attr('name'):
|
||||
dests.add(link['name'])
|
||||
|
||||
for link in soup.find_all(id=True):
|
||||
dests.add(link['id'])
|
||||
# GitHub's rendering of .mediawiki files puts 'id="user-content-<ANCHOR>"' in the source
|
||||
# and dynamically creates a corresponding link #<ANCHOR>.
|
||||
if link['id'].startswith("user-content-"):
|
||||
dests.add(link['id'][13:])
|
||||
|
||||
internal.difference_update(['#' + d for d in dests]) # ignore internal links satisfied by a dest
|
||||
links.update(internal)
|
||||
return (links, dests)
|
||||
|
||||
|
||||
def main(args):
|
||||
if len(args) < 2:
|
||||
print("Usage: ./links_and_dests.py [--check] [--print-dests] <file.pdf|html|xhtml>")
|
||||
return 1
|
||||
|
||||
check = '--check' in args[1:]
|
||||
print_dests = '--print-dests' in args[1:]
|
||||
paths = [arg for arg in args[1:] if not arg.startswith('--')]
|
||||
|
||||
all_links = {} # url -> pdf_paths
|
||||
all_dests = {} # url -> dests
|
||||
|
||||
errors = deque()
|
||||
|
||||
print("Reading files...")
|
||||
for path in paths:
|
||||
print(path, end=" ")
|
||||
sys.stdout.flush()
|
||||
|
||||
with open(path, 'rb') as f:
|
||||
if path.endswith(".html") or path.endswith(".xhtml"):
|
||||
(links, dests) = get_links_and_destinations_from_html(f)
|
||||
elif path.endswith(".pdf"):
|
||||
(links, dests) = get_links_and_destinations_from_pdf(f)
|
||||
else:
|
||||
errors.append("Unrecognized file type: " + path)
|
||||
continue
|
||||
|
||||
path = relpath(path)
|
||||
for l in links:
|
||||
refs = all_links.get(l, None)
|
||||
if refs is None:
|
||||
all_links[l] = refs = deque()
|
||||
refs.append(path)
|
||||
|
||||
all_dests["https://zips.z.cash/" + path] = dests
|
||||
if path.endswith(".html"):
|
||||
all_dests["https://zips.z.cash/" + path[:-5]] = dests
|
||||
|
||||
print("\n")
|
||||
print("Links:")
|
||||
|
||||
last_url = None
|
||||
content = None
|
||||
content_type = None
|
||||
dests = None
|
||||
|
||||
for (l, p) in sorted(all_links.items()):
|
||||
print(l, end=" ")
|
||||
sys.stdout.flush()
|
||||
what = "%s (occurs in %s)" % (l, " and ".join(p)) if len(paths) > 1 else l
|
||||
status = ""
|
||||
|
||||
if ":" not in l:
|
||||
l = "https://zips.z.cash/" + l
|
||||
|
||||
if l.startswith("mailto:"):
|
||||
status = "(not checked)"
|
||||
elif l.startswith("https:") or l.startswith("HTTP:"): # use uppercase HTTP: for links with no https: equivalent
|
||||
(url, _, fragment) = l.partition("#")
|
||||
|
||||
if url in all_dests:
|
||||
if fragment and fragment not in all_dests[url]:
|
||||
errors.append("Missing link target: " + what)
|
||||
status = "❌"
|
||||
else:
|
||||
status = "✓"
|
||||
elif check:
|
||||
# If url == last_url, there is no need to refetch content. This is an optimization when
|
||||
# checking URLs with the same site but different fragments (which will be sorted together).
|
||||
if url != last_url:
|
||||
headers = {"User-Agent": "Mozilla/5.0"}
|
||||
https_handler = HTTPSHandler(context=ssl.create_default_context(cafile=certifi.where()))
|
||||
|
||||
# Some DOI links (i.e. to https://doi.org/) redirect to link.springer.com
|
||||
# in a way that requires cookies (booo!). We allow this for DOI links,
|
||||
# but for all other links we simulate a client that never sets cookies.
|
||||
if l.startswith("https://doi.org/"):
|
||||
opener = build_opener(HTTPCookieProcessor(), https_handler)
|
||||
else:
|
||||
opener = build_opener(https_handler)
|
||||
|
||||
for retry in range(2):
|
||||
try:
|
||||
response = opener.open(Request(url=l, headers=headers))
|
||||
content_type = response.info().get_content_type()
|
||||
content = response.read()
|
||||
last_url = url
|
||||
except URLError as e:
|
||||
if retry == 0 and isinstance(e, HTTPError) and e.code == 429:
|
||||
try:
|
||||
delay = int(e.headers['Retry-After'], 10) + 1
|
||||
except Exception:
|
||||
delay = 60
|
||||
|
||||
print("(waiting %ds due to rate limiting)" % (delay,), end=" ")
|
||||
sys.stdout.flush()
|
||||
sleep(delay)
|
||||
continue
|
||||
|
||||
errors.append("Could not open link: %s due to %r" % (what, e))
|
||||
status = "❌"
|
||||
content_type = None
|
||||
content = None
|
||||
last_url = None
|
||||
|
||||
dests = None
|
||||
break
|
||||
|
||||
if content is not None:
|
||||
if fragment:
|
||||
if dests is None:
|
||||
if content_type in ('text/html', 'application/xhtml+xml'):
|
||||
(_, dests) = get_links_and_destinations_from_html(BytesIO(content))
|
||||
elif content_type == 'application/pdf':
|
||||
(_, dests) = get_links_and_destinations_from_pdf(BytesIO(content))
|
||||
|
||||
if dests is None:
|
||||
print("(link target not checked)", end=" ")
|
||||
status = "✓"
|
||||
elif fragment not in dests:
|
||||
errors.append("Missing link target: " + what)
|
||||
status = "❌"
|
||||
else:
|
||||
status = "✓"
|
||||
else:
|
||||
status = "✓"
|
||||
else:
|
||||
errors.append("Insecure or unrecognized protocol in link: " + what)
|
||||
status = "❌"
|
||||
|
||||
print(status)
|
||||
|
||||
if print_dests:
|
||||
for (path, dests) in all_dests.items():
|
||||
if path + ".html" not in all_dests: # avoid duplication
|
||||
print("\nDestinations for %s:" % (path,))
|
||||
for d in dests:
|
||||
print(d)
|
||||
|
||||
if errors:
|
||||
print("\nErrors:")
|
||||
for e in errors:
|
||||
print(e)
|
||||
|
||||
return 0
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
sys.exit(main(sys.argv))
|
|
@ -0,0 +1,23 @@
|
|||
#!/bin/sh
|
||||
|
||||
cat <<EndOfHeader
|
||||
|
||||
Index of ZIPs
|
||||
-------------
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<embed><table>
|
||||
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
|
||||
EndOfHeader
|
||||
for zipfile in zip-*.rst; do
|
||||
echo Adding $zipfile to index. >/dev/stderr
|
||||
if grep -E '^\s*Status:\s*Reserved' $zipfile >/dev/null; then
|
||||
echo " <tr> <td><span class=\"reserved\">`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'`</span></td> <td class=\"left\"><a class=\"reserved\" href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'`</a></td> <td>`grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`</td>"
|
||||
elif grep -E '^\s*Status:\s*(Withdrawn|Rejected|Obsolete)' $zipfile >/dev/null; then
|
||||
echo " <tr> <td><strike>`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'`</strike></td> <td class=\"left\"><strike><a href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'`</a></strike></td> <td>`grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`</td>"
|
||||
else
|
||||
echo " <tr> <td>`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'`</td> <td class=\"left\"><a href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'`</a></td> <td>`grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`</td>"
|
||||
fi
|
||||
done
|
||||
echo " </table></embed>"
|
|
@ -1,113 +1,185 @@
|
|||
LATEXMK=latexmk --halt-on-error -bibtex -pdf
|
||||
LATEX=pdflatex --halt-on-error
|
||||
SHELL=/bin/bash -eo pipefail
|
||||
|
||||
sprout.pdf: protocol.tex zcash.bib incremental_merkle.pdf key_components.pdf
|
||||
$(MAKE) pdf
|
||||
# Experimental; options are pdflatex, lualatex, or xelatex.
|
||||
# On Debian, LuaLaTeX needs the texlive-luatex package, and XeLaTeX needs the texlive-xetex package.
|
||||
# Make sure to read <https://github.com/zcash/zips/issues/249>.
|
||||
ENGINE=pdflatex
|
||||
|
||||
sapling.pdf: protocol.tex zcash.bib incremental_merkle.pdf key_components_sapling.pdf
|
||||
LATEXMKOPT_pdflatex=
|
||||
LATEXMKOPT_xelatex=-pdflatex=xelatex -dvi- -ps-
|
||||
LATEXMKOPT_lualatex=-pdflatex=lualatex -dvi- -ps-
|
||||
|
||||
LATEXMK=max_print_line=10000 latexmk $(LATEXMKOPT_$(ENGINE)) --halt-on-error --file-line-error -bibtex -pdf -logfilewarnings- -e '$$max_repeat=8'
|
||||
LATEX=$(ENGINE) --halt-on-error --file-line-error
|
||||
NOCRUFT?=|perl -pe 's|[{\<\(]\/[^ ]* ?||g;s|^.* has been referenced but does not exist.*||g;s|^\n||g'
|
||||
|
||||
# Use EXTRAOPT=-pvc for "continuous preview" mode. For example, "make auxblossom EXTRAOPT=-pvc".
|
||||
# In this case the updated .pdf will be in the aux/ directory.
|
||||
|
||||
.PHONY: all all-specs release discard
|
||||
all: .Makefile.uptodate
|
||||
$(MAKE) nu5 canopy heartwood blossom sapling
|
||||
|
||||
all-specs: .Makefile.uptodate
|
||||
$(MAKE) nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf
|
||||
|
||||
release:
|
||||
ifeq ($(shell git tag --points-at HEAD |wc -l),0)
|
||||
echo "Set a tag at HEAD first."
|
||||
else
|
||||
$(eval TAG := $(shell git tag --points-at HEAD))
|
||||
if [[ "$(shell git rev-parse --abbrev-ref HEAD)" != "main" ]]; then echo "Not on main."; exit 1; fi
|
||||
$(MAKE) clean all
|
||||
git add *.pdf
|
||||
git commit -m "Regenerate PDFs." *.pdf
|
||||
git tag "v$(TAG)"
|
||||
git push --tags origin HEAD:main
|
||||
endif
|
||||
|
||||
discard:
|
||||
git checkout -- '*.pdf'
|
||||
|
||||
.Makefile.uptodate: Makefile
|
||||
$(MAKE) clean
|
||||
touch .Makefile.uptodate
|
||||
|
||||
sapling.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
|
||||
$(MAKE) sapling
|
||||
|
||||
.PHONY: auxsprout
|
||||
auxsprout:
|
||||
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
mkdir -p aux
|
||||
rm -f aux/sprout.* aux/protocol.*
|
||||
$(LATEXMK) -jobname=sprout -auxdir=aux -outdir=aux protocol
|
||||
blossom.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
|
||||
$(MAKE) blossom
|
||||
|
||||
.PHONY: sprout
|
||||
sprout:
|
||||
$(MAKE) auxsprout
|
||||
mv -f aux/sprout.pdf .
|
||||
heartwood.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
|
||||
$(MAKE) heartwood
|
||||
|
||||
.PHONY: pvcsprout
|
||||
pvcsprout:
|
||||
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
mkdir -p aux
|
||||
rm -f aux/sprout.* aux/protocol.*
|
||||
$(LATEXMK) -jobname=sprout -auxdir=aux -pvc protocol
|
||||
canopy.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
|
||||
$(MAKE) canopy
|
||||
|
||||
nu5.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
|
||||
$(MAKE) nu5
|
||||
|
||||
.PHONY: auxsapling
|
||||
auxsapling:
|
||||
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
mkdir -p aux
|
||||
rm -f aux/sapling.*
|
||||
$(LATEXMK) -jobname=sapling -auxdir=aux -outdir=aux protocol
|
||||
$(LATEXMK) -jobname=sapling -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
|
||||
|
||||
.PHONY: sapling
|
||||
sapling:
|
||||
$(MAKE) auxsapling
|
||||
mv -f aux/sapling.pdf .
|
||||
cp -f sapling.pdf protocol.pdf
|
||||
|
||||
.PHONY: pvcsapling
|
||||
pvcsapling:
|
||||
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
.PHONY: auxblossom
|
||||
auxblossom:
|
||||
printf '\\toggletrue{isblossom}\n\\renewcommand{\\docversion}{Version %s [\\BlossomSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
mkdir -p aux
|
||||
rm -f aux/sapling.*
|
||||
$(LATEXMK) -jobname=sapling -auxdir=aux -pvc protocol
|
||||
rm -f aux/blossom.*
|
||||
$(LATEXMK) -jobname=blossom -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
|
||||
|
||||
.PHONY: nolatexmk-sprout
|
||||
nolatexmk-sprout:
|
||||
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
|
||||
rm -f sprout.aux sprout.bbl sprout.blg sprout.brf sprout.bcf
|
||||
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
biber protocol
|
||||
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
.PHONY: blossom
|
||||
blossom:
|
||||
$(MAKE) auxblossom
|
||||
mv -f aux/blossom.pdf .
|
||||
|
||||
.PHONY: auxheartwood
|
||||
auxheartwood:
|
||||
printf '\\toggletrue{isheartwood}\n\\renewcommand{\\docversion}{Version %s [\\HeartwoodSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
mkdir -p aux
|
||||
rm -f aux/heartwood.*
|
||||
$(LATEXMK) -jobname=heartwood -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
|
||||
|
||||
.PHONY: heartwood
|
||||
heartwood:
|
||||
$(MAKE) auxheartwood
|
||||
mv -f aux/heartwood.pdf .
|
||||
|
||||
.PHONY: auxcanopy
|
||||
auxcanopy:
|
||||
printf '\\toggletrue{iscanopy}\n\\renewcommand{\\docversion}{Version %s [\\CanopySpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
mkdir -p aux
|
||||
rm -f aux/canopy.*
|
||||
$(LATEXMK) -jobname=canopy -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
|
||||
|
||||
.PHONY: canopy
|
||||
canopy:
|
||||
$(MAKE) auxcanopy
|
||||
mv -f aux/canopy.pdf .
|
||||
|
||||
.PHONY: auxnu5
|
||||
auxnu5:
|
||||
printf '\\toggletrue{isnufive}\n\\renewcommand{\\docversion}{Version %s [\\NUFiveSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
mkdir -p aux
|
||||
rm -f aux/nu5.*
|
||||
$(LATEXMK) -jobname=nu5 -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
|
||||
|
||||
.PHONY: nu5
|
||||
nu5:
|
||||
$(MAKE) auxnu5
|
||||
mv -f aux/nu5.pdf .
|
||||
cp -f nu5.pdf protocol.pdf
|
||||
|
||||
.PHONY: nolatexmk-sapling
|
||||
nolatexmk-sapling:
|
||||
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
|
||||
rm -f sapling.aux sapling.bbl sapling.blg sapling.brf sapling.bcf
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
biber sapling
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
sh mymakeindex.sh -o sapling.ind sapling.idx
|
||||
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
|
||||
.PHONY: html
|
||||
html: sprout.pdf sapling.pdf
|
||||
# Can't use --split-pages 1 because XHR doesn't work by default on local files in Chrome.
|
||||
pdf2htmlEX --decompose-ligature 1 --font-size-multiplier 65 --fit-width 1000 --dest-dir html sprout.pdf
|
||||
pdf2htmlEX --decompose-ligature 1 --font-size-multiplier 65 --fit-width 1000 --dest-dir html sapling.pdf
|
||||
.PHONY: nolatexmk-blossom
|
||||
nolatexmk-blossom:
|
||||
printf '\\toggletrue{isblossom}\n\\renewcommand{\\docversion}{Version %s [\\BlossomSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
|
||||
rm -f blossom.aux blossom.bbl blossom.blg blossom.brf blossom.bcf
|
||||
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
biber blossom
|
||||
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
sh mymakeindex.sh -o blossom.ind blossom.idx
|
||||
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
cp -f blossom.pdf protocol.pdf
|
||||
|
||||
.PHONY: nolatexmk-heartwood
|
||||
nolatexmk-heartwood:
|
||||
printf '\\toggletrue{isheartwood}\n\\renewcommand{\\docversion}{Version %s [\\HeartwoodSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
|
||||
rm -f heartwood.aux heartwood.bbl heartwood.blg heartwood.brf heartwood.bcf
|
||||
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
biber heartwood
|
||||
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
sh mymakeindex.sh -o heartwood.ind heartwood.idx
|
||||
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
|
||||
.PHONY: nolatexmk-canopy
|
||||
nolatexmk-canopy:
|
||||
printf '\\toggletrue{iscanopy}\n\\renewcommand{\\docversion}{Version %s [\\CanopySpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
|
||||
rm -f canopy.aux canopy.bbl canopy.blg canopy.brf canopy.bcf
|
||||
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
biber canopy
|
||||
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
sh mymakeindex.sh -o canopy.ind canopy.idx
|
||||
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
|
||||
.PHONY: nolatexmk-nu5
|
||||
nolatexmk-nu5:
|
||||
printf '\\toggletrue{isnufive}\n\\renewcommand{\\docversion}{Version %s [\\NUFiveSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
|
||||
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
|
||||
rm -f nu5.aux nu5.bbl nu5.blg nu5.brf nu5.bcf
|
||||
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
biber nu5
|
||||
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
sh mymakeindex.sh -o nu5.ind nu5.idx
|
||||
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f aux/* html/* protocol.ver \
|
||||
sprout.dvi sprout.pdf sprout.bbl sprout.blg sprout.brf sprout.toc \
|
||||
sprout.aux sprout.out sprout.log sprout.bcf sprout.run.xml sprout.fls sprout.fdb_latexmk \
|
||||
sapling.dvi sapling.pdf sapling.bbl sapling.blg sapling.brf sapling.toc \
|
||||
sapling.aux sapling.out sapling.log sapling.bcf sapling.run.xml sapling.fls sapling.fdb_latexmk
|
||||
|
||||
optimizer-installed.flag:
|
||||
# Nail down git commits to make backdooring somewhat harder.
|
||||
git clone https://github.com/pts/sam2p.git
|
||||
cd sam2p && git reset --hard a2d7819107324faf7b0904fc7074f7dd4a0e16c7 && $(MAKE)
|
||||
git clone https://github.com/pts/tif22pnm.git
|
||||
cd tif22pnm && git reset --hard 22217c1a3ea355a899e9c7c79903488ca13d1dfe && $(MAKE)
|
||||
git clone https://github.com/pts/pdfsizeopt.git
|
||||
cd pdfsizeopt && git reset --hard 47a03403d70f6975888cee966858bebc51b76463
|
||||
touch optimizer-installed.flag
|
||||
|
||||
.PHONY: clean-optimizer
|
||||
clean-optimizer:
|
||||
rm -rf sam2p tif22pnm pdfsizeopt optimizer-installed.flag
|
||||
|
||||
.PHONY: optsprout
|
||||
optsprout: optimizer-installed.flag
|
||||
$(MAKE) auxsprout
|
||||
PATH="${PATH}:$(CURDIR)/sam2p:$(CURDIR)/tif22pnm" pdfsizeopt/pdfsizeopt --v=40 --use-image-optimizer=sam2p \
|
||||
--tmp-dir=aux aux/sprout.pdf sprout.pdf
|
||||
|
||||
.PHONY: optsapling
|
||||
optsapling: optimizer-installed.flag
|
||||
$(MAKE) auxsapling
|
||||
PATH="${PATH}:$(CURDIR)/sam2p:$(CURDIR)/tif22pnm" pdfsizeopt/pdfsizeopt --v=40 --use-image-optimizer=sam2p \
|
||||
--tmp-dir=aux aux/sapling.pdf sapling.pdf
|
||||
cp -f sapling.pdf protocol.pdf
|
||||
|
||||
.PHONY: optimized
|
||||
optimized: optsprout optsapling
|
||||
rm -f aux/* html/* protocol.ver protocol.pdf nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf
|
||||
|
|
|
@ -7,7 +7,7 @@ Build dependencies on Debian-based systems include, at least:
|
|||
.. code::
|
||||
|
||||
apt-get install texlive texlive-science texlive-fonts-extra \
|
||||
texlive-generic-recommended texlive-bibtex-extra biber latexmk
|
||||
texlive-generic-recommended texlive-bibtex-extra biber latexmk perl awk
|
||||
|
||||
|
||||
Building
|
||||
|
@ -15,54 +15,32 @@ Building
|
|||
|
||||
Use:
|
||||
|
||||
* ``make pdf`` to make the current protocol specification (``protocol.pdf``);
|
||||
* ``make sapling`` to make the draft specification for the Overwinter and
|
||||
Sapling upgrades (``sapling.pdf``).
|
||||
* ``make nufour`` to make the draft specification for NU4 (``nufour.pdf``);
|
||||
* ``make heartwood`` to make the specification for Heartwood (``protocol.pdf``);
|
||||
* ``make blossom`` to make the specification for the Blossom upgrade
|
||||
(``blossom.pdf``);
|
||||
* ``make sapling`` to make the specification for the Overwinter and
|
||||
Sapling upgrades (``sapling.pdf``);
|
||||
* ``make sprout`` to make a version of the specification that does not
|
||||
include Overwinter or Sapling (``sprout.pdf``).
|
||||
|
||||
By default these use ``latexmk``, which does not work on all systems.
|
||||
Use ``make nolatexmk-pdf`` or ``make nolatexmk-sapling`` if you run into
|
||||
problems with ``latexmk``, but that is not the preferred way of building
|
||||
because it may not run ``pdflatex`` enough times.
|
||||
``make all`` is equivalent to ``make nufour heartwood blossom sapling sprout``.
|
||||
|
||||
There is also support for using the incremental (``-pvc``) mode of
|
||||
``latexmk`` to automatically rebuild when changes in the source files
|
||||
are detected: ``make pvcpdf`` or ``make pvcsapling``.
|
||||
Manual intervention is still needed when there are LaTeX errors.
|
||||
By default these use ``latexmk``. If you have trouble getting ``latexmk`` to
|
||||
work, you can instead use ``make nolatexmk-sapling``, etc. That is not the
|
||||
preferred way of building because it may not run ``pdflatex`` enough times.
|
||||
|
||||
It is also possible to use the incremental (``-pvc``) mode of ``latexmk`` to
|
||||
automatically rebuild when changes in the source files are detected, by adding
|
||||
``EXTRAOPT=-pvc`` to the ``make`` command line. In this case the updated PDF
|
||||
files will be in the ``aux/`` directory. Manual intervention is still needed
|
||||
when there are LaTeX errors.
|
||||
|
||||
|
||||
Optimizing PDF size
|
||||
-------------------
|
||||
Alternative TeX engines
|
||||
-----------------------
|
||||
|
||||
Optionally, you can use `Péter Szabó <https://github.com/pts>`_'s
|
||||
``pdfsizeopt`` program to optimize the size of the resulting PDF files.
|
||||
|
||||
Use:
|
||||
|
||||
* ``make optpdf`` to make an optimized version of ``protocol.pdf``;
|
||||
* ``make optsapling`` to make an optimized version of ``sapling.pdf``;
|
||||
* ``make optimized`` to make both.
|
||||
|
||||
This will probably only work on Linux. The first time one of these
|
||||
targets is run, it will automatically clone and build the necessary
|
||||
dependencies (pinned by ``git`` hash) from GitHub.
|
||||
|
||||
This gives a size saving of about 50% for ``protocol.pdf``, and
|
||||
40% for ``sapling.pdf``.
|
||||
|
||||
|
||||
Converting to HTML
|
||||
------------------
|
||||
|
||||
To convert to HTML you will first need to install ``pdf2htmlEX``. On Debian:
|
||||
|
||||
.. code::
|
||||
|
||||
apt-get install pdf2htmlex
|
||||
|
||||
Then use ``make html`` (or ``make optimized html``) to convert both PDFs.
|
||||
|
||||
The results are placed in the ``html`` directory at ``html/protocol.html``
|
||||
and ``html/sapling.html``.
|
||||
|
||||
See `<https://github.com/zcash/zips/issues/127>`_ for limitations of
|
||||
this conversion.
|
||||
There is experimental support for building the specification using LuaTeX
|
||||
or XeTeX; see the comments at the top of the `Makefile`. However, this will
|
||||
`currently produce poor output <https://github.com/zcash/zips/issues/249>`_.
|
||||
A warning is included below the Abstract to indicate this.
|
||||
|
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 439 KiB After Width: | Height: | Size: 584 KiB |
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 73 KiB |
|
@ -13,7 +13,7 @@
|
|||
height="370"
|
||||
id="svg2"
|
||||
version="1.1"
|
||||
inkscape:version="0.92.0 r15299"
|
||||
inkscape:version="0.92.4 (5da689c313, 2019-01-14)"
|
||||
sodipodi:docname="key_components.svg"
|
||||
inkscape:export-filename="/home/davidsarah/zecc/zips/protocol/key_components.png"
|
||||
inkscape:export-xdpi="179.99957"
|
||||
|
@ -26,7 +26,7 @@
|
|||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="1.979899"
|
||||
inkscape:cx="256.59392"
|
||||
inkscape:cx="142.95176"
|
||||
inkscape:cy="195.56571"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
|
@ -190,7 +190,7 @@
|
|||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
|
@ -343,15 +343,15 @@
|
|||
</g>
|
||||
<text
|
||||
id="text3850-7"
|
||||
y="784.07965"
|
||||
x="176.54729"
|
||||
y="784.58472"
|
||||
x="123.51428"
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';stroke-width:1.06666672"
|
||||
y="784.07965"
|
||||
x="176.54729"
|
||||
y="784.58472"
|
||||
x="123.51428"
|
||||
id="tspan3852-97"
|
||||
sodipodi:role="line">Payment address</tspan></text>
|
||||
sodipodi:role="line">Shielded payment address</tspan></text>
|
||||
<rect
|
||||
ry="26.666662"
|
||||
y="936.75397"
|
||||
|
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
After Width: | Height: | Size: 346 KiB |
After Width: | Height: | Size: 97 KiB |
Before Width: | Height: | Size: 181 KiB After Width: | Height: | Size: 223 KiB |
|
@ -13,7 +13,7 @@
|
|||
height="720"
|
||||
id="svg2"
|
||||
version="1.1"
|
||||
inkscape:version="0.92.0 r15299"
|
||||
inkscape:version="0.92.4 (5da689c313, 2019-01-14)"
|
||||
sodipodi:docname="key_components_sapling.svg"
|
||||
inkscape:export-filename="c:\zcash\key_components_sapling.png"
|
||||
inkscape:export-xdpi="179.99957"
|
||||
|
@ -25,16 +25,16 @@
|
|||
borderopacity="1.0"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="0.98994951"
|
||||
inkscape:cx="927.70996"
|
||||
inkscape:cy="254.72974"
|
||||
inkscape:zoom="1.4"
|
||||
inkscape:cx="681.16675"
|
||||
inkscape:cy="396.44845"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
showgrid="false"
|
||||
inkscape:window-width="1525"
|
||||
inkscape:window-height="943"
|
||||
inkscape:window-x="69"
|
||||
inkscape:window-y="182"
|
||||
inkscape:window-width="3150"
|
||||
inkscape:window-height="1491"
|
||||
inkscape:window-x="682"
|
||||
inkscape:window-y="232"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:lockguides="false"
|
||||
inkscape:snap-global="false" />
|
||||
|
@ -531,14 +531,14 @@
|
|||
id="text3850-8"
|
||||
y="668.83093"
|
||||
x="23.203564"
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#f10090;fill-opacity:1;stroke:none;stroke-width:1.06666672"
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672;"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#f10090;fill-opacity:1;stroke-width:1.06666672"
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#000000;fill-opacity:1;stroke-width:1.06666672;"
|
||||
y="668.83093"
|
||||
x="23.203564"
|
||||
id="tspan3852-3"
|
||||
sodipodi:role="line"> Incoming</tspan><tspan
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#f10090;fill-opacity:1;stroke-width:1.06666672"
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#000000;fill-opacity:1;stroke-width:1.06666672;"
|
||||
y="694.23407"
|
||||
x="23.203564"
|
||||
sodipodi:role="line"
|
||||
|
@ -617,15 +617,15 @@
|
|||
</g>
|
||||
<text
|
||||
id="text3850-7"
|
||||
y="512.10144"
|
||||
x="181.49651"
|
||||
y="512.354"
|
||||
x="134.01933"
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';stroke-width:1.06666672"
|
||||
y="512.10144"
|
||||
x="181.49651"
|
||||
y="512.354"
|
||||
x="134.01933"
|
||||
id="tspan3852-97"
|
||||
sodipodi:role="line">Payment address</tspan></text>
|
||||
sodipodi:role="line">Shielded payment address</tspan></text>
|
||||
<rect
|
||||
ry="26.666662"
|
||||
y="647.65533"
|
||||
|
@ -690,27 +690,27 @@
|
|||
sodipodi:role="line"
|
||||
style="stroke-width:1.06666672">sk</tspan></text>
|
||||
<path
|
||||
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#f10090;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lendh)"
|
||||
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker6075)"
|
||||
d="m 289.70585,937.86564 c 13.34726,-19.916 17.58393,-28.45003 24.03935,-46.47757 3.31248,-9.25049 6.23409,-19.55143 7.6985,-38.78777 1.38353,-18.174 0.29483,-34.40533 0.55584,-57.15903 l 0.55822,-102.74298"
|
||||
id="path4668"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="csscc" />
|
||||
<g
|
||||
id="g4689"
|
||||
style="fill:none;fill-opacity:1;stroke:#f10090;stroke-opacity:1"
|
||||
style="fill:none;fill-opacity:1;stroke:#050003;stroke-opacity:1"
|
||||
transform="translate(21.565438,-290.93448)">
|
||||
<path
|
||||
sodipodi:nodetypes="czzzc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="path4670"
|
||||
d="m 156.2806,930.52347 c -3.22019,0.27418 -4.8062,0.90755 -6.85506,3.96663 -2.04886,3.05908 -2.06364,10.34355 -2.01133,15.3383 0.0523,4.99475 -0.10857,8.93699 -2.51642,11.96863 -2.40782,3.03165 -4.09355,3.97036 -8.40092,3.77013"
|
||||
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#f10090;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
|
||||
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#050003;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
|
||||
<path
|
||||
sodipodi:nodetypes="czzzc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="path4670-6"
|
||||
d="m 156.2806,1000.6108 c -3.22019,-0.2741 -4.8062,-0.9075 -6.85506,-3.96658 -2.04886,-3.05908 -2.06364,-10.34355 -2.01133,-15.3383 0.0523,-4.99475 -0.10857,-8.93699 -2.51642,-11.96863 -2.40782,-3.03165 -4.09355,-3.97036 -8.40092,-3.77013"
|
||||
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#f10090;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
|
||||
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#050003;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
|
||||
</g>
|
||||
<path
|
||||
sodipodi:nodetypes="cc"
|
||||
|
@ -831,15 +831,15 @@
|
|||
</g>
|
||||
<text
|
||||
id="text3850-7-7"
|
||||
y="511.16852"
|
||||
x="800.72668"
|
||||
y="513.18884"
|
||||
x="752.23938"
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';stroke-width:1.06666672"
|
||||
y="511.16852"
|
||||
x="800.72668"
|
||||
id="tspan3852-97-4"
|
||||
sodipodi:role="line">Payment address</tspan></text>
|
||||
y="513.18884"
|
||||
x="752.23938"
|
||||
sodipodi:role="line"
|
||||
id="tspan4954">Shielded payment address</tspan></text>
|
||||
<rect
|
||||
ry="26.666662"
|
||||
y="644.01617"
|
||||
|
|
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 57 KiB |
|
@ -0,0 +1 @@
|
|||
$makeindex = 'sh mymakeindex.sh -o %D %O %S';
|
|
@ -0,0 +1,29 @@
|
|||
#!/bin/sh
|
||||
set -e
|
||||
makeindex $*
|
||||
|
||||
# We want to change things like:
|
||||
# \hyperindexformat{\definingstyle}{17},
|
||||
# \hyperindexformat{\normalstyle}{17},
|
||||
# to just
|
||||
# \hyperindexformat{\definingstyle}{17},
|
||||
#
|
||||
# and change:
|
||||
# \hyperindexformat{\definingstyle}{17},
|
||||
# \hyperindexformat{\normalstyle}{17, 18},
|
||||
# to
|
||||
# \hyperindexformat{\definingstyle}{17},
|
||||
# \hyperindexformat{\normalstyle}{18},
|
||||
#
|
||||
# and change:
|
||||
# \hyperindexformat{\definingstyle}{17},
|
||||
# \hyperindexformat{\normalstyle}{17--19},
|
||||
# to
|
||||
# \hyperindexformat{\definingstyle}{17},
|
||||
# \hyperindexformat{\normalstyle}{\increment{17}--19},
|
||||
|
||||
echo Postprocessing index file "$2"...
|
||||
perl -i.original -p0e 's/(?s)(\\hyperindexformat[{]\\definingstyle[}][{])(\d+)[}],\s*.\s*\\hyperindexformat[{]\\normalstyle[}][{]\2[}]/\1\2}/sg' "$2"
|
||||
perl -i -p0e 's/(?s)(\\hyperindexformat[{]\\definingstyle[}][{])(\d+)([}],\s*.\s*\\hyperindexformat[{]\\normalstyle[}][{])\2,\s*([\d,-\s]+[}])/\1\2\3\4/sg' "$2"
|
||||
perl -i -p0e 's/(?s)(\\hyperindexformat[{]\\definingstyle[}][{])(\d+)([}],\s*.\s*\\hyperindexformat[{]\\normalstyle[}][{])\2--([\d,-\s]+[}])/\1\2\3\\increment{\2}--\4/sg' "$2"
|
||||
#diff --context=3 "$2.original" "$2"
|
15203
protocol/protocol.tex
|
@ -1,2 +0,0 @@
|
|||
\toggletrue{issapling}
|
||||
\renewcommand{\docversion}{Version 2018.0-beta-27 [\SaplingSpec]}
|
1121
protocol/zcash.bib
|
@ -0,0 +1,7 @@
|
|||
#!/bin/bash
|
||||
set -efuxo pipefail
|
||||
|
||||
TAG='zcash-zips-render'
|
||||
|
||||
docker build -t "$TAG" .
|
||||
docker run -v "$(pwd):/zips" "$TAG"
|
|
@ -0,0 +1,317 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 0: ZIP Process</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 0
|
||||
Title: ZIP Process
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Deirdre Connolly <deirdre@zfnd.org>
|
||||
Original-Authors: Daira Hopwood
|
||||
Josh Cincinnati
|
||||
George Tankersley
|
||||
Credits: Luke Dashjr
|
||||
Status: Active
|
||||
Category: Process
|
||||
Created: 2019-02-16
|
||||
License: BSD-2-Clause</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</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>A Zcash Improvement Proposal (ZIP) is a design document providing information to the Zcash community, or describing a new feature for Zcash or its processes or environment. The ZIP should provide a concise technical specification of the feature and a rationale for the feature.</p>
|
||||
<p>We intend ZIPs to be the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Zcash. The Owner(s) of the ZIP (usually the authors(s)) are responsible for building consensus within the community and documenting dissenting opinions.</p>
|
||||
<p>Because the ZIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p>
|
||||
<p>This document is based partly on the work done by Luke Dashjr with <a href="https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki">BIP 2</a>.</p>
|
||||
</section>
|
||||
<section id="zip-workflow"><h2><span class="section-heading">ZIP Workflow</span><span class="section-anchor"> <a rel="bookmark" href="#zip-workflow"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The ZIP process begins with a new idea for Zcash. Each potential ZIP must have Owners — one or more people who write the ZIP using the style and format described below, shepherd the discussions in the appropriate forums, and attempt to build community consensus around the idea. The ZIP Owners should first attempt to ascertain whether the idea is ZIP-able. Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a ZIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker. Additionally, many ideas have been brought forward for changing Zcash that have been rejected for various reasons. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. After investigating past work, the best way to proceed is by posting about the new idea to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>.</p>
|
||||
<p>Vetting an idea publicly before going as far as writing a ZIP is meant to save both the potential Owners and the wider community time. Asking the Zcash community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the Owners. Just because an idea sounds good to the Owners does not mean it will work for most people in most areas where Zcash is used.</p>
|
||||
<p>Once the Owners have asked the Zcash community as to whether an idea has any chance of acceptance, a draft ZIP should be presented to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>. This gives the Owners a chance to flesh out the draft ZIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the <a href="https://github.com/zcash/zips">ZIPs git repository</a> as a pull request. This draft must be written in ZIP style as described below, and named with an alias such as <code>zip-zatoshizakamoto-42millionzec</code> until the ZIP Editors have assigned it a ZIP number (Owners MUST NOT self-assign ZIP numbers).</p>
|
||||
<p>ZIP Owners are responsible for collecting community feedback on both the initial idea and the ZIP before submitting it for review. However, wherever possible, long open-ended discussions on forums should be avoided.</p>
|
||||
<p>It is highly recommended that a single ZIP contain a single key proposal or new idea. The more focused the ZIP, the more successful it tends to be. If in doubt, split your ZIP into several well-focused ones.</p>
|
||||
<p>When the ZIP draft is complete, the ZIP Editors will assign the ZIP a number (if that has not already been done) and one or more Categories, and merge the pull request to the ZIPs git repository. The ZIP Editors will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or not in keeping with the Zcash philosophy. For a ZIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.</p>
|
||||
<p>The ZIP Owners may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the Owners as pull requests.</p>
|
||||
<section id="zip-numbering-conventions"><h3><span class="section-heading">ZIP Numbering Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#zip-numbering-conventions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The ZIP Editors currently use the following conventions when numbering ZIPs:</p>
|
||||
<ul>
|
||||
<li>if a ZIP directly corresponds to a BIP (Bitcoin Improvement Proposal), and the number doesn't clash, assign the same number;</li>
|
||||
<li>if it affects the consensus layer or the core protocol, assign a number in the range 200..299;</li>
|
||||
<li>if it affects only higher layers but is needed for interoperability between node implementations or other parts of the ecosystem, assign a number in the range 300..399;</li>
|
||||
<li>if it is specific to an implementation (e.g. zcashd or zebra), assign a number in the range 400..499;</li>
|
||||
<li>try to number ZIPs that should or will be deployed together consecutively (subject to the above conventions), and in a coherent reading order.</li>
|
||||
</ul>
|
||||
<p>These conventions are subject to change by consensus of the ZIP Editors.</p>
|
||||
</section>
|
||||
<section id="transferring-zip-ownership"><h3><span class="section-heading">Transferring ZIP Ownership</span><span class="section-anchor"> <a rel="bookmark" href="#transferring-zip-ownership"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>It occasionally becomes necessary to transfer ownership of ZIPs to a new Owner. In general, we'd like to retain the original Owner as a co-Owner of the transferred ZIP, but that's really up to the original Owner. A good reason to transfer ownership is because the original Owner no longer has the time or interest in updating it or following through with the ZIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ZIP. We try to build consensus around a ZIP, but if that's not possible, you can always submit a competing ZIP.</p>
|
||||
<p>If you are interested in assuming ownership of a ZIP, send a message asking to take over, addressed to both the original Owner and the ZIP Editors. If the original Owner doesn't respond to email in a timely manner, the ZIP Editors will make a unilateral decision (it's not like such decisions can't be reversed :).</p>
|
||||
<p>If an author of a ZIP is no longer an Owner, an Original-Authors field SHOULD be added to the ZIP metadata indicating the original authorship, unless the original author(s) request otherwise.</p>
|
||||
</section>
|
||||
<section id="zip-editors"><h3><span class="section-heading">ZIP Editors</span><span class="section-anchor"> <a rel="bookmark" href="#zip-editors"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The current ZIP Editors are Daira Hopwood, representing the Electric Coin Company, and Deirdre Connolly, representing the Zcash Foundation. Both can be reached at <a href="mailto:zips@z.cash">zips@z.cash</a> . The current design of the ZIP Process dictates that there are always at least two ZIP Editors: one from the Electric Coin Company and one from the Zcash Foundation. Additional Editors may be selected by consensus among the current Editors.</p>
|
||||
</section>
|
||||
<section id="zip-editor-responsibilities-workflow"><h3><span class="section-heading">ZIP Editor Responsibilities & Workflow</span><span class="section-anchor"> <a rel="bookmark" href="#zip-editor-responsibilities-workflow"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The ZIP Editors subscribe to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum.</a></p>
|
||||
<p>For each new ZIP that comes in an Editor confirms the following:</p>
|
||||
<ul>
|
||||
<li>Read the ZIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.</li>
|
||||
<li>The title should accurately describe the content.</li>
|
||||
<li>The ZIP draft must have been sent to the Zcash Community Forum or as a PR to the <a href="https://github.com/zcash/zips">ZIPs git repository</a></li>
|
||||
<li>Motivation and backward compatibility (when applicable) must be addressed.</li>
|
||||
<li>The licensing terms are acceptable for ZIPs.</li>
|
||||
</ul>
|
||||
<p>If the ZIP isn't ready, the editor will send it back to the Owners for revision, with specific instructions.</p>
|
||||
<p>Once the ZIP is ready for the repository it SHOULD be submitted as a "pull request" to the <a href="https://github.com/zcash/zips">ZIPs git repository</a> where it may get further feedback. It SHOULD NOT contain a ZIP number unless one had already been assigned by the ZIP Editors. The pull request SHOULD initially be marked as a Draft.</p>
|
||||
<p>The ZIP Editors will:</p>
|
||||
<ul>
|
||||
<li>Assign a ZIP number in the pull request.</li>
|
||||
<li>Remove Draft status and merge the pull request when it is ready.</li>
|
||||
</ul>
|
||||
<p>The ZIP editors monitor ZIP changes and update ZIP headers as appropriate.</p>
|
||||
<p>The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons:</p>
|
||||
<ul>
|
||||
<li>it violates the Zcash Code of Conduct <a id="id3" class="footnote_reference" href="#conduct">4</a> ;</li>
|
||||
<li>it appears too unfocused or broad;</li>
|
||||
<li>it duplicates effort in other ZIPs without sufficient technical justification (however, alternative proposals to address similar or overlapping problems are not excluded for this reason);</li>
|
||||
<li>it has manifest security flaws (including being unrealistically dependent on user vigilance to avoid security weaknesses);</li>
|
||||
<li>it disregards compatibility with the existing Zcash blockchain or ecosystem;</li>
|
||||
<li>it is manifestly unimplementable;</li>
|
||||
<li>it includes buggy code, pseudocode, or algorithms;</li>
|
||||
<li>it manifestly violates common expectations of a significant portion of the Zcash community;</li>
|
||||
<li>it updates a Draft ZIP to Released when there is significant community opposition to its content (however, Draft ZIPs explicitly may describe proposals to which there is, or could be expected, significant community opposition);</li>
|
||||
<li>in the case of a Released ZIP, the update makes a substantive change to which there is significant community opposition;</li>
|
||||
<li>it is dependent on a patent that could potentially be an obstacle to adoption of the ZIP;</li>
|
||||
<li>it includes commercial advertising or spam;</li>
|
||||
<li>it disregards formatting rules;</li>
|
||||
<li>it makes non-editorial edits to previous entries in a ZIP's Change history, if there is one;</li>
|
||||
<li>an update to an existing ZIP extends or changes its scope to an extent that would be better handled as a separate ZIP;</li>
|
||||
<li>a new ZIP has been proposed for a category that does not reflect its content, or an update would change a ZIP to an inappropriate category;</li>
|
||||
<li>it updates a Released ZIP to Draft when the specification is already implemented and has been in common use;</li>
|
||||
<li>it violates any specific "MUST" or "MUST NOT" rule in this document;</li>
|
||||
<li>the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct <a id="id4" class="footnote_reference" href="#conduct">4</a> (except in the case of an update removing that Owner);</li>
|
||||
<li>it is not authorized by the stated ZIP Owners;</li>
|
||||
<li>it removes an Owner without their consent (unless the reason for removal is directly related to a breach of the Code of Conduct by that Owner).</li>
|
||||
</ul>
|
||||
<p>The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update that does not violate any of these criteria. If they refuse a proposal or update, they MUST give an explanation of which of the criteria were violated, with the exception that spam may be deleted without an explanation.</p>
|
||||
<p>Note that it is not the primary responsibility of the ZIP Editors to review proposals for security, correctness, or implementability.</p>
|
||||
<p>Please send all ZIP-related communications either by email to <<a href="mailto:zips@z.cash">zips@z.cash</a>>, or by opening an issue on the <a href="https://github.com/zcash/zips/issues">ZIPs issue tracker</a>. All communications should abide by the Zcash Code of Conduct <a id="id5" class="footnote_reference" href="#conduct">4</a> and follow <a href="https://www.gnu.org/philosophy/kind-communication.en.html">the GNU Kind Communication Guidelines</a></p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="zip-format-and-structure"><h2><span class="section-heading">ZIP format and structure</span><span class="section-anchor"> <a rel="bookmark" href="#zip-format-and-structure"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>ZIPs SHOULD be written in reStructuredText <a id="id6" class="footnote_reference" href="#rst">5</a>, Markdown <a id="id7" class="footnote_reference" href="#markdown">6</a>, or LaTeX <a id="id8" class="footnote_reference" href="#latex">7</a>. For ZIPs written in LaTeX, a <code>Makefile</code> MUST be provided to build (at least) a PDF version of the document.</p>
|
||||
<p>Each ZIP SHOULD have the following parts:</p>
|
||||
<ul>
|
||||
<li>Preamble — Headers containing metadata about the ZIP (<a href="#zip-header-preamble">see below</a>). The License field of the preamble indicates the licensing terms, which MUST be acceptable according to <a href="#zip-licensing">the ZIP licensing requirements</a>.</li>
|
||||
<li>Terminology — Definitions of technical or non-obvious terms used in the document.</li>
|
||||
<li>Abstract — A short (~200 word) description of the technical issue being addressed.</li>
|
||||
<li>Motivation — The motivation is critical for ZIPs that want to change the Zcash protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the ZIP solves.</li>
|
||||
<li>Specification — The technical specification should describe the interface and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Zcash platforms.</li>
|
||||
<li>Rationale — The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.</li>
|
||||
<li>Security and privacy considerations — If applicable, security and privacy considerations should be explicitly described, particularly if the ZIP makes explicit trade-offs or assumptions. For guidance on this section consider RFC 3552 <a id="id9" class="footnote_reference" href="#rfc3552">2</a> as a starting point.</li>
|
||||
<li>Reference implementation — Literal code implementing the ZIP's specification, and/or a link to the reference implementation of the ZIP's specification. The reference implementation MUST be completed before any ZIP is given status “Implemented” or “Final”, but it generally need not be completed before the ZIP is accepted into “Proposed”.</li>
|
||||
</ul>
|
||||
<section id="zip-header-preamble"><h3><span class="section-heading">ZIP header preamble</span><span class="section-anchor"> <a rel="bookmark" href="#zip-header-preamble"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Each ZIP MUST begin with a RFC 822-style header preamble. For ZIPs written in reStructuredText, this is represented as <code>::</code> on the first line, followed by a blank line, then the preamble indented by 2 spaces.</p>
|
||||
<p>The following header fields are REQUIRED:</p>
|
||||
<pre>ZIP:
|
||||
Title:
|
||||
Owners:
|
||||
Status:
|
||||
Category:
|
||||
Created:
|
||||
License:</pre>
|
||||
<p>The following additional header fields are OPTIONAL:</p>
|
||||
<pre>Credits:
|
||||
Original-Authors:
|
||||
Discussions-To:
|
||||
Pull-Request:
|
||||
Obsoleted by:
|
||||
Updated by:
|
||||
Obsoletes:
|
||||
Updates:</pre>
|
||||
<p>The Owners header lists the names and email addresses of all the Owners of the ZIP. The format of the Owners header value SHOULD be:</p>
|
||||
<pre>Random J. User <address@dom.ain></pre>
|
||||
<p>If there are multiple Owners, each should be on a separate line.</p>
|
||||
<p>The "Owners", "Credits", and "Original-Authors" headers always use these plural spellings even there is only one Owner, one person to be credited, or one original author.</p>
|
||||
<p>While a ZIP is in public discussions (usually during the initial Draft phase), a Discussions-To header will indicate the URL where the ZIP is being discussed. No Discussions-To header is necessary if the ZIP is being discussed privately with the Owner.</p>
|
||||
<p>The Pull-Request header, if present, gives an URL to a Pull Request for the ZIP.</p>
|
||||
<p>The Category header specifies the type of ZIP, as described in <a href="#zip-categories">ZIP categories</a>. Multiple categories MAY be specified, separated by " <code>/</code> ".</p>
|
||||
<p>The Created header records the date that the ZIP was submitted. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.</p>
|
||||
<p>For ZIPs written in reStructuredText, URLs in header fields SHOULD be surrounded by <code><</code> <code>></code>; this ensures that the link is rendered correctly.</p>
|
||||
</section>
|
||||
<section id="auxiliary-files"><h3><span class="section-heading">Auxiliary Files</span><span class="section-anchor"> <a rel="bookmark" href="#auxiliary-files"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>ZIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that ZIP; that is, for any ZIP that requires more than one file, all of the files SHOULD be in a subdirectory named zip-XXXX.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="zip-categories"><h2><span class="section-heading">ZIP categories</span><span class="section-anchor"> <a rel="bookmark" href="#zip-categories"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Each ZIP is in one or more of the following categories, as specified in the Category header:</p>
|
||||
<dl>
|
||||
<dt>Consensus</dt>
|
||||
<dd>Rules that affect the consensus protocol followed by all Zcash implementations.</dd>
|
||||
<dt>Standards</dt>
|
||||
<dd>Non-consensus changes affecting most or all Zcash implementations, or the interoperability of applications using Zcash.</dd>
|
||||
<dt>Process</dt>
|
||||
<dd>A Process ZIP describes a process surrounding Zcash, or proposes a change to (or an event in) a process. They may propose an implementation, but not to Zcash's codebase; they often require community consensus; unlike Informational ZIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Zcash development.</dd>
|
||||
<dt>Consensus Process</dt>
|
||||
<dd>A subcategory of Process ZIP that specifies requirements and processes that are to be realized by one or more Consensus ZIPs, and/or by social consensus of the Zcash community.</dd>
|
||||
<dt>Informational</dt>
|
||||
<dd>An Informational ZIP describes non-consensus Zcash design issues, or general guidelines or information for the Zcash community. These ZIPs do not not necessarily represent a Zcash community consensus or recommendation, so users and implementors are free to ignore Informational ZIPs or follow their advice.</dd>
|
||||
<dt>Network</dt>
|
||||
<dd>Specifications of peer-to-peer networking behaviour.</dd>
|
||||
<dt>RPC</dt>
|
||||
<dd>Specifications of the RPC interface provided by zcashd nodes.</dd>
|
||||
<dt>Wallet</dt>
|
||||
<dd>Specifications affecting wallets (e.g. non-consensus changes to how transactions, addresses, etc. are constructed or interpreted).</dd>
|
||||
<dt>Ecosystem</dt>
|
||||
<dd>Specifications otherwise useful to the Zcash ecosystem.</dd>
|
||||
</dl>
|
||||
<p>New categories may be added by consensus among the ZIP Editors.</p>
|
||||
<p>Consensus and Standards ZIPs SHOULD have a Reference Implementation section, which includes or (more often) links to an implementation.</p>
|
||||
<p>Consensus ZIPs SHOULD have a Deployment section, describing how and when the consensus change is planned to be deployed (for example, in a particular network upgrade).</p>
|
||||
</section>
|
||||
<section id="zip-status-field"><h2><span class="section-heading">ZIP Status Field</span><span class="section-anchor"> <a rel="bookmark" href="#zip-status-field"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Reserved: The ZIP Editors have reserved this ZIP number, and there MAY be a Pull Request for it, but no ZIP has been published. The ZIP Editors SHOULD publish a stub header so that the reservation appears in the <a href="https://zips.z.cash#index-of-zips">ZIP index</a>.</li>
|
||||
<li>Draft: All initial ZIP submissions have this status.</li>
|
||||
<li>Withdrawn: If the Owner decides to remove the ZIP from consideration by the community, they may set the status to Withdrawn.</li>
|
||||
<li>Active: Typically only used for Process/Informational ZIPs, achieved once rough consensus is reached in PR/forum posts from Draft Process ZIP.</li>
|
||||
<li>Proposed: Typically the stage after Draft, added to a ZIP after consideration, feedback, and rough consensus from the community. The ZIP Editors must validate this change before it is approved.</li>
|
||||
<li>Rejected: The status when progress hasn't been made on the ZIP in one year. Can revert back to Draft/Proposed if the Owner resumes work or resolves issues preventing consensus.</li>
|
||||
<li>Implemented: When a Consensus or Standards ZIP has a working reference implementation but before activation on the Zcash network.</li>
|
||||
<li>Final: When a Consensus or Standards ZIP is both implemented and activated on the Zcash network.</li>
|
||||
<li>Obsolete: The status when a ZIP is no longer relevant (typically when superseded by another ZIP).</li>
|
||||
</ul>
|
||||
<p>More details on the status workflow are given in the section below.</p>
|
||||
<section id="specification"><h3><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Owners of a ZIP may decide on their own to change the status between Draft or Withdrawn.</p>
|
||||
<p>A ZIP may only change status from Draft (or Rejected) to Proposed, when the Owner deems it is complete and there is rough consensus on the forums, validated by both the Electric Coin Company and Zcash Foundation Editors. One Editor will not suffice — there needs to be consensus among the Editors. If it's a Consensus ZIP, a Deployment section MUST be present in order for the ZIP to change status to Proposed. Typically, although not necessarily, this will specify a network upgrade in which the consensus change is to activate.</p>
|
||||
<p>A Standards ZIP may only change status from Proposed to Implemented once the Owners provide an associated reference implementation, typically in the period after the network upgrade's specification freeze but before the implementation audit. If the Owners miss this deadline, the Editors or Owners MAY choose to update the Deployment section of the ZIP to target another upgrade, at their discretion.</p>
|
||||
<p>ZIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in one year. Such a ZIP may be changed to Draft status if the Owner provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraphs.</p>
|
||||
<p>A Consensus or Standards ZIP becomes Final when its associated network upgrade or other protocol change is activated on Zcash's mainnet.</p>
|
||||
<p>A Process or Informational ZIP may change status from Draft to Active when it achieves rough consensus on the forum or PR. Such a proposal is said to have rough consensus if it has been open to discussion on the forum or GitHub PR for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.</p>
|
||||
<p>When an Active or Final ZIP is no longer relevant, its status may be changed to Obsolete. This change must also be objectively verifiable and/or discussed. Final ZIPs may be updated; the specification is still in force but modified by another specified ZIP or ZIPs (check the optional Updated-by header).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="zip-comments"><h2><span class="section-heading">ZIP Comments</span><span class="section-anchor"> <a rel="bookmark" href="#zip-comments"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Comments from the community on the ZIP should occur on the Zcash Community Forum and the comment fields of the pull requests in any open ZIPs. Editors will use these sources to judge rough consensus.</p>
|
||||
</section>
|
||||
<section id="zip-licensing"><h2><span class="section-heading">ZIP Licensing</span><span class="section-anchor"> <a rel="bookmark" href="#zip-licensing"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>New ZIPs may be accepted with the following licenses. Each new ZIP MUST identify at least one acceptable license in its preamble. Each license MUST be referenced by their respective abbreviation given below.</p>
|
||||
<p>For example, a preamble might include the following License header:</p>
|
||||
<pre>License: BSD-2-Clause
|
||||
GNU-All-Permissive</pre>
|
||||
<p>In this case, the ZIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of <em>either</em> license. In other words, the license list is an "OR choice", not an "AND also" requirement.</p>
|
||||
<p>It is also possible to license source code differently from the ZIP text. This case SHOULD be indicated in the Reference Implementation section of the ZIP. Again, each license MUST be referenced by its respective abbreviation given below.</p>
|
||||
<p>Statements of code licenses in ZIPs are only advisory; anyone intending to use the code should look for license statements in the code itself.</p>
|
||||
<p>ZIPs are not required to be <em>exclusively</em> licensed under approved terms, and MAY also be licensed under unacceptable licenses <em>in addition to</em> at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License header.</p>
|
||||
<section id="recommended-licenses"><h3><span class="section-heading">Recommended licenses</span><span class="section-anchor"> <a rel="bookmark" href="#recommended-licenses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>MIT: <a href="https://opensource.org/licenses/MIT">Expat/MIT/X11 license</a></li>
|
||||
<li>BSD-2-Clause: <a href="https://opensource.org/licenses/BSD-2-Clause">OSI-approved BSD 2-clause license</a></li>
|
||||
<li>BSD-3-Clause: <a href="https://opensource.org/licenses/BSD-3-Clause">OSI-approved BSD 3-clause license</a></li>
|
||||
<li>CC0-1.0: <a href="https://creativecommons.org/publicdomain/zero/1.0/">Creative Commons CC0 1.0 Universal</a></li>
|
||||
<li>GNU-All-Permissive: <a href="https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html">GNU All-Permissive License</a></li>
|
||||
<li>Apache-2.0: <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License, version 2.0</a></li>
|
||||
</ul>
|
||||
<p>In addition, it is RECOMMENDED that literal code included in the ZIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for zcashd would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ZIP text.</p>
|
||||
</section>
|
||||
<section id="not-recommended-but-acceptable-licenses"><h3><span class="section-heading">Not recommended, but acceptable licenses</span><span class="section-anchor"> <a rel="bookmark" href="#not-recommended-but-acceptable-licenses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>BSL-1.0: <a href="https://www.boost.org/LICENSE_1_0.txt">Boost Software License, version 1.0</a></li>
|
||||
<li>CC-BY-4.0: <a href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International</a></li>
|
||||
<li>CC-BY-SA-4.0: <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International</a></li>
|
||||
<li>AGPL-3.0+: <a href="https://www.gnu.org/licenses/agpl-3.0.en.html">GNU Affero General Public License (AGPL), version 3 or newer</a></li>
|
||||
<li>FDL-1.3: <a href="https://www.gnu.org/licenses/fdl-1.3.en.html">GNU Free Documentation License, version 1.3</a></li>
|
||||
<li>GPL-2.0+: <a href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html">GNU General Public License (GPL), version 2 or newer</a></li>
|
||||
<li>LGPL-2.1+: <a href="https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html">GNU Lesser General Public License (LGPL), version 2.1 or newer</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="not-acceptable-licenses"><h3><span class="section-heading">Not acceptable licenses</span><span class="section-anchor"> <a rel="bookmark" href="#not-acceptable-licenses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>All licenses not explicitly included in the above lists are not acceptable terms for a Zcash Improvement Proposal.</p>
|
||||
</section>
|
||||
<section id="rationale"><h3><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Bitcoin's BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?</p>
|
||||
<ul>
|
||||
<li>The OPL is generally regarded as obsolete, and not a license suitable for new publications.</li>
|
||||
<li>The OPL license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate.</li>
|
||||
<li>In some jurisdictions, releasing a work to the public domain is not recognised as a legitimate legal action, leaving the ZIP simply copyrighted with no redistribution or modification allowed at all.</li>
|
||||
</ul>
|
||||
<p>Why are there software licenses included?</p>
|
||||
<ul>
|
||||
<li>Some ZIPs, especially in the Consensus category, may include literal code in the ZIP itself which may not be available under the exact license terms of the ZIP.</li>
|
||||
<li>Despite this, not all software licenses would be acceptable for content included in ZIPs.</li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="see-also"><h2><span class="section-heading">See Also</span><span class="section-anchor"> <a rel="bookmark" href="#see-also"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li><a href="https://www.rfc-editor.org/rfc/rfc7282.html">RFC 7282: On Consensus and Humming in the IETF</a></li>
|
||||
<li><a href="https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/">Zcash Network Upgrade Pipeline</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="rfc3552" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="https://www.rfc-editor.org/rfc/rfc3552.html">RFC 3552: Guidelines for Writing RFC Text on Security Considerations</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="conduct" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="https://github.com/zcash/zcash/blob/master/code_of_conduct.md">Zcash Code of Conduct</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="rst" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="https://docutils.sourceforge.io/rst.html">reStructuredText documentation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="markdown" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="https://www.markdownguide.org/">The Markdown Guide</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="latex" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="https://www.latex-project.org/">LaTeX — a document preparation system</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,637 @@
|
|||
::
|
||||
|
||||
ZIP: 0
|
||||
Title: ZIP Process
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Deirdre Connolly <deirdre@zfnd.org>
|
||||
Original-Authors: Daira Hopwood
|
||||
Josh Cincinnati
|
||||
George Tankersley
|
||||
Credits: Luke Dashjr
|
||||
Status: Active
|
||||
Category: Process
|
||||
Created: 2019-02-16
|
||||
License: BSD-2-Clause
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED",
|
||||
"OPTIONAL", and "REQUIRED" in this document are to be interpreted as
|
||||
described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as
|
||||
described in ZIP 200. [#zip-0200]_
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
A Zcash Improvement Proposal (ZIP) is a design document providing
|
||||
information to the Zcash community, or describing a new feature for
|
||||
Zcash or its processes or environment. The ZIP should provide a concise
|
||||
technical specification of the feature and a rationale for the feature.
|
||||
|
||||
We intend ZIPs to be the primary mechanism for proposing new features,
|
||||
for collecting community input on an issue, and for documenting the
|
||||
design decisions that have gone into Zcash. The Owner(s) of the ZIP
|
||||
(usually the authors(s)) are responsible for building consensus within
|
||||
the community and documenting dissenting opinions.
|
||||
|
||||
Because the ZIPs are maintained as text files in a versioned repository,
|
||||
their revision history is the historical record of the feature proposal.
|
||||
|
||||
This document is based partly on the work done by Luke Dashjr with
|
||||
`BIP 2 <https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki>`__.
|
||||
|
||||
|
||||
ZIP Workflow
|
||||
============
|
||||
|
||||
The ZIP process begins with a new idea for Zcash. Each potential ZIP
|
||||
must have Owners — one or more people who write the ZIP using the style
|
||||
and format described below, shepherd the discussions in the appropriate
|
||||
forums, and attempt to build community consensus around the idea. The
|
||||
ZIP Owners should first attempt to ascertain whether the idea is ZIP-able.
|
||||
Small enhancements or patches to a particular piece of software often
|
||||
don't require standardisation between multiple projects; these don't
|
||||
need a ZIP and should be injected into the relevant project-specific
|
||||
development workflow with a patch submission to the applicable issue
|
||||
tracker. Additionally, many ideas have been brought forward for changing
|
||||
Zcash that have been rejected for various reasons. The first step should
|
||||
be to search past discussions to see if an idea has been considered
|
||||
before, and if so, what issues arose in its progression. After
|
||||
investigating past work, the best way to proceed is by posting about the
|
||||
new idea to the `Zcash Community Forum <https://forum.zcashcommunity.com/>`__.
|
||||
|
||||
Vetting an idea publicly before going as far as writing a ZIP is meant
|
||||
to save both the potential Owners and the wider community time. Asking
|
||||
the Zcash community first if an idea is original helps prevent too much
|
||||
time being spent on something that is guaranteed to be rejected based on
|
||||
prior discussions (searching the internet does not always do the trick).
|
||||
It also helps to make sure the idea is applicable to the entire
|
||||
community and not just the Owners. Just because an idea sounds good to
|
||||
the Owners does not mean it will work for most people in most areas
|
||||
where Zcash is used.
|
||||
|
||||
Once the Owners have asked the Zcash community as to whether an idea
|
||||
has any chance of acceptance, a draft ZIP should be presented to the
|
||||
`Zcash Community Forum <https://forum.zcashcommunity.com/>`__.
|
||||
This gives the Owners a chance to flesh out the draft ZIP to make it
|
||||
properly formatted, of high quality, and to address additional concerns
|
||||
about the proposal. Following a discussion, the proposal should be
|
||||
submitted to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
||||
as a pull request. This draft must be written in ZIP style as described
|
||||
below, and named with an alias such as
|
||||
``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned
|
||||
it a ZIP number (Owners MUST NOT self-assign ZIP numbers).
|
||||
|
||||
ZIP Owners are responsible for collecting community feedback on both
|
||||
the initial idea and the ZIP before submitting it for review. However,
|
||||
wherever possible, long open-ended discussions on forums should be avoided.
|
||||
|
||||
It is highly recommended that a single ZIP contain a single key proposal
|
||||
or new idea. The more focused the ZIP, the more successful it tends to
|
||||
be. If in doubt, split your ZIP into several well-focused ones.
|
||||
|
||||
When the ZIP draft is complete, the ZIP Editors will assign the ZIP a
|
||||
number (if that has not already been done) and one or more Categories,
|
||||
and merge the pull request to the ZIPs git repository. The ZIP Editors
|
||||
will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include
|
||||
duplication of effort, disregard for formatting rules, being too
|
||||
unfocused or too broad, being technically unsound, not providing proper
|
||||
motivation or not in keeping with the Zcash philosophy. For a ZIP to be
|
||||
accepted it must meet certain minimum criteria. It must be a clear and
|
||||
complete description of the proposed enhancement. The enhancement must
|
||||
represent a net improvement. The proposed implementation, if applicable,
|
||||
must be solid and must not complicate the protocol unduly.
|
||||
|
||||
The ZIP Owners may update the draft as necessary in the git repository.
|
||||
Updates to drafts should also be submitted by the Owners as pull requests.
|
||||
|
||||
|
||||
ZIP Numbering Conventions
|
||||
-------------------------
|
||||
|
||||
The ZIP Editors currently use the following conventions when numbering
|
||||
ZIPs:
|
||||
|
||||
* if a ZIP directly corresponds to a BIP (Bitcoin Improvement Proposal),
|
||||
and the number doesn't clash, assign the same number;
|
||||
* if it affects the consensus layer or the core protocol, assign a
|
||||
number in the range 200..299;
|
||||
* if it affects only higher layers but is needed for interoperability
|
||||
between node implementations or other parts of the ecosystem, assign
|
||||
a number in the range 300..399;
|
||||
* if it is specific to an implementation (e.g. zcashd or zebra), assign
|
||||
a number in the range 400..499;
|
||||
* try to number ZIPs that should or will be deployed together
|
||||
consecutively (subject to the above conventions), and in a coherent
|
||||
reading order.
|
||||
|
||||
These conventions are subject to change by consensus of the ZIP Editors.
|
||||
|
||||
|
||||
Transferring ZIP Ownership
|
||||
--------------------------
|
||||
|
||||
It occasionally becomes necessary to transfer ownership of ZIPs to a new
|
||||
Owner. In general, we'd like to retain the original Owner as a
|
||||
co-Owner of the transferred ZIP, but that's really up to the original
|
||||
Owner. A good reason to transfer ownership is because the original
|
||||
Owner no longer has the time or interest in updating it or following
|
||||
through with the ZIP process, or has fallen off the face of the 'net
|
||||
(i.e. is unreachable or not responding to email). A bad reason to
|
||||
transfer ownership is because you don't agree with the direction of the
|
||||
ZIP. We try to build consensus around a ZIP, but if that's not possible,
|
||||
you can always submit a competing ZIP.
|
||||
|
||||
If you are interested in assuming ownership of a ZIP, send a message
|
||||
asking to take over, addressed to both the original Owner and the ZIP
|
||||
Editors. If the original Owner doesn't respond to email in a timely
|
||||
manner, the ZIP Editors will make a unilateral decision (it's not like
|
||||
such decisions can't be reversed :).
|
||||
|
||||
If an author of a ZIP is no longer an Owner, an Original-Authors field
|
||||
SHOULD be added to the ZIP metadata indicating the original authorship,
|
||||
unless the original author(s) request otherwise.
|
||||
|
||||
|
||||
ZIP Editors
|
||||
-----------
|
||||
|
||||
The current ZIP Editors are Daira Hopwood, representing the Electric Coin
|
||||
Company, and Deirdre Connolly, representing the Zcash Foundation. Both
|
||||
can be reached at zips@z.cash . The current design of the ZIP Process
|
||||
dictates that there are always at least two ZIP Editors: one from the
|
||||
Electric Coin Company and one from the Zcash Foundation. Additional Editors may
|
||||
be selected by consensus among the current Editors.
|
||||
|
||||
|
||||
ZIP Editor Responsibilities & Workflow
|
||||
--------------------------------------
|
||||
|
||||
The ZIP Editors subscribe to the `Zcash Community Forum.
|
||||
<https://forum.zcashcommunity.com/>`__
|
||||
|
||||
For each new ZIP that comes in an Editor confirms the following:
|
||||
|
||||
* Read the ZIP to check if it is ready: sound and complete. The ideas
|
||||
must make technical sense, even if they don't seem likely to be
|
||||
accepted.
|
||||
* The title should accurately describe the content.
|
||||
* The ZIP draft must have been sent to the Zcash Community Forum or as
|
||||
a PR to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
||||
* Motivation and backward compatibility (when applicable) must be
|
||||
addressed.
|
||||
* The licensing terms are acceptable for ZIPs.
|
||||
|
||||
If the ZIP isn't ready, the editor will send it back to the Owners for
|
||||
revision, with specific instructions.
|
||||
|
||||
Once the ZIP is ready for the repository it SHOULD be submitted as a
|
||||
"pull request" to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
||||
where it may get further feedback. It SHOULD NOT contain a ZIP number
|
||||
unless one had already been assigned by the ZIP Editors. The pull
|
||||
request SHOULD initially be marked as a Draft.
|
||||
|
||||
The ZIP Editors will:
|
||||
|
||||
* Assign a ZIP number in the pull request.
|
||||
* Remove Draft status and merge the pull request when it is ready.
|
||||
|
||||
The ZIP editors monitor ZIP changes and update ZIP headers as
|
||||
appropriate.
|
||||
|
||||
The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP
|
||||
for any of the following reasons:
|
||||
|
||||
* it violates the Zcash Code of Conduct [#conduct]_ ;
|
||||
* it appears too unfocused or broad;
|
||||
* it duplicates effort in other ZIPs without sufficient technical justification
|
||||
(however, alternative proposals to address similar or overlapping problems
|
||||
are not excluded for this reason);
|
||||
* it has manifest security flaws (including being unrealistically dependent
|
||||
on user vigilance to avoid security weaknesses);
|
||||
* it disregards compatibility with the existing Zcash blockchain or ecosystem;
|
||||
* it is manifestly unimplementable;
|
||||
* it includes buggy code, pseudocode, or algorithms;
|
||||
* it manifestly violates common expectations of a significant portion of the
|
||||
Zcash community;
|
||||
* it updates a Draft ZIP to Released when there is significant community
|
||||
opposition to its content (however, Draft ZIPs explicitly may describe
|
||||
proposals to which there is, or could be expected, significant community
|
||||
opposition);
|
||||
* in the case of a Released ZIP, the update makes a substantive change to
|
||||
which there is significant community opposition;
|
||||
* it is dependent on a patent that could potentially be an obstacle to
|
||||
adoption of the ZIP;
|
||||
* it includes commercial advertising or spam;
|
||||
* it disregards formatting rules;
|
||||
* it makes non-editorial edits to previous entries in a ZIP's Change history,
|
||||
if there is one;
|
||||
* an update to an existing ZIP extends or changes its scope to an extent
|
||||
that would be better handled as a separate ZIP;
|
||||
* a new ZIP has been proposed for a category that does not reflect its content,
|
||||
or an update would change a ZIP to an inappropriate category;
|
||||
* it updates a Released ZIP to Draft when the specification is already
|
||||
implemented and has been in common use;
|
||||
* it violates any specific "MUST" or "MUST NOT" rule in this document;
|
||||
* the expressed political views of a Owner of the document are inimical
|
||||
to the Zcash Code of Conduct [#conduct]_ (except in the case of an update
|
||||
removing that Owner);
|
||||
* it is not authorized by the stated ZIP Owners;
|
||||
* it removes an Owner without their consent (unless the reason for removal
|
||||
is directly related to a breach of the Code of Conduct by that Owner).
|
||||
|
||||
The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal
|
||||
or update that does not violate any of these criteria. If they refuse a
|
||||
proposal or update, they MUST give an explanation of which of the
|
||||
criteria were violated, with the exception that spam may be deleted
|
||||
without an explanation.
|
||||
|
||||
Note that it is not the primary responsibility of the ZIP Editors to
|
||||
review proposals for security, correctness, or implementability.
|
||||
|
||||
Please send all ZIP-related communications either by email to
|
||||
<zips@z.cash>, or by opening an issue on the `ZIPs issue
|
||||
tracker <https://github.com/zcash/zips/issues>`__. All communications
|
||||
should abide by the Zcash Code of Conduct [#conduct]_
|
||||
and follow `the GNU Kind Communication
|
||||
Guidelines <https://www.gnu.org/philosophy/kind-communication.en.html>`__
|
||||
|
||||
|
||||
ZIP format and structure
|
||||
========================
|
||||
|
||||
ZIPs SHOULD be written in reStructuredText [#rst]_, Markdown [#markdown]_,
|
||||
or LaTeX [#latex]_. For ZIPs written in LaTeX, a ``Makefile`` MUST be
|
||||
provided to build (at least) a PDF version of the document.
|
||||
|
||||
Each ZIP SHOULD have the following parts:
|
||||
|
||||
* Preamble — Headers containing metadata about the ZIP (`see
|
||||
below <#zip-header-preamble>`__).
|
||||
The License field of the preamble indicates the licensing terms,
|
||||
which MUST be acceptable according to `the ZIP licensing requirements <#zip-licensing>`__.
|
||||
|
||||
* Terminology — Definitions of technical or non-obvious terms used
|
||||
in the document.
|
||||
|
||||
* Abstract — A short (~200 word) description of the technical issue
|
||||
being addressed.
|
||||
|
||||
* Motivation — The motivation is critical for ZIPs that want to change
|
||||
the Zcash protocol. It should clearly explain why the existing
|
||||
protocol is inadequate to address the problem that the ZIP solves.
|
||||
|
||||
* Specification — The technical specification should describe the
|
||||
interface and semantics of any new feature. The specification should be
|
||||
detailed enough to allow competing, interoperable implementations for
|
||||
any of the current Zcash platforms.
|
||||
|
||||
* Rationale — The rationale fleshes out the specification by
|
||||
describing what motivated the design and why particular design
|
||||
decisions were made. It should describe alternate designs that were
|
||||
considered and related work. The rationale should provide evidence of
|
||||
consensus within the community and discuss important objections or
|
||||
concerns raised during discussion.
|
||||
|
||||
* Security and privacy considerations — If applicable, security
|
||||
and privacy considerations should be explicitly described, particularly
|
||||
if the ZIP makes explicit trade-offs or assumptions. For guidance on
|
||||
this section consider RFC 3552 [#RFC3552]_ as a starting point.
|
||||
|
||||
* Reference implementation — Literal code implementing the ZIP's
|
||||
specification, and/or a link to the reference implementation of
|
||||
the ZIP's specification. The reference implementation MUST be
|
||||
completed before any ZIP is given status “Implemented” or “Final”,
|
||||
but it generally need not be completed before the ZIP is accepted
|
||||
into “Proposed”.
|
||||
|
||||
ZIP header preamble
|
||||
-------------------
|
||||
|
||||
Each ZIP MUST begin with a RFC 822-style header preamble. For ZIPs written
|
||||
in reStructuredText, this is represented as ``::`` on the first line,
|
||||
followed by a blank line, then the preamble indented by 2 spaces.
|
||||
|
||||
The following header fields are REQUIRED::
|
||||
|
||||
ZIP:
|
||||
Title:
|
||||
Owners:
|
||||
Status:
|
||||
Category:
|
||||
Created:
|
||||
License:
|
||||
|
||||
The following additional header fields are OPTIONAL::
|
||||
|
||||
Credits:
|
||||
Original-Authors:
|
||||
Discussions-To:
|
||||
Pull-Request:
|
||||
Obsoleted by:
|
||||
Updated by:
|
||||
Obsoletes:
|
||||
Updates:
|
||||
|
||||
The Owners header lists the names and email addresses of all the
|
||||
Owners of the ZIP. The format of the Owners header value SHOULD be::
|
||||
|
||||
Random J. User <address@dom.ain>
|
||||
|
||||
If there are multiple Owners, each should be on a separate line.
|
||||
|
||||
The "Owners", "Credits", and "Original-Authors" headers always use
|
||||
these plural spellings even there is only one Owner, one person to be
|
||||
credited, or one original author.
|
||||
|
||||
While a ZIP is in public discussions (usually during the initial Draft
|
||||
phase), a Discussions-To header will indicate the URL where the ZIP is
|
||||
being discussed. No Discussions-To header is necessary if the ZIP is being
|
||||
discussed privately with the Owner.
|
||||
|
||||
The Pull-Request header, if present, gives an URL to a Pull Request for
|
||||
the ZIP.
|
||||
|
||||
The Category header specifies the type of ZIP, as described in
|
||||
`ZIP categories`_. Multiple categories MAY be specified, separated by
|
||||
" ``/`` ".
|
||||
|
||||
The Created header records the date that the ZIP was submitted.
|
||||
Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.
|
||||
|
||||
For ZIPs written in reStructuredText, URLs in header fields SHOULD be
|
||||
surrounded by ``<`` ``>``; this ensures that the link is rendered correctly.
|
||||
|
||||
Auxiliary Files
|
||||
---------------
|
||||
|
||||
ZIPs may include auxiliary files such as diagrams. Auxiliary files
|
||||
should be included in a subdirectory for that ZIP; that is, for any ZIP
|
||||
that requires more than one file, all of the files SHOULD be in a
|
||||
subdirectory named zip-XXXX.
|
||||
|
||||
|
||||
ZIP categories
|
||||
==============
|
||||
|
||||
Each ZIP is in one or more of the following categories, as specified
|
||||
in the Category header:
|
||||
|
||||
Consensus
|
||||
Rules that affect the consensus protocol followed by all Zcash
|
||||
implementations.
|
||||
Standards
|
||||
Non-consensus changes affecting most or all Zcash implementations, or
|
||||
the interoperability of applications using Zcash.
|
||||
Process
|
||||
A Process ZIP describes a process surrounding Zcash, or proposes a
|
||||
change to (or an event in) a process. They may propose an implementation,
|
||||
but not to Zcash's codebase; they often require community consensus;
|
||||
unlike Informational ZIPs, they are more than recommendations, and users
|
||||
are typically not free to ignore them. Examples include procedures,
|
||||
guidelines, changes to the decision-making process, and changes to the
|
||||
tools or environment used in Zcash development.
|
||||
Consensus Process
|
||||
A subcategory of Process ZIP that specifies requirements and processes
|
||||
that are to be realized by one or more Consensus ZIPs, and/or by social
|
||||
consensus of the Zcash community.
|
||||
Informational
|
||||
An Informational ZIP describes non-consensus Zcash design issues, or
|
||||
general guidelines or information for the Zcash community. These ZIPs
|
||||
do not not necessarily represent a Zcash community consensus or
|
||||
recommendation, so users and implementors are free to ignore
|
||||
Informational ZIPs or follow their advice.
|
||||
Network
|
||||
Specifications of peer-to-peer networking behaviour.
|
||||
RPC
|
||||
Specifications of the RPC interface provided by zcashd nodes.
|
||||
Wallet
|
||||
Specifications affecting wallets (e.g. non-consensus changes to how
|
||||
transactions, addresses, etc. are constructed or interpreted).
|
||||
Ecosystem
|
||||
Specifications otherwise useful to the Zcash ecosystem.
|
||||
|
||||
New categories may be added by consensus among the ZIP Editors.
|
||||
|
||||
Consensus and Standards ZIPs SHOULD have a Reference Implementation section,
|
||||
which includes or (more often) links to an implementation.
|
||||
|
||||
Consensus ZIPs SHOULD have a Deployment section, describing how and when
|
||||
the consensus change is planned to be deployed (for example, in a particular
|
||||
network upgrade).
|
||||
|
||||
|
||||
ZIP Status Field
|
||||
================
|
||||
|
||||
* Reserved: The ZIP Editors have reserved this ZIP number, and there MAY
|
||||
be a Pull Request for it, but no ZIP has been published. The ZIP Editors
|
||||
SHOULD publish a stub header so that the reservation appears in the
|
||||
`ZIP index <https://zips.z.cash#index-of-zips>`__.
|
||||
|
||||
* Draft: All initial ZIP submissions have this status.
|
||||
|
||||
* Withdrawn: If the Owner decides to remove the ZIP from
|
||||
consideration by the community, they may set the status to Withdrawn.
|
||||
|
||||
* Active: Typically only used for Process/Informational ZIPs, achieved
|
||||
once rough consensus is reached in PR/forum posts from Draft Process ZIP.
|
||||
|
||||
* Proposed: Typically the stage after Draft, added to a ZIP after
|
||||
consideration, feedback, and rough consensus from the community. The ZIP
|
||||
Editors must validate this change before it is approved.
|
||||
|
||||
* Rejected: The status when progress hasn't been made on the ZIP in one
|
||||
year. Can revert back to Draft/Proposed if the Owner resumes work
|
||||
or resolves issues preventing consensus.
|
||||
|
||||
* Implemented: When a Consensus or Standards ZIP has a working
|
||||
reference implementation but before activation on the Zcash network.
|
||||
|
||||
* Final: When a Consensus or Standards ZIP is both implemented
|
||||
and activated on the Zcash network.
|
||||
|
||||
* Obsolete: The status when a ZIP is no longer relevant (typically when
|
||||
superseded by another ZIP).
|
||||
|
||||
More details on the status workflow are given in the section below.
|
||||
|
||||
Specification
|
||||
-------------
|
||||
|
||||
Owners of a ZIP may decide on their own to change the status between
|
||||
Draft or Withdrawn.
|
||||
|
||||
A ZIP may only change status from Draft (or Rejected) to Proposed, when
|
||||
the Owner deems it is complete and there is rough consensus on the
|
||||
forums, validated by both the Electric Coin Company and Zcash Foundation
|
||||
Editors. One Editor will not suffice — there needs to be consensus
|
||||
among the Editors. If it's a Consensus ZIP, a Deployment section MUST
|
||||
be present in order for the ZIP to change status to Proposed. Typically,
|
||||
although not necessarily, this will specify a network upgrade in which
|
||||
the consensus change is to activate.
|
||||
|
||||
A Standards ZIP may only change status from Proposed to Implemented once
|
||||
the Owners provide an associated reference implementation, typically in
|
||||
the period after the network upgrade's specification freeze but before
|
||||
the implementation audit. If the Owners miss this deadline, the Editors
|
||||
or Owners MAY choose to update the Deployment section of the ZIP to
|
||||
target another upgrade, at their discretion.
|
||||
|
||||
ZIPs should be changed from Draft or Proposed status, to Rejected
|
||||
status, upon request by any person, if they have not made progress in
|
||||
one year. Such a ZIP may be changed to Draft status if the Owner
|
||||
provides revisions that meaningfully address public criticism of the
|
||||
proposal, or to Proposed status if it meets the criteria required as
|
||||
described in the previous paragraphs.
|
||||
|
||||
A Consensus or Standards ZIP becomes Final when its associated network
|
||||
upgrade or other protocol change is activated on Zcash's mainnet.
|
||||
|
||||
A Process or Informational ZIP may change status from Draft to Active
|
||||
when it achieves rough consensus on the forum or PR. Such a proposal is
|
||||
said to have rough consensus if it has been open to discussion on the
|
||||
forum or GitHub PR for at least one month, and no person maintains
|
||||
any unaddressed substantiated objections to it. Addressed or obstructive
|
||||
objections may be ignored/overruled by general agreement that they have
|
||||
been sufficiently addressed, but clear reasoning must be given in such
|
||||
circumstances.
|
||||
|
||||
When an Active or Final ZIP is no longer relevant, its status may be
|
||||
changed to Obsolete. This change must also be objectively verifiable
|
||||
and/or discussed. Final ZIPs may be updated; the specification is still
|
||||
in force but modified by another specified ZIP or ZIPs (check the
|
||||
optional Updated-by header).
|
||||
|
||||
|
||||
ZIP Comments
|
||||
============
|
||||
|
||||
Comments from the community on the ZIP should occur on the Zcash
|
||||
Community Forum and the comment fields of the pull requests in
|
||||
any open ZIPs. Editors will use these sources to judge rough consensus.
|
||||
|
||||
|
||||
ZIP Licensing
|
||||
=============
|
||||
|
||||
New ZIPs may be accepted with the following licenses. Each new ZIP MUST
|
||||
identify at least one acceptable license in its preamble. Each license
|
||||
MUST be referenced by their respective abbreviation given below.
|
||||
|
||||
For example, a preamble might include the following License header::
|
||||
|
||||
License: BSD-2-Clause
|
||||
GNU-All-Permissive
|
||||
|
||||
In this case, the ZIP text is fully licensed under both the OSI-approved
|
||||
BSD 2-clause license as well as the GNU All-Permissive License, and
|
||||
anyone may modify and redistribute the text provided they comply with
|
||||
the terms of *either* license. In other words, the license list is an
|
||||
"OR choice", not an "AND also" requirement.
|
||||
|
||||
It is also possible to license source code differently from the ZIP
|
||||
text. This case SHOULD be indicated in the Reference Implementation
|
||||
section of the ZIP. Again, each license MUST be referenced by its
|
||||
respective abbreviation given below.
|
||||
|
||||
Statements of code licenses in ZIPs are only advisory; anyone intending
|
||||
to use the code should look for license statements in the code itself.
|
||||
|
||||
ZIPs are not required to be *exclusively* licensed under approved
|
||||
terms, and MAY also be licensed under unacceptable licenses
|
||||
*in addition to* at least one acceptable license. In this case, only the
|
||||
acceptable license(s) should be listed in the License header.
|
||||
|
||||
|
||||
Recommended licenses
|
||||
--------------------
|
||||
|
||||
* MIT: `Expat/MIT/X11 license <https://opensource.org/licenses/MIT>`__
|
||||
* BSD-2-Clause: `OSI-approved BSD 2-clause
|
||||
license <https://opensource.org/licenses/BSD-2-Clause>`__
|
||||
* BSD-3-Clause: `OSI-approved BSD 3-clause
|
||||
license <https://opensource.org/licenses/BSD-3-Clause>`__
|
||||
* CC0-1.0: `Creative Commons CC0 1.0
|
||||
Universal <https://creativecommons.org/publicdomain/zero/1.0/>`__
|
||||
* GNU-All-Permissive: `GNU All-Permissive
|
||||
License <https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html>`__
|
||||
* Apache-2.0: `Apache License, version
|
||||
2.0 <https://www.apache.org/licenses/LICENSE-2.0>`__
|
||||
|
||||
In addition, it is RECOMMENDED that literal code included in the ZIP be
|
||||
dual-licensed under the same license terms as the project it modifies.
|
||||
For example, literal code intended for zcashd would ideally be
|
||||
dual-licensed under the MIT license terms as well as one of the above
|
||||
with the rest of the ZIP text.
|
||||
|
||||
Not recommended, but acceptable licenses
|
||||
----------------------------------------
|
||||
|
||||
* BSL-1.0: `Boost Software License, version
|
||||
1.0 <https://www.boost.org/LICENSE_1_0.txt>`__
|
||||
* CC-BY-4.0: `Creative Commons Attribution 4.0
|
||||
International <https://creativecommons.org/licenses/by/4.0/>`__
|
||||
* CC-BY-SA-4.0: `Creative Commons Attribution-ShareAlike 4.0
|
||||
International <https://creativecommons.org/licenses/by-sa/4.0/>`__
|
||||
* AGPL-3.0+: `GNU Affero General Public License (AGPL), version 3 or
|
||||
newer <https://www.gnu.org/licenses/agpl-3.0.en.html>`__
|
||||
* FDL-1.3: `GNU Free Documentation License, version
|
||||
1.3 <https://www.gnu.org/licenses/fdl-1.3.en.html>`__
|
||||
* GPL-2.0+: `GNU General Public License (GPL), version 2 or
|
||||
newer <https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html>`__
|
||||
* LGPL-2.1+: `GNU Lesser General Public License (LGPL), version 2.1 or
|
||||
newer <https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html>`__
|
||||
|
||||
Not acceptable licenses
|
||||
-----------------------
|
||||
|
||||
All licenses not explicitly included in the above lists are not
|
||||
acceptable terms for a Zcash Improvement Proposal.
|
||||
|
||||
Rationale
|
||||
---------
|
||||
|
||||
Bitcoin's BIP 1 allowed the Open Publication License or releasing into
|
||||
the public domain; was this insufficient?
|
||||
|
||||
* The OPL is generally regarded as obsolete, and not a license suitable
|
||||
for new publications.
|
||||
* The OPL license terms allowed for the author to prevent publication
|
||||
and derived works, which was widely considered inappropriate.
|
||||
* In some jurisdictions, releasing a work to the public domain is not
|
||||
recognised as a legitimate legal action, leaving the ZIP simply
|
||||
copyrighted with no redistribution or modification allowed at all.
|
||||
|
||||
Why are there software licenses included?
|
||||
|
||||
* Some ZIPs, especially in the Consensus category, may include literal
|
||||
code in the ZIP itself which may not be available under the exact
|
||||
license terms of the ZIP.
|
||||
* Despite this, not all software licenses would be acceptable for
|
||||
content included in ZIPs.
|
||||
|
||||
|
||||
See Also
|
||||
========
|
||||
|
||||
* `RFC 7282: On Consensus and Humming in the
|
||||
IETF <https://www.rfc-editor.org/rfc/rfc7282.html>`__
|
||||
* `Zcash Network Upgrade Pipeline <https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/>`__
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#RFC3552] `RFC 3552: Guidelines for Writing RFC Text on Security Considerations <https://www.rfc-editor.org/rfc/rfc3552.html>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#conduct] `Zcash Code of Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`_
|
||||
.. [#rst] `reStructuredText documentation <https://docutils.sourceforge.io/rst.html>`_
|
||||
.. [#markdown] `The Markdown Guide <https://www.markdownguide.org/>`_
|
||||
.. [#latex] `LaTeX — a document preparation system <https://www.latex-project.org/>`_
|
|
@ -0,0 +1,16 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 1: Network Upgrade Policy and Scheduling</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 1
|
||||
Title: Network Upgrade Policy and Scheduling
|
||||
Status: Reserved
|
||||
Category: Consensus Process
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/343">https://github.com/zcash/zips/issues/343</a>></pre>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,7 @@
|
|||
::
|
||||
|
||||
ZIP: 1
|
||||
Title: Network Upgrade Policy and Scheduling
|
||||
Status: Reserved
|
||||
Category: Consensus Process
|
||||
Discussions-To: <https://github.com/zcash/zips/issues/343>
|
|
@ -0,0 +1,16 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 2: Design Considerations for Network Upgrades</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 2
|
||||
Title: Design Considerations for Network Upgrades
|
||||
Status: Reserved
|
||||
Category: Informational
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/362">https://github.com/zcash/zips/issues/362</a>></pre>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,7 @@
|
|||
::
|
||||
|
||||
ZIP: 2
|
||||
Title: Design Considerations for Network Upgrades
|
||||
Status: Reserved
|
||||
Category: Informational
|
||||
Discussions-To: <https://github.com/zcash/zips/issues/362>
|
|
@ -0,0 +1,16 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 22: Specification of getblocktemplate for Zcash</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 22
|
||||
Title: Specification of getblocktemplate for Zcash
|
||||
Status: Reserved
|
||||
Category: RPC
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/349">https://github.com/zcash/zips/issues/349</a>></pre>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
After Width: | Height: | Size: 186 KiB |
After Width: | Height: | Size: 83 KiB |
After Width: | Height: | Size: 228 KiB |
After Width: | Height: | Size: 89 KiB |
|
@ -0,0 +1,711 @@
|
|||
::
|
||||
|
||||
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
|
||||
|
||||
: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 .`
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.
|
||||
[#RFC2119]_
|
||||
|
||||
"Jubjub" refers to the elliptic curve defined in [#protocol-jubjub]_.
|
||||
|
||||
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.
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash
|
||||
Protocol Specification [#protocol-networks]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32
|
||||
[#bip-0032]_, to support Zcash's shielded addresses.
|
||||
|
||||
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):
|
||||
|
||||
- Sapling
|
||||
- Orchard
|
||||
|
||||
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 `zcashd` no longer
|
||||
generates Sprout addresses (and neither `Zebra` nor the mobile SDKs have ever done so).
|
||||
|
||||
The last part shows how to use these trees in the context of existing BIP 44 [#bip-0044]_ wallets.
|
||||
|
||||
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).
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
BIP 32 [#bip-0032]_ is the standard mechanism by which wallets for Bitcoin and its derivatives (including
|
||||
Zcash's transparent addresses [#slip-0044]_) generate keys and addresses deterministically. This has several
|
||||
advantages over random generation:
|
||||
|
||||
- Wallets only need to store a single seed (particularly useful for hardware wallets).
|
||||
- A one-time backup of the seed (usually stored as a word phrase [#bip-0039]_) can be used to recover funds
|
||||
from all future addresses.
|
||||
- Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level
|
||||
structures.
|
||||
- Viewing authority or spending authority can be delegated independently for sub-trees without compromising
|
||||
the master seed.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Conventions
|
||||
===========
|
||||
|
||||
Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification
|
||||
[#protocol]_. They are reproduced here for convenience:
|
||||
|
||||
- :math:`\mathsf{truncate}_k(S)` means the sequence formed from the first :math:`k` elements of :math:`S`.
|
||||
|
||||
- :math:`a\,||\,b` means the concatenation of sequences :math:`a` then :math:`b`.
|
||||
|
||||
- :math:`[k] P` means scalar multiplication of the elliptic curve point :math:`P` by the scalar :math:`k`.
|
||||
|
||||
- :math:`\mathsf{LEOS2IP}_\ell(S)` is the integer in range :math:`\{ 0\,.\!. 2^\ell - 1 \}` represented in
|
||||
little-endian order by the byte sequence :math:`S` of length :math:`\ell/8`.
|
||||
|
||||
- :math:`\mathsf{I2LEBSP}_\ell(k)` is the sequence of :math:`\ell` bits representing :math:`k` in
|
||||
little-endian order.
|
||||
|
||||
- :math:`\mathsf{LEBS2OSP}_\ell(B)` is defined as follows when :math:`\ell` is a multiple of :math:`8`:
|
||||
convert each group of 8 bits in :math:`B` to a byte value with the least significant bit first, and
|
||||
concatenate the resulting bytes in the same order as the groups.
|
||||
|
||||
- :math:`\mathsf{repr}_\mathbb{J}(P)` is the representation of the Jubjub elliptic curve point :math:`P`
|
||||
as a bit sequence, defined in [#protocol-jubjub]_.
|
||||
|
||||
- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)` refers to unkeyed BLAKE2b-256 in sequential mode,
|
||||
with an output digest length of 32 bytes, 16-byte personalization string :math:`p`, and input :math:`x`.
|
||||
|
||||
- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{512}(p, x)` refers to unkeyed BLAKE2b-512 in sequential mode,
|
||||
with an output digest length of 64 bytes, 16-byte personalization string :math:`p`, and input :math:`x`.
|
||||
|
||||
- :math:`\mathsf{PRF^{expand}}(\mathsf{sk}, t) :=`:math:`\mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“Zcash_ExpandSeed”},`:math:`\mathsf{sk}\,||\,t)`
|
||||
|
||||
- :math:`r_\mathbb{J}` is the order of the Jubjub large prime subgroup.
|
||||
|
||||
- :math:`r_\mathbb{P}` is the order of the Pallas curve.
|
||||
|
||||
- :math:`\mathsf{ToScalar^{Sapling}}(x) :=`:math:`\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}`.
|
||||
|
||||
- :math:`\mathsf{ToScalar^{Orchard}}(x) :=`:math:`\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{P}}`.
|
||||
|
||||
- :math:`\mathsf{DiversifyHash^{Sapling}}(d)` maps a diversifier :math:`d` to a base point on the Jubjub elliptic
|
||||
curve, or to :math:`\bot` if the diversifier is invalid. It is instantiated in [#protocol-concretediversifyhash]_.
|
||||
|
||||
The following algorithm standardized in [#NIST-SP-800-38G]_ is used:
|
||||
|
||||
- :math:`\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)` refers to the FF1 encryption algorithm
|
||||
using AES with a 256-bit :math:`key`, and parameters :math:`radix = 2,`:math:`minlen = 88,`:math:`maxlen = 88`.
|
||||
It will be used only with the empty string :math:`\texttt{“”}` as the :math:`tweak`. :math:`x` is a
|
||||
sequence of 88 bits, as is the output.
|
||||
|
||||
We also define the following conversion function:
|
||||
|
||||
- :math:`\mathsf{I2LEOSP}_\ell(k)` is the byte sequence :math:`S` of length :math:`\ell/8` representing in
|
||||
little-endian order the integer :math:`k` in range :math:`\{ 0\,.\!. 2^\ell - 1 \}`. It is the reverse
|
||||
operation of :math:`\mathsf{LEOS2IP}_\ell(S)`.
|
||||
|
||||
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.
|
||||
|
||||
We adapt the path notation of BIP 32 [#bip-0032]_ to describe shielded HD paths, using prime marks (:math:`'`) to
|
||||
indicate hardened derivation (:math:`i' = i + 2^{31}`) as in BIP 44 [#bip-0044]_:
|
||||
|
||||
- :math:`\mathsf{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)` is written as :math:`m_\mathsf{Sapling} / a / b / c`.
|
||||
|
||||
|
||||
Specification: Sapling key derivation
|
||||
=====================================
|
||||
|
||||
Sapling extended keys
|
||||
---------------------
|
||||
|
||||
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:
|
||||
|
||||
- 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).
|
||||
|
||||
- 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.
|
||||
|
||||
We represent a Sapling extended spending key as :math:`(\mathsf{ask, nsk, ovk, dk, c})`, where
|
||||
:math:`(\mathsf{ask, nsk, ovk})` is the normal Sapling expanded spending key, :math:`\mathsf{dk}` is a
|
||||
diversifier key, and :math:`\mathsf{c}` is the chain code.
|
||||
|
||||
We represent a Sapling extended full viewing key as :math:`(\mathsf{ak, nk, ovk, dk, c})`, where
|
||||
:math:`(\mathsf{ak, nk, ovk})` is the normal Sapling full viewing key, :math:`\mathsf{dk}` is the same
|
||||
diversifier key as above, and :math:`\mathsf{c}` is the chain code.
|
||||
|
||||
Sapling helper functions
|
||||
------------------------
|
||||
|
||||
Define
|
||||
|
||||
* :math:`\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk}) :=`:math:`\mathsf{I2LEOSP}_{256}(\mathsf{ask})`:math:`||\,\mathsf{I2LEOSP}_{256}(\mathsf{nsk})`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}`
|
||||
* :math:`\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=`:math:`\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))`:math:`||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}`
|
||||
|
||||
Sapling master key generation
|
||||
-----------------------------
|
||||
|
||||
Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
|
||||
|
||||
- Calculate :math:`I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Sapling”}, S)`.
|
||||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`, and :math:`I_R` as the master chain code
|
||||
:math:`\mathsf{c}_m`.
|
||||
- Calculate :math:`\mathsf{ask}_m`, :math:`\mathsf{nsk}_m`, and :math:`\mathsf{ovk}_m` via the standard
|
||||
Sapling derivation [#protocol-saplingkeycomponents]_:
|
||||
|
||||
- :math:`\mathsf{ask}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))`
|
||||
- :math:`\mathsf{nsk}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x01}]))`
|
||||
- :math:`\mathsf{ovk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x02}]))`.
|
||||
|
||||
- Calculate :math:`\mathsf{dk}_m` similarly:
|
||||
|
||||
- :math:`\mathsf{dk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x10}]))`.
|
||||
|
||||
- Return :math:`(\mathsf{ask}_m, \mathsf{nsk}_m, \mathsf{ovk}_m, \mathsf{dk}_m, \mathsf{c}_m)` as the
|
||||
master extended spending key :math:`m_\mathsf{Sapling}`.
|
||||
|
||||
Note that the master extended key is invalid if :math:`\mathsf{ask}_m` is :math:`0`, or if the corresponding
|
||||
:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
|
||||
|
||||
Sapling child key derivation
|
||||
----------------------------
|
||||
|
||||
As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index :math:`i`,
|
||||
depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.
|
||||
|
||||
Deriving a child extended spending key
|
||||
``````````````````````````````````````
|
||||
|
||||
:math:`\mathsf{CDKsk}((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{ask}_i, \mathsf{nsk}_i, \mathsf{ovk}_i, \mathsf{dk}_i, \mathsf{c}_i)`
|
||||
|
||||
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
|
||||
|
||||
- If so (hardened child):
|
||||
let :math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x11}]`:math:`||\,\mathsf{EncodeExtSKParts}(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`.
|
||||
- If not (normal child):
|
||||
let :math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]`:math:`||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`
|
||||
where :math:`(\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})` is the full viewing key derived from
|
||||
:math:`(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})` as described in [#protocol-saplingkeycomponents]_.
|
||||
|
||||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Let :math:`I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))`.
|
||||
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))`.
|
||||
- Return:
|
||||
|
||||
- :math:`\mathsf{ask}_i = (I_\mathsf{ask} + \mathsf{ask}_{par}) \pmod{r_\mathbb{J}}`
|
||||
- :math:`\mathsf{nsk}_i = (I_\mathsf{nsk} + \mathsf{nsk}_{par}) \pmod{r_\mathbb{J}}`
|
||||
- :math:`\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]`:math:`||\,\mathsf{ovk}_{par}))`
|
||||
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
|
||||
- :math:`\mathsf{c}_i = I_R`.
|
||||
|
||||
Note that the child extended key is invalid if :math:`\mathsf{ask}_i` is :math:`0`, or if the corresponding
|
||||
:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
|
||||
|
||||
Deriving a child extended full viewing key
|
||||
``````````````````````````````````````````
|
||||
|
||||
Let :math:`\mathcal{G}^\mathsf{Sapling}` be as defined in [#protocol-concretespendauthsig]_ and
|
||||
let :math:`\mathcal{H}^\mathsf{Sapling}` be as defined in [#protocol-saplingkeycomponents]_.
|
||||
|
||||
:math:`\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})`
|
||||
|
||||
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
|
||||
|
||||
- If so (hardened child): return failure.
|
||||
- If not (normal child): let
|
||||
:math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]`:math:`||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`.
|
||||
|
||||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Let :math:`I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))`.
|
||||
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))`.
|
||||
- Return:
|
||||
|
||||
- :math:`\mathsf{ak}_i = [I_\mathsf{ask}]\,\mathcal{G}^\mathsf{Sapling} + \mathsf{ak}_{par}`
|
||||
- :math:`\mathsf{nk}_i = [I_\mathsf{nsk}]\,\mathcal{H}^\mathsf{Sapling} + \mathsf{nk}_{par}`
|
||||
- :math:`\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]`:math:`||\,\mathsf{ovk}_{par}))`
|
||||
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
|
||||
- :math:`\mathsf{c}_i = I_R`.
|
||||
|
||||
Note that the child extended key is invalid if :math:`\mathsf{ak}_i` is the zero point of Jubjub,
|
||||
or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
|
||||
is :math:`0`.
|
||||
|
||||
Sapling internal key derivation
|
||||
-------------------------------
|
||||
|
||||
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 [#bip-0044]_, 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.
|
||||
|
||||
Deriving a Sapling internal spending key
|
||||
````````````````````````````````````````
|
||||
|
||||
Let :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})` be the external spending key.
|
||||
|
||||
- Derive the corresponding :math:`\mathsf{ak}` and :math:`\mathsf{nk}` as specified in [#protocol-saplingkeycomponents]_.
|
||||
- Let :math:`I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))`.
|
||||
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))`.
|
||||
- Let :math:`R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])`.
|
||||
- Let :math:`\mathsf{nsk_{internal}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}`.
|
||||
- Split :math:`R` into two 32-byte sequences, :math:`\mathsf{dk_{internal}}` and :math:`\mathsf{ovk_{internal}}`.
|
||||
- Return the internal spending key as :math:`(\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})`.
|
||||
|
||||
Note that the child extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
|
||||
or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
|
||||
is :math:`0`.
|
||||
|
||||
Deriving a Sapling internal full viewing key
|
||||
````````````````````````````````````````````
|
||||
|
||||
Let :math:`\mathcal{H}^\mathsf{Sapling}` be as defined in [#protocol-saplingkeycomponents]_.
|
||||
|
||||
Let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})` be the external full viewing key.
|
||||
|
||||
- Let :math:`I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))`.
|
||||
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))`.
|
||||
- Let :math:`R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])`.
|
||||
- Let :math:`\mathsf{nk_{internal}} = [I_\mathsf{nsk}] \mathcal{H}^\mathsf{Sapling} + \mathsf{nk}`.
|
||||
- Split :math:`R` into two 32-byte sequences, :math:`\mathsf{dk_{internal}}` and :math:`\mathsf{ovk_{internal}}`.
|
||||
- Return the internal full viewing key as :math:`(\mathsf{ak}, \mathsf{nk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})`.
|
||||
|
||||
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 :math:`\mathsf{ak}`) as the
|
||||
original, but viewing authority only for internal transfers.
|
||||
|
||||
The values of :math:`I`, :math:`I_\mathsf{nsk}`, and :math:`R` 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:
|
||||
|
||||
.. figure:: zip-0032-sapling-internal-key-derivation.png
|
||||
:width: 900px
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Diagram of Sapling internal key derivation
|
||||
|
||||
(For simplicity, the proof authorizing key is not shown.)
|
||||
|
||||
This method of deriving internal keys is applied to external keys that are children of the
|
||||
Account level. It was implemented in `zcashd` as part of support for ZIP 316 [#zip-0316]_.
|
||||
|
||||
Note that the internal extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
|
||||
or if the corresponding :math:`\mathsf{ivk_{internal}}` derived from the internal full viewing key
|
||||
as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
|
||||
|
||||
|
||||
Sapling diversifier derivation
|
||||
------------------------------
|
||||
|
||||
The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key :math:`\mathsf{dk}`.
|
||||
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:
|
||||
|
||||
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
|
||||
- :math:`d_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.
|
||||
|
||||
A valid diversifier :math:`d_j` is one for which :math:`\mathsf{DiversifyHash^{Sapling}}(d_j) \neq \bot`.
|
||||
For a given :math:`\mathsf{dk}`, approximately half of the possible values of :math:`j` yield valid
|
||||
diversifiers.
|
||||
|
||||
The default diversifier for a Sapling extended key is defined to be :math:`d_j`, where :math:`j` is the
|
||||
least nonnegative integer yielding a valid diversifier.
|
||||
|
||||
|
||||
Specification: Orchard key derivation
|
||||
=====================================
|
||||
|
||||
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.
|
||||
|
||||
Orchard extended keys
|
||||
---------------------
|
||||
|
||||
We represent an Orchard extended spending key as :math:`(\mathsf{sk, c}),` where :math:`\mathsf{sk}`
|
||||
is the normal Orchard spending key (opaque 32 bytes), and :math:`\mathsf{c}` is the chain code.
|
||||
|
||||
Orchard master key generation
|
||||
-----------------------------
|
||||
|
||||
Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
|
||||
|
||||
- Calculate :math:`I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Orchard”}, S)`.
|
||||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`.
|
||||
- Use :math:`I_R` as the master chain code :math:`\mathsf{c}_m`.
|
||||
- Return :math:`(\mathsf{sk}_m, \mathsf{c}_m)` as the master extended spending key
|
||||
:math:`m_\mathsf{Orchard}`.
|
||||
|
||||
Orchard child key derivation
|
||||
----------------------------
|
||||
|
||||
:math:`\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)`
|
||||
|
||||
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
|
||||
|
||||
- If so (hardened child): let
|
||||
:math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i))`.
|
||||
- If not (normal child): return failure.
|
||||
|
||||
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
|
||||
- Use :math:`I_L` as the child spending key :math:`\mathsf{sk}_{i}`.
|
||||
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
|
||||
|
||||
Note that the resulting child spending key may produce an invalid external FVK, as specified
|
||||
in [#protocol-orchardkeycomponents]_, with small probability. The corresponding internal FVK
|
||||
derived as specified in the next section may also be invalid with small probability.
|
||||
|
||||
Orchard internal key derivation
|
||||
-------------------------------
|
||||
|
||||
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.
|
||||
|
||||
Let :math:`\mathsf{ask}` be the spend authorizing key if available, and
|
||||
let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})` be the corresponding external full
|
||||
viewing key, obtained as specified in [#protocol-orchardkeycomponents]_.
|
||||
|
||||
Define :math:`\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})`
|
||||
as follows:
|
||||
|
||||
- Let :math:`K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})`.
|
||||
- Let :math:`\mathsf{rivk_{internal}} = \mathsf{ToScalar^{Orchard}}(\mathsf{PRF^{expand}}(K, [\mathtt{0x83}] \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{ak}) \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{nk}))`.
|
||||
- Return :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk_{internal}})`.
|
||||
|
||||
The result of applying :math:`\mathsf{DeriveInternalFVK^{Orchard}}` to the external full viewing
|
||||
key is the internal full viewing key. The corresponding expanded internal spending key is
|
||||
:math:`(\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})`,
|
||||
|
||||
Unlike `Sapling internal key derivation`_, 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 :math:`\mathsf{rivk_{internal}}`
|
||||
field relative to the external full viewing key, which results in different
|
||||
:math:`\mathsf{dk_{internal}}`, :math:`\mathsf{ivk_{internal}}` and :math:`\mathsf{ovk_{internal}}`
|
||||
fields being derived, as specified in [#protocol-orchardkeycomponents]_ and shown in the following
|
||||
diagram:
|
||||
|
||||
.. figure:: zip-0032-orchard-internal-key-derivation.png
|
||||
:width: 720px
|
||||
:align: center
|
||||
:figclass: align-center
|
||||
|
||||
Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key
|
||||
|
||||
This method of deriving internal keys is applied to external keys that are children of the
|
||||
Account level. It was implemented in `zcashd` as part of support for ZIP 316 [#zip-0316]_.
|
||||
|
||||
Note that the resulting FVK may be invalid, as specified in [#protocol-orchardkeycomponents]_.
|
||||
|
||||
Orchard diversifier derivation
|
||||
------------------------------
|
||||
|
||||
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.
|
||||
|
||||
Given an Orchard extended spending key :math:`(\mathsf{sk}_i, \mathsf{c}_i)`:
|
||||
|
||||
- Let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})` be the Orchard full viewing key for :math:`\mathsf{sk}_i`.
|
||||
- Let :math:`K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})` and let :math:`B = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})`.
|
||||
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(K, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(B)))`.
|
||||
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
|
||||
- :math:`d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.
|
||||
|
||||
Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of :math:`j` yield
|
||||
valid diversifiers.
|
||||
|
||||
The default diversifier for :math:`(\mathsf{sk}_i, \mathsf{c}_i)` is defined to be :math:`d_{i,0}.`
|
||||
|
||||
|
||||
Specification: Wallet usage
|
||||
===========================
|
||||
|
||||
Existing Zcash-supporting HD wallets all use BIP 44 [#bip-0044]_ 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.
|
||||
|
||||
Key path levels
|
||||
---------------
|
||||
|
||||
Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened
|
||||
derivation:
|
||||
|
||||
- :math:`purpose`: a constant set to :math:`32'` (or :math:`\texttt{0x80000020}`) following the BIP 43
|
||||
recommendation. It indicates that the subtree of this node is used according to this specification.
|
||||
|
||||
- :math:`coin\_type`: 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
|
||||
[#slip-0044]_. Note that in keeping with that document, all cryptocurrency testnets share :math:`coin\_type`
|
||||
index :math:`1`.
|
||||
|
||||
- :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in
|
||||
BIP 44 [#bip-0044]_.
|
||||
|
||||
Unlike BIP 44, none of the shielded key paths have a :math:`change` 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.
|
||||
|
||||
Sapling key path
|
||||
----------------
|
||||
|
||||
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.
|
||||
|
||||
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 :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
|
||||
|
||||
* :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account'`.
|
||||
|
||||
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.
|
||||
|
||||
Note that a given account can have a maximum of approximately :math:`2^{87}` payment addresses, because each
|
||||
diversifier has around a 50% chance of being invalid.
|
||||
|
||||
If in certain circumstances a wallet needs to derive independent spend authorities within a single account,
|
||||
they MAY additionally support a non-hardened :math:`address\_index` path level as in [#bip-0044]_:
|
||||
|
||||
* :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index`.
|
||||
|
||||
`zcashd` version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase
|
||||
under account :math:`\mathtt{0x7FFFFFFF}`, using hardened derivation for :math:`address\_index`.
|
||||
|
||||
Orchard key path
|
||||
----------------
|
||||
|
||||
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.
|
||||
|
||||
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 :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
|
||||
|
||||
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`.
|
||||
|
||||
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.
|
||||
|
||||
Note that a given account can have a maximum of :math:`2^{88}` payment addresses (unlike Sapling, all Orchard
|
||||
diversifiers are valid).
|
||||
|
||||
|
||||
Specification: Fingerprints and Tags
|
||||
====================================
|
||||
|
||||
Sapling Full Viewing Key Fingerprints and Tags
|
||||
----------------------------------------------
|
||||
|
||||
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding :math:`\mathit{FVK}` (as specified
|
||||
in [#protocol-saplingfullviewingkeyencoding]_) is given by:
|
||||
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})`.
|
||||
|
||||
It MAY be used to uniquely identify a particular Sapling full viewing key.
|
||||
|
||||
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.
|
||||
|
||||
Orchard Full Viewing Key Fingerprints and Tags
|
||||
----------------------------------------------
|
||||
|
||||
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding :math:`\mathit{FVK}` (as
|
||||
specified in [#protocol-orchardfullviewingkeyencoding]_) is given by:
|
||||
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})`.
|
||||
|
||||
It MAY be used to uniquely identify a particular Orchard full viewing key.
|
||||
|
||||
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.
|
||||
|
||||
Seed Fingerprints
|
||||
-----------------
|
||||
|
||||
A "seed fingerprint" for the master seed :math:`S` of a hierarchical deterministic wallet is given by:
|
||||
|
||||
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_HD_Seed_FP”},`:math:`[\mathsf{length}(S)]\,||\,S)`.
|
||||
|
||||
It MAY be used to uniquely identify a particular hierarchical deterministic wallet.
|
||||
|
||||
No corresponding short tag is defined.
|
||||
|
||||
Note: a previous version of this specification did not have the length byte prefixing the seed.
|
||||
The current specification reflects the implementation in `zcashd`.
|
||||
|
||||
|
||||
Specification: Key Encodings
|
||||
============================
|
||||
|
||||
The following encodings are analogous to the ``xprv`` and ``xpub`` encodings defined
|
||||
in BIP 32 for transparent keys and addresses. Each key type has a raw representation
|
||||
and a Bech32 [#bip-0173]_ encoding.
|
||||
|
||||
|
||||
Sapling extended spending keys
|
||||
------------------------------
|
||||
|
||||
A Sapling extended spending key :math:`(\mathsf{ask, nsk, ovk, dk, c})`, at depth :math:`depth`,
|
||||
with parent full viewing key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is
|
||||
represented as a byte sequence:
|
||||
|
||||
* :math:`\mathsf{I2LEOSP}_{8}(depth)`:math:`||\,parent\_fvk\_tag`:math:`||\,\mathsf{I2LEOSP}_{32}(i)`:math:`||\,\mathsf{c}`:math:`||\,\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk})`.
|
||||
|
||||
For the master extended spending key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag` is
|
||||
4 zero bytes, and :math:`i` is :math:`0`.
|
||||
|
||||
When encoded as Bech32, the Human-Readable Part is ``secret-extended-key-main``
|
||||
for the production network, or ``secret-extended-key-test`` for the test network.
|
||||
|
||||
Sapling extended full viewing keys
|
||||
----------------------------------
|
||||
|
||||
A Sapling extended full viewing key :math:`(\mathsf{ak, nk, ovk, dk, c})`, at depth :math:`depth`,
|
||||
with parent full viewing key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is
|
||||
represented as a byte sequence:
|
||||
|
||||
* :math:`\mathsf{I2LEOSP}_{8}(depth)`:math:`||\,parent\_fvk\_tag`:math:`||\,\mathsf{I2LEOSP}_{32}(i)`:math:`||\,\mathsf{c}`:math:`||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk})`.
|
||||
|
||||
For the master extended full viewing key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag`
|
||||
is 4 zero bytes, and :math:`i` is :math:`0`.
|
||||
|
||||
When encoded as Bech32, the Human-Readable Part is ``zxviews`` for the production
|
||||
network, or ``zxviewtestsapling`` for the test network.
|
||||
|
||||
Orchard extended spending keys
|
||||
------------------------------
|
||||
|
||||
An Orchard extended spending key :math:`(\mathsf{sk, c})`, at depth :math:`depth`, with parent full viewing
|
||||
key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is represented as a byte sequence:
|
||||
|
||||
* :math:`\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}`.
|
||||
|
||||
For the master extended spending key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag` is
|
||||
4 zero bytes, and :math:`i` is :math:`0`.
|
||||
|
||||
When encoded as Bech32, the Human-Readable Part is ``secret-orchard-extsk-main``
|
||||
for Mainnet, or ``secret-orchard-extsk-test`` for Testnet.
|
||||
|
||||
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 [#protocol-orchardspendingkeyencoding]_.
|
||||
|
||||
|
||||
Values reserved due to previous specification for Sprout
|
||||
========================================================
|
||||
|
||||
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:
|
||||
|
||||
* the :math:`\mathsf{BLAKE2b}\text{-}\mathsf{512}` personalization :math:`\texttt{“ZcashIP32_Sprout”}`,
|
||||
formerly specified for derivation of the master key of the Sprout tree;
|
||||
* the :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}` personalization :math:`\texttt{“Zcash_Sprout_AFP”}`,
|
||||
formerly specified for generation of Sprout address fingerprints;
|
||||
* the :math:`\mathsf{PRF^{expand}}` prefix :math:`\texttt{0x80}`, formerly specified for
|
||||
Sprout child key derivation;
|
||||
* the Bech32 Human-Readable Parts ``zxsprout`` and ``zxtestsprout``, formerly specified for
|
||||
Sprout extended spending keys on Mainnet and Testnet respectively.
|
||||
|
||||
|
||||
Test Vectors
|
||||
============
|
||||
|
||||
TBC
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
* https://github.com/zcash-hackworks/zip32
|
||||
* https://github.com/zcash/librustzcash/pull/29
|
||||
* https://github.com/zcash/zcash/pull/3447
|
||||
* https://github.com/zcash/zcash/pull/3492
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#bip-0032] `BIP 32: Hierarchical Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>`_
|
||||
.. [#bip-0039] `BIP 39: Mnemonic code for generating deterministic keys <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>`_
|
||||
.. [#bip-0043] `BIP 43: Purpose Field for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>`_
|
||||
.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
|
||||
.. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
|
||||
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
|
||||
.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.rst>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal] <protocol/protocol.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2022.2.19. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
|
||||
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
|
||||
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2022.2.19. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions <protocol/protocol.pdf#concretediversifyhash>`_
|
||||
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.2.19. Section 5.4.6.1: Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
|
||||
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2022.2.19. Section 5.4.9.3: Jubjub <protocol/protocol.pdf#jubjub>`_
|
||||
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.2.1: Sprout Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
|
||||
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.2.3: Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
|
||||
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.3: Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
|
||||
.. [#protocol-saplingspendingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.4: Sapling Spending Keys <protocol/protocol.pdf#saplingspendingkeyencoding>`_
|
||||
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys <protocol/protocol.pdf#orchardfullviewingkeyencoding>`_
|
||||
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.5: Orchard Spending Keys <protocol/protocol.pdf#orchardspendingkeyencoding>`_
|
||||
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_
|
|
@ -0,0 +1,18 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 76: Transaction Signature Validation before Overwinter</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 76
|
||||
Title: Transaction Signature Validation before Overwinter
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Consensus
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/130">https://github.com/zcash/zips/issues/130</a>></pre>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,9 @@
|
|||
::
|
||||
|
||||
ZIP: 76
|
||||
Title: Transaction Signature Validation before Overwinter
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Reserved
|
||||
Category: Consensus
|
||||
Discussions-To: <https://github.com/zcash/zips/issues/130>
|
106
zip-0143.rst
|
@ -0,0 +1,287 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 155: addrv2 message</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 155
|
||||
Title: addrv2 message
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Wladimir J. van der Laan
|
||||
Zancas Wilcox
|
||||
Status: Proposed
|
||||
Category: Network
|
||||
Created: 2021-08-13
|
||||
License: BSD-2-Clause
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/542">https://github.com/zcash/zips/issues/542</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/543">https://github.com/zcash/zips/pull/543</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 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>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></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">2</a>.</p>
|
||||
<p>"P2P network" means the Zcash peer-to-peer network.</p>
|
||||
<p><code>uint8</code>, <code>uint16</code>, and <code>uint32</code> denote unsigned integer data types of the corresponding length (8, 16, or 32 bits respectively).</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 document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current <code>addr</code> message.</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>Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy <a id="id4" class="footnote_reference" href="#tor-rendezvous-v3">9</a>. These services have 256-bit addresses and thus do not fit in the existing <code>addr</code> message (unchanged from Bitcoin <a id="id5" class="footnote_reference" href="#bitcoin-addr-message">7</a>), which encapsulates onion addresses in OnionCat IPv6 addresses.</p>
|
||||
<p>Other transport-layer protocols such as I2P have always used longer addresses. This change would make it possible to gossip such addresses over the P2P network, so that other peers can connect to them.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The <code>addrv2</code> message is defined as a message where the <code>command</code> field is (NUL-padded) <code>"addrv2"</code>. It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format described in <a id="id6" class="footnote_reference" href="#bitcoin-addr-message">7</a>, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to <a id="id7" class="footnote_reference" href="#bitcoin-compactsize">8</a>.</p>
|
||||
<p>This means that the message contains a serialized vector of the following structure:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Bytes</td>
|
||||
<td>Name</td>
|
||||
<td>Data Type</td>
|
||||
<td>Description</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>4</td>
|
||||
<td><code>time</code></td>
|
||||
<td><code>uint32</code></td>
|
||||
<td>Time that this node was last seen as connected to the network. A time in Unix epoch time format.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>varies</code></td>
|
||||
<td><code>services</code></td>
|
||||
<td><code>CompactSize</code></td>
|
||||
<td>Service bits. A CompactSize-encoded bit field that is 64 bits wide.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td><code>networkID</code></td>
|
||||
<td><code>uint8</code></td>
|
||||
<td>Network identifier. An 8-bit value that specifies which network is addressed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>varies</code></td>
|
||||
<td><code>sizeAddr</code></td>
|
||||
<td><code>CompactSize</code></td>
|
||||
<td>The length in bytes of <code>addr</code>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>sizeAddr</code></td>
|
||||
<td><code>addr</code></td>
|
||||
<td><code>uint8[sizeAddr]</code></td>
|
||||
<td>Network address. The interpretation depends on networkID.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>2</td>
|
||||
<td><code>port</code></td>
|
||||
<td><code>uint16</code></td>
|
||||
<td>Network port. If not relevant for the network this MUST be 0.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p>One message can contain up to 1,000 addresses. Clients MUST reject messages with more addresses.</p>
|
||||
<p>Field <code>addr</code> has a variable length, with a maximum of 512 bytes (4096 bits). Clients MUST reject messages with a longer <code>addr</code> field, irrespective of the network ID.</p>
|
||||
<p>The list of reserved network IDs is as follows:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Network ID</td>
|
||||
<td>Enumeration</td>
|
||||
<td>Address length (bytes)</td>
|
||||
<td>Description</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0x01</code></td>
|
||||
<td><code>IPV4</code></td>
|
||||
<td>4</td>
|
||||
<td>IPv4 address (globally routed internet)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0x02</code></td>
|
||||
<td><code>IPV6</code></td>
|
||||
<td>16</td>
|
||||
<td>IPv6 address (globally routed internet)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0x04</code></td>
|
||||
<td><code>TORV3</code></td>
|
||||
<td>32</td>
|
||||
<td>Tor v3 onion service address</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0x05</code></td>
|
||||
<td><code>I2P</code></td>
|
||||
<td>32</td>
|
||||
<td>I2P overlay network address</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0x06</code></td>
|
||||
<td><code>CJDNS</code></td>
|
||||
<td>16</td>
|
||||
<td>Cjdns overlay network address</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="id8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
|
||||
<p>Clients SHOULD gossip valid, potentially routable addresses from all known networks, even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.</p>
|
||||
<p>Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.</p>
|
||||
<p>Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.</p>
|
||||
<section id="network-address-encodings"><h3><span class="section-heading">Network address encodings</span><span class="section-anchor"> <a rel="bookmark" href="#network-address-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The <code>IPV4</code> and <code>IPV6</code> network IDs use addresses encoded in the usual way for binary IPv4 and IPv6 addresses in network byte order (big endian).</p>
|
||||
<section id="tor-v3-address-encoding"><h4><span class="section-heading">Tor v3 address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#tor-v3-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>According to the spec <a id="id9" class="footnote_reference" href="#tor-rendezvous-v3">9</a>, version 3 <code>.onion</code> addresses are encoded as follows:</p>
|
||||
<pre>onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion"
|
||||
CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
|
||||
<p>where:</p>
|
||||
<ul>
|
||||
<li><code>PUBKEY</code> is the 32-byte Ed25519 master pubkey of the onion service;</li>
|
||||
<li><code>VERSION</code> is a one-byte version field (default value <code>0x03</code>);</li>
|
||||
<li><code>".onion"</code> and <code>".onion checksum"</code> are constant strings;</li>
|
||||
<li><code>CHECKSUM</code> is truncated to two bytes before inserting it in <code>onion_address</code>;</li>
|
||||
<li><code>H()</code> is the SHA3-256 cryptographic hash function. <a id="id10" class="footnote_reference" href="#nist-sha3">10</a></li>
|
||||
</ul>
|
||||
<p>Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte <code>PUBKEY</code> part in the <code>addr</code> field. As <code>VERSION</code> will always be 0x03 in the case of v3 addresses, this is enough to reconstruct the onion address.</p>
|
||||
</section>
|
||||
<section id="i2p-address-encoding"><h4><span class="section-heading">I2P address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#i2p-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Like Tor, I2P naming uses a base32-encoded address format <a id="id11" class="footnote_reference" href="#i2p-naming">11</a>.</p>
|
||||
<p>I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>. The base32 encoding does not include <code>"="</code> padding characters.</p>
|
||||
<p>I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field.</p>
|
||||
</section>
|
||||
<section id="cjdns-address-encoding"><h4><span class="section-heading">Cjdns address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#cjdns-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range <a id="id12" class="footnote_reference" href="#cjdns-whitepaper">12</a>. They MUST be sent with the <code>CJDNS</code> network ID. They are encoded in network byte order (big endian) as for the <code>IPV6</code> network ID.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>TODO: change ${PLACEHOLDER} to a specific peer protocol version.</p>
|
||||
<p>Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="id13" class="footnote_reference" href="#zip-0252">6</a>.</p>
|
||||
<p>Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MUST NOT send <code>addrv2</code> messages on that connection.</p>
|
||||
<p>A node that has negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MAY still send <code>addr</code> messages on the connection, and MUST handle received <code>addr</code> messages as it would have done prior to this ZIP.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is closely based on BIP 155 <a id="id14" class="footnote_reference" href="#bip-0155">3</a>, with the following changes:</p>
|
||||
<ul>
|
||||
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of ${PLACEHOLDER} or higher, not by sending a <code>sendaddrv2</code> message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example the <code>MSG_WTX</code> inv type defined in ZIP 239 <a id="id15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
|
||||
<li>No Network ID for Tor v2 onion addresses: the Tor network is expected to have removed support for these addresses in the timeframe for deployment of this ZIP.</li>
|
||||
<li>Clients MUST, rather than SHOULD, reject <code>addrv2</code> messages with more than 1,000 addresses. Making this a consistent requirement promotes interoperability.</li>
|
||||
<li>Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks.</li>
|
||||
<li>Clients MUST, rather than SHOULD, reject messages that contain addresses that have a different length than specified for a known network ID, or a length greater than the 512-byte maximum for an unknown network ID.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBD.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is closely based on BIP 155 <a id="id16" class="footnote_reference" href="#bip-0155">3</a>, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.</p>
|
||||
<p>Acknowledgements for BIP 155:</p>
|
||||
<ul>
|
||||
<li>Jonas Schnelli: change <code>services</code> field to <code>CompactSize</code>, to make the message more compact in the likely case instead of always using 8 bytes.</li>
|
||||
<li>Gregory Maxwell: various suggestions regarding extensibility.</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="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0155" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki">BIP 155: addrv2 message</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0239" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0239">ZIP 239: Relay of Version 5 Transactions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0252" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bitcoin-addr-message" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#addr">Protocol documentation: addr. Bitcoin Wiki</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bitcoin-compactsize" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer">Variable length integer. Bitcoin Wiki</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="tor-rendezvous-v3" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt">Tor Rendezvous Specification - Version 3</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="nist-sha3" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="https://csrc.nist.gov/publications/detail/fips/202/final">NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="i2p-naming" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="https://geti2p.net/en/docs/naming#base32">I2P: Naming and address book</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="cjdns-whitepaper" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="https://github.com/cjdelisle/cjdns/blob/f909b960709a4e06730ddd4d221e5df38164dbb6/doc/Whitepaper.md#user-content-pulling-it-all-together">Cjdns whitepaper: Pulling It All Together</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,251 @@
|
|||
::
|
||||
|
||||
ZIP: 155
|
||||
Title: addrv2 message
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Wladimir J. van der Laan
|
||||
Zancas Wilcox
|
||||
Status: Proposed
|
||||
Category: Network
|
||||
Created: 2021-08-13
|
||||
License: BSD-2-Clause
|
||||
Discussions-To: <https://github.com/zcash/zips/issues/542>
|
||||
Pull-Request: <https://github.com/zcash/zips/pull/543>
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
|
||||
document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as described in
|
||||
ZIP 200. [#zip-0200]_
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||
|
||||
"P2P network" means the Zcash peer-to-peer network.
|
||||
|
||||
``uint8``, ``uint16``, and ``uint32`` denote unsigned integer data types of the
|
||||
corresponding length (8, 16, or 32 bits respectively).
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This document proposes a new P2P message to gossip longer node addresses over the
|
||||
P2P network. This is required to support new-generation onion addresses, I2P, and
|
||||
potentially other networks that have longer endpoint addresses than fit in the 128
|
||||
bits of the current ``addr`` message.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9.
|
||||
They have various advantages compared to the old v2 onion services, among which better
|
||||
encryption and privacy [#Tor-rendezvous-v3]_. These services have 256-bit addresses
|
||||
and thus do not fit in the existing ``addr`` message (unchanged from Bitcoin
|
||||
[#Bitcoin-addr-message]_), which encapsulates onion addresses in OnionCat IPv6 addresses.
|
||||
|
||||
Other transport-layer protocols such as I2P have always used longer addresses. This
|
||||
change would make it possible to gossip such addresses over the P2P network, so that
|
||||
other peers can connect to them.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
The ``addrv2`` message is defined as a message where the ``command`` field is
|
||||
(NUL-padded) ``"addrv2"``. It is serialized in the standard encoding for P2P messages.
|
||||
Its format is similar to the current ``addr`` message format described in
|
||||
[#Bitcoin-addr-message]_, with the difference that the fixed 16-byte IP address is
|
||||
replaced by a network ID and a variable-length address, and the services format
|
||||
has been changed to [#Bitcoin-CompactSize]_.
|
||||
|
||||
This means that the message contains a serialized vector of the following structure:
|
||||
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
| Bytes | Name | Data Type | Description |
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
| 4 | ``time`` | ``uint32`` | Time that this node was last seen as connected to the network. |
|
||||
| | | | A time in Unix epoch time format. |
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
| ``varies`` | ``services`` | ``CompactSize`` | Service bits. A CompactSize-encoded bit field that is 64 bits |
|
||||
| | | | wide. |
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
| 1 | ``networkID`` | ``uint8`` | Network identifier. An 8-bit value that specifies which |
|
||||
| | | | network is addressed. |
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
| ``varies`` | ``sizeAddr`` | ``CompactSize`` | The length in bytes of ``addr``. |
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
| ``sizeAddr`` | ``addr`` | ``uint8[sizeAddr]`` | Network address. The interpretation depends on networkID. |
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
| 2 | ``port`` | ``uint16`` | Network port. If not relevant for the network this MUST be 0. |
|
||||
+--------------+-----------------+---------------------+----------------------------------------------------------------+
|
||||
|
||||
One message can contain up to 1,000 addresses. Clients MUST reject messages with
|
||||
more addresses.
|
||||
|
||||
Field ``addr`` has a variable length, with a maximum of 512 bytes (4096 bits). Clients
|
||||
MUST reject messages with a longer ``addr`` field, irrespective of the network ID.
|
||||
|
||||
The list of reserved network IDs is as follows:
|
||||
|
||||
+------------+-------------+------------------------+-----------------------------------------+
|
||||
| Network ID | Enumeration | Address length (bytes) | Description |
|
||||
+------------+-------------+------------------------+-----------------------------------------+
|
||||
| ``0x01`` | ``IPV4`` | 4 | IPv4 address (globally routed internet) |
|
||||
+------------+-------------+------------------------+-----------------------------------------+
|
||||
| ``0x02`` | ``IPV6`` | 16 | IPv6 address (globally routed internet) |
|
||||
+------------+-------------+------------------------+-----------------------------------------+
|
||||
| ``0x04`` | ``TORV3`` | 32 | Tor v3 onion service address |
|
||||
+------------+-------------+------------------------+-----------------------------------------+
|
||||
| ``0x05`` | ``I2P`` | 32 | I2P overlay network address |
|
||||
+------------+-------------+------------------------+-----------------------------------------+
|
||||
| ``0x06`` | ``CJDNS`` | 16 | Cjdns overlay network address |
|
||||
+------------+-------------+------------------------+-----------------------------------------+
|
||||
|
||||
Network ID ``0x03`` is intentionally not assigned. In BIP 155 [#bip-0155]_ it was
|
||||
assigned to Tor v2 onion addresses, but those addresses are no longer supported
|
||||
by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
|
||||
|
||||
Clients SHOULD gossip valid, potentially routable addresses from all known
|
||||
networks, even if they are currently not connected to some of them. That could
|
||||
help multi-homed nodes and make it more difficult for an observer to tell which
|
||||
networks a node is connected to.
|
||||
|
||||
Clients MUST NOT gossip addresses from unknown networks, because they have no means
|
||||
to validate those addresses and so can be tricked to gossip invalid addresses.
|
||||
|
||||
Clients MUST reject messages that contain addresses that have a different length
|
||||
than specified in this table for a specific network ID, as these are meaningless.
|
||||
|
||||
Network address encodings
|
||||
-------------------------
|
||||
|
||||
The ``IPV4`` and ``IPV6`` network IDs use addresses encoded in the usual way for
|
||||
binary IPv4 and IPv6 addresses in network byte order (big endian).
|
||||
|
||||
Tor v3 address encoding
|
||||
'''''''''''''''''''''''
|
||||
|
||||
According to the spec [#Tor-rendezvous-v3]_, version 3 ``.onion`` addresses are
|
||||
encoded as follows::
|
||||
|
||||
onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion"
|
||||
CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes
|
||||
|
||||
where:
|
||||
|
||||
* ``PUBKEY`` is the 32-byte Ed25519 master pubkey of the onion service;
|
||||
* ``VERSION`` is a one-byte version field (default value ``0x03``);
|
||||
* ``".onion"`` and ``".onion checksum"`` are constant strings;
|
||||
* ``CHECKSUM`` is truncated to two bytes before inserting it in ``onion_address``;
|
||||
* ``H()`` is the SHA3-256 cryptographic hash function. [#NIST-SHA3]_
|
||||
|
||||
Tor v3 addresses MUST be sent with the ``TORV3`` network ID, with the 32-byte
|
||||
``PUBKEY`` part in the ``addr`` field. As ``VERSION`` will always be 0x03 in the
|
||||
case of v3 addresses, this is enough to reconstruct the onion address.
|
||||
|
||||
I2P address encoding
|
||||
''''''''''''''''''''
|
||||
|
||||
Like Tor, I2P naming uses a base32-encoded address format [#I2P-naming]_.
|
||||
|
||||
I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by
|
||||
``.b32.i2p``. The base32 encoding does not include ``"="`` padding characters.
|
||||
|
||||
I2P addresses MUST be sent with the ``I2P`` network ID, with the decoded SHA-256 hash
|
||||
as address field.
|
||||
|
||||
Cjdns address encoding
|
||||
''''''''''''''''''''''
|
||||
|
||||
Cjdns addresses are simply IPv6 addresses in the ``fc00::/8`` range
|
||||
[#Cjdns-whitepaper]_. They MUST be sent with the ``CJDNS`` network ID.
|
||||
They are encoded in network byte order (big endian) as for the ``IPV6`` network ID.
|
||||
|
||||
Deployment
|
||||
----------
|
||||
|
||||
TODO: change ${PLACEHOLDER} to a specific peer protocol version.
|
||||
|
||||
Support for this specification is signalled by peer protocol version ${PLACEHOLDER}
|
||||
(on both Testnet and Mainnet). Note that this is the same peer protocol version that
|
||||
signals support for NU5 on Mainnet [#zip-0252]_.
|
||||
|
||||
Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a
|
||||
given connection, MUST NOT send ``addrv2`` messages on that connection.
|
||||
|
||||
A node that has negotiated peer protocol version ${PLACEHOLDER} or higher on a given
|
||||
connection, MAY still send ``addr`` messages on the connection, and MUST handle
|
||||
received ``addr`` messages as it would have done prior to this ZIP.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
This ZIP is closely based on BIP 155 [#bip-0155]_, with the following changes:
|
||||
|
||||
* Deployment: support for the ``addrv2`` message is signalled by advertising a
|
||||
peer protocol version of ${PLACEHOLDER} or higher, not by sending a ``sendaddrv2``
|
||||
message. This is motivated by a desire to avoid an exponential explosion in the
|
||||
space of possible feature configurations in a given peer-to-peer connection. In
|
||||
Zcash, unlike Bitcoin, the space of such configurations is effectively constant no
|
||||
matter how many peer-to-peer protocol changes are made, because nodes that do not
|
||||
support a given peer protocol version will drop off the network over time if they do
|
||||
not support the latest Network Upgrade. The feature configuration for a given
|
||||
connection is also established at version negotiation, and cannot change after that
|
||||
point without reconnecting. Other peer-to-peer protocol changes ported from the
|
||||
Bitcoin peer-to-peer protocol, for example the ``MSG_WTX`` inv type defined in
|
||||
ZIP 239 [#zip-0239]_, have taken the same approach to signalling.
|
||||
|
||||
* No Network ID for Tor v2 onion addresses: the Tor network is expected to have
|
||||
removed support for these addresses in the timeframe for deployment of this ZIP.
|
||||
|
||||
* Clients MUST, rather than SHOULD, reject ``addrv2`` messages with more than 1,000
|
||||
addresses. Making this a consistent requirement promotes interoperability.
|
||||
|
||||
* Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks.
|
||||
|
||||
* Clients MUST, rather than SHOULD, reject messages that contain addresses that have
|
||||
a different length than specified for a known network ID, or a length greater
|
||||
than the 512-byte maximum for an unknown network ID.
|
||||
|
||||
|
||||
Reference implementation
|
||||
========================
|
||||
|
||||
TBD.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
================
|
||||
|
||||
This ZIP is closely based on BIP 155 [#bip-0155]_, written by Wladimir J.
|
||||
van der Laan. Zancas Wilcox ported the implementation for Zcashd.
|
||||
|
||||
Acknowledgements for BIP 155:
|
||||
|
||||
* Jonas Schnelli: change ``services`` field to ``CompactSize``, to make the message
|
||||
more compact in the likely case instead of always using 8 bytes.
|
||||
* Gregory Maxwell: various suggestions regarding extensibility.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#bip-0155] `BIP 155: addrv2 message <https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`_
|
||||
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
|
||||
.. [#Bitcoin-addr-message] `Protocol documentation: addr. Bitcoin Wiki <https://en.bitcoin.it/wiki/Protocol_documentation#addr>`_
|
||||
.. [#Bitcoin-CompactSize] `Variable length integer. Bitcoin Wiki <https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer>`_
|
||||
.. [#Tor-rendezvous-v3] `Tor Rendezvous Specification - Version 3 <https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt>`_
|
||||
.. [#NIST-SHA3] `NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions <https://csrc.nist.gov/publications/detail/fips/202/final>`_
|
||||
.. [#I2P-naming] `I2P: Naming and address book <https://geti2p.net/en/docs/naming#base32>`_
|
||||
.. [#Cjdns-whitepaper] `Cjdns whitepaper: Pulling It All Together <https://github.com/cjdelisle/cjdns/blob/f909b960709a4e06730ddd4d221e5df38164dbb6/doc/Whitepaper.md#user-content-pulling-it-all-together>`_
|
|
@ -0,0 +1,412 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 173: Bech32 Format</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 173
|
||||
Title: Bech32 Format
|
||||
Author: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Pieter Wuille <pieter.wuille@gmail.com>
|
||||
Greg Maxwell <greg@xiph.org>
|
||||
Rusty Russell
|
||||
Mark Friedenbach
|
||||
Status: Final
|
||||
Category: Standards / Wallet
|
||||
Created: 2018-06-13
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205. <a id="id3" class="footnote_reference" href="#zip-0205">5</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 document proposes a checksummed base32 format, "Bech32", and a standard for Sapling addresses and keys using it.</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>Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256 checksum, inherited from Bitcoin. They were part of the original Bitcoin software and their scope was extended in BIP 13 <a id="id4" class="footnote_reference" href="#bip-0013">6</a> for P2SH (Pay-to-Script-Hash) addresses. However, both the character set and the checksum algorithm have limitations:</p>
|
||||
<ul>
|
||||
<li>Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''.</li>
|
||||
<li>The mixed case in Base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud.</li>
|
||||
<li>The double-SHA256 checksum is slow and has no error-detection guarantees.</li>
|
||||
<li>Most of the research on error-detecting codes only applies to character-set sizes that are a <a href="https://en.wikipedia.org/wiki/Prime_power">prime power</a>, which 58 is not.</li>
|
||||
<li>Base58 decoding is complicated and relatively slow.</li>
|
||||
</ul>
|
||||
<p>To address these issues, Bitcoin adopted a new encoding called Bech32 <a id="id5" class="footnote_reference" href="#bip-0173">7</a>, for use with address types added by its Segregated Witness proposal. Zcash does not implement Segregated Witness, but it reuses Bech32 with address and key types introduced by the Sapling network upgrade <a id="id6" class="footnote_reference" href="#zip-0205">5</a>.</p>
|
||||
<p>Since the description of Bech32 in <a id="id7" class="footnote_reference" href="#bip-0173">7</a> is partially entangled with Segregated Witness address formats, we have found it clearer to write this ZIP to specify Bech32 separately. This specification should be read in conjunction with section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol specification <a id="id8" class="footnote_reference" href="#protocol">2</a>, and with ZIP 32 which specifies additional key types for support of shielded hierarchical deterministic wallets <a id="id9" class="footnote_reference" href="#zip-0032">3</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>We describe the general checksummed base32 format called ''Bech32''. Its use for Sapling payment addresses and keys is defined in the Sapling protocol specification <a id="id10" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>A Bech32 string consists of:</p>
|
||||
<ul>
|
||||
<li>The <em>human-readable part</em>, which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications.</li>
|
||||
<li>The <em>separator</em>, which is always "1". In case "1" is allowed inside the human-readable part, the last one in the string is the separator.</li>
|
||||
<li>The <em>data part</em>, which is at least 6 characters long and only consists of alphanumeric characters excluding "1", "b", "i", and "o".</li>
|
||||
</ul>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th>0</th>
|
||||
<th>1</th>
|
||||
<th>2</th>
|
||||
<th>3</th>
|
||||
<th>4</th>
|
||||
<th>5</th>
|
||||
<th>6</th>
|
||||
<th>7</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>+0</td>
|
||||
<td>q</td>
|
||||
<td>p</td>
|
||||
<td>z</td>
|
||||
<td>r</td>
|
||||
<td>y</td>
|
||||
<td>9</td>
|
||||
<td>x</td>
|
||||
<td>8</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>+8</td>
|
||||
<td>g</td>
|
||||
<td>f</td>
|
||||
<td>2</td>
|
||||
<td>t</td>
|
||||
<td>v</td>
|
||||
<td>d</td>
|
||||
<td>w</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>+16</td>
|
||||
<td>s</td>
|
||||
<td>3</td>
|
||||
<td>j</td>
|
||||
<td>n</td>
|
||||
<td>5</td>
|
||||
<td>4</td>
|
||||
<td>k</td>
|
||||
<td>h</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>+24</td>
|
||||
<td>c</td>
|
||||
<td>e</td>
|
||||
<td>6</td>
|
||||
<td>m</td>
|
||||
<td>u</td>
|
||||
<td>a</td>
|
||||
<td>7</td>
|
||||
<td>l</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<section id="checksum"><h3><span class="section-heading">Checksum</span><span class="section-anchor"> <a rel="bookmark" href="#checksum"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The last six characters of the data part form a checksum and contain no information. Valid strings MUST pass the criteria for validity specified by the Python3 code snippet below. The checksum is defined so that the function <code>bech32_verify_checksum</code> returns true when its arguments are:</p>
|
||||
<ul>
|
||||
<li><code>hrp</code>: the human-readable part as a string;</li>
|
||||
<li><code>data</code>: the data part as a list of integers representing the characters after conversion using the table above.</li>
|
||||
</ul>
|
||||
<pre>def bech32_polymod(values):
|
||||
GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
|
||||
chk = 1
|
||||
for v in values:
|
||||
b = (chk >> 25)
|
||||
chk = (chk & 0x1ffffff) << 5 ^ v
|
||||
for i in range(5):
|
||||
chk ^= GEN[i] if ((b >> i) & 1) else 0
|
||||
return chk
|
||||
|
||||
def bech32_hrp_expand(s):
|
||||
return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]
|
||||
|
||||
def bech32_verify_checksum(hrp, data):
|
||||
return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1</pre>
|
||||
<p>This implements a <a href="https://en.wikipedia.org/wiki/BCH_code">BCH code</a>; in the case where the encoded string is at most 90 characters, this code guarantees detection of <em>any error affecting at most 4 characters</em> and has less than a 1 in 10<sup>9</sup> chance of failing to detect more errors. More details about the properties can be found in the Checksum Design section. The human-readable part is processed by first feeding the higher 3 bits of each character's US-ASCII value into the checksum calculation followed by a zero and then the lower 5 bits of each US-ASCII value.</p>
|
||||
<p>To construct a valid checksum given the human-readable part and (non-checksum) values of the data-part characters, the code below can be used:</p>
|
||||
<pre>def bech32_create_checksum(hrp, data):
|
||||
values = bech32_hrp_expand(hrp) + data
|
||||
polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1
|
||||
return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)]</pre>
|
||||
<section id="error-correction"><h4><span class="section-heading">Error correction</span><span class="section-anchor"> <a rel="bookmark" href="#error-correction"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>One of the properties of these BCH codes is that they can be used for error correction. An unfortunate side effect of error correction is that it erodes error detection: correction changes invalid inputs into valid inputs, but if more than a few errors were made then the valid input may not be the correct input. Use of an incorrect but valid input can cause funds to be lost irrecoverably. Because of this, implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.</p>
|
||||
</section>
|
||||
<section id="uppercase-lowercase"><h4><span class="section-heading">Uppercase/lowercase</span><span class="section-anchor"> <a rel="bookmark" href="#uppercase-lowercase"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The lowercase form is used when determining a character's value for checksum purposes.</p>
|
||||
<p>Encoders MUST always output an all-lowercase Bech32 string. If an uppercase version of the encoding result is desired (e.g. for presentation purposes, or QR code use), then an uppercasing procedure can be performed external to the encoding process.</p>
|
||||
<p>Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed-case strings).</p>
|
||||
<p>For presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of <a href="https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding">alphanumeric mode</a>, which is 45% more compact than the <a href="https://www.thonky.com/qr-code-tutorial/byte-mode-encoding">byte mode</a> that would otherwise be used.</p>
|
||||
</section>
|
||||
<section id="encoding"><h4><span class="section-heading">Encoding</span><span class="section-anchor"> <a rel="bookmark" href="#encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<ul>
|
||||
<li>Start with the bits of the raw encoding of the appropriate address or key type, most significant bit per byte first.</li>
|
||||
<li>Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.</li>
|
||||
<li>Translate those bits, most significant bit first, to characters using the table above.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="decoding"><h4><span class="section-heading">Decoding</span><span class="section-anchor"> <a rel="bookmark" href="#decoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Software interpreting a Bech32-encoded address MUST first verify that the human-readable part matches that of a specified address type, and similarly for keys.</p>
|
||||
<p>If this check passes, convert the rest of the data to bytes:</p>
|
||||
<ul>
|
||||
<li>Translate the values using the table above to 5 bits, most significant bit first.</li>
|
||||
<li>Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or fewer, MUST be all zeroes, and is discarded.</li>
|
||||
<li>The resulting groups are interpreted as the raw encoding of the appropriate address or key type, with the most significant bit first in each byte.</li>
|
||||
</ul>
|
||||
<p>Decoders SHOULD enforce known-length restrictions on address and key types.</p>
|
||||
<p>For example, <a id="id11" class="footnote_reference" href="#protocol">2</a> specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.</p>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="compatibility"><h2><span class="section-heading">Compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Only software supporting the Sapling network upgrade is able to use these addresses.</p>
|
||||
<p>There is no effect on support for transparent addresses and keys, or for Sprout z-addresses and keys; these will continue to be encoded using Base58Check, and MUST NOT be encoded using Bech32.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="why-use-base32-at-all"><h3><span class="section-heading">Why use base32 at all?</span><span class="section-anchor"> <a rel="bookmark" href="#why-use-base32-at-all"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The lack of mixed case makes it more efficient to read out loud or to put into QR codes. It does come with a 15% length increase. However, the length of a Bech32-encoded Sapling payment address remains below 80 characters, which reduces the likelihood of line splitting in terminals or email. Thus, cutting-and-pasting of addresses is still reliable.</p>
|
||||
</section>
|
||||
<section id="why-call-it-bech32"><h3><span class="section-heading">Why call it Bech32?</span><span class="section-anchor"> <a rel="bookmark" href="#why-call-it-bech32"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>"Bech" contains the characters BCH (the error detection algorithm used) and sounds a bit like "base". The term Bech32 is established for Bitcoin and there was no reason to use a different name for it in Zcash Sapling.</p>
|
||||
</section>
|
||||
<section id="why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><h3><span class="section-heading">Why not support Bech32 encoding of Sprout or transparent addresses?</span><span class="section-anchor"> <a rel="bookmark" href="#why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This was not considered to be sufficiently well-motivated given the compatibility issues that would arise from having two formats for these address types, with pre-Sapling software not supporting the new format.</p>
|
||||
</section>
|
||||
<section id="why-include-a-separator-in-addresses"><h3><span class="section-heading">Why include a separator in addresses?</span><span class="section-anchor"> <a rel="bookmark" href="#why-include-a-separator-in-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>That way the human-readable part is unambiguously separated from the data part, avoiding potential collisions with other human-readable parts that share a prefix. It also allows us to avoid having character-set restrictions on the human-readable part. The separator is ''1'' because using a non-alphanumeric character would complicate copy-pasting of addresses (with no double-click selection in several applications). Therefore an alphanumeric character outside the normal character set was chosen.</p>
|
||||
</section>
|
||||
<section id="why-not-use-an-existing-base32-character-set"><h3><span class="section-heading">Why not use an existing base32 character set?</span><span class="section-anchor"> <a rel="bookmark" href="#why-not-use-an-existing-base32-character-set"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Existing character sets for base-32 encodings include <a href="https://www.rfc-editor.org/rfc/rfc3548.html">RFC 3548</a> and <a href="https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt">z-base-32</a>. The set used for Bech32 was chosen to minimize ambiguity according to <a href="https://hissa.nist.gov/~black/GTLD/">this</a> visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.</p>
|
||||
</section>
|
||||
<section id="why-are-the-high-bits-of-the-human-readable-part-processed-first"><h3><span class="section-heading">Why are the high bits of the human-readable part processed first?</span><span class="section-anchor"> <a rel="bookmark" href="#why-are-the-high-bits-of-the-human-readable-part-processed-first"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This design choice had a rationale for Bitcoin Segregated Witness addresses (see <a id="id12" class="footnote_reference" href="#bip-0173">7</a>) that does not apply to Zcash Sapling addresses. It is retained for compatibility with Bech32 encoders/decoders written for Bitcoin.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementations"><h2><span class="section-heading">Reference implementations</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The encoder/decoder used by <code>zcashd</code>:
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash/zcash/blob/master/src/bech32.cpp">In C++</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Encoders and decoders written for Bitcoin:
|
||||
<ul>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/c">For C</a></li>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/c++">For C++</a></li>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/javascript">For Javascript</a></li>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/go">For Go</a></li>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/python">For Python</a></li>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/haskell">For Haskell</a></li>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/ruby">For Ruby</a></li>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ref/rust">For Rust</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Fancy decoder written for Bitcoin that localizes errors:
|
||||
<ul>
|
||||
<li><a href="https://github.com/sipa/bech32/tree/master/ecc/javascript">Fancy decoder for Javascript</a> (<a href="HTTP://bitcoin.sipa.be/bech32/demo/demo.html">demo website</a>)</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Note that the encoders written for Bitcoin may make assumptions specific to Segregated Witness address formats that do not apply to Zcash. Only the Python one has been tested with Zcash at the time of writing.</p>
|
||||
</section>
|
||||
<section id="examples"><h2><span class="section-heading">Examples</span><span class="section-anchor"> <a rel="bookmark" href="#examples"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TODO: add valid Sapling payment addresses and keys, and their corresponding raw encodings.</p>
|
||||
</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>The following strings are valid Bech32:</p>
|
||||
<ul>
|
||||
<li><code>A12UEL5L</code></li>
|
||||
<li><code>a12uel5l</code></li>
|
||||
<li><code>an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</code></li>
|
||||
<li><code>abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</code></li>
|
||||
<li><code>11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</code></li>
|
||||
<li><code>split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w</code></li>
|
||||
<li><code>?1ezyfcl</code></li>
|
||||
</ul>
|
||||
<p>The following strings are not valid Bech32 (with reason for invalidity):</p>
|
||||
<ul>
|
||||
<li>0x20 + <code>1nwldj5</code>: HRP character out of range</li>
|
||||
<li>0x7F + <code>1axkwrx</code>: HRP character out of range</li>
|
||||
<li>0x80 + <code>1eym55h</code>: HRP character out of range</li>
|
||||
<li><code>pzry9x0s0muk</code>: No separator character</li>
|
||||
<li><code>1pzry9x0s0muk</code>: Empty HRP</li>
|
||||
<li><code>x1b4n0q5v</code>: Invalid data character</li>
|
||||
<li><code>li1dgmt3</code>: Too short checksum</li>
|
||||
<li><code>de1lg7wt</code> + 0xFF: Invalid character in checksum</li>
|
||||
<li><code>A1G7SGD8</code>: checksum calculated with uppercase form of HRP</li>
|
||||
<li><code>10a06t8</code>: empty HRP</li>
|
||||
<li><code>1qzzfhee</code>: empty HRP</li>
|
||||
<li><code>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</code>: Invalid checksum</li>
|
||||
<li><code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sL5k7</code>: Mixed case</li>
|
||||
<li><code>bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du</code>: Zero padding of more than 4 bits</li>
|
||||
<li><code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv</code>: Non-zero padding in 8-to-5 conversion</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="checksum-design"><h2><span class="section-heading">Checksum design</span><span class="section-anchor"> <a rel="bookmark" href="#checksum-design"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="design-choices"><h3><span class="section-heading">Design choices</span><span class="section-anchor"> <a rel="bookmark" href="#design-choices"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>BCH codes can be constructed over any prime-power alphabet and can be chosen to have a good trade-off between size and error-detection capabilities. Unlike <a href="https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction">Reed-Solomon codes</a>, they are not restricted in length to one less than the alphabet size. While they also support efficient error correction, the implementation of just error detection is very simple.</p>
|
||||
<p>We pick 6 checksum characters as a trade-off between length of the addresses and the error-detection capabilities, as 6 characters is the lowest number sufficient for a random failure chance below 1 per billion. For the length of data we're most interested in protecting (up to 77 bytes excluding the separator, for a Sapling payment address), BCH codes can be constructed that guarantee detecting up to 4 errors. Longer data is also supported with slightly weaker error detection.</p>
|
||||
<section id="selected-properties"><h4><span class="section-heading">Selected properties</span><span class="section-anchor"> <a rel="bookmark" href="#selected-properties"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Many of these codes perform badly when dealing with more errors than they are designed to detect, but not all. For that reason, we consider codes that are designed to detect only 3 errors as well as 4 errors, and analyse how well they perform in practice.</p>
|
||||
<p>The specific code chosen here is the result of:</p>
|
||||
<ul>
|
||||
<li>Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4 errors up to length 93, 151, 165, 341, 1023, and 1057.</li>
|
||||
<li>From those, requiring the detection of 4 errors up to length 71, resulting in 28825 remaining codes.</li>
|
||||
<li>From those, choosing the codes with the best worst-case window for 5-character errors, resulting in 310 remaining codes.</li>
|
||||
<li>From those, picking the code with the lowest chance for not detecting small numbers of ''bit'' errors.</li>
|
||||
</ul>
|
||||
<p>As a naive search would require over 6.5 * 10<sup>19</sup> checksum evaluations, a collision-search approach was used for analysis. The code can be found <a href="https://github.com/sipa/ezbase32/">here</a>.</p>
|
||||
</section>
|
||||
<section id="properties"><h4><span class="section-heading">Properties</span><span class="section-anchor"> <a rel="bookmark" href="#properties"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The following table summarizes the chances for detection failure (as multiples of 1 in 10<sup>9</sup>).</p>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td colspan="2">Window length</td>
|
||||
<td colspan="6">Number of wrong characters</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Length</td>
|
||||
<td>Description</td>
|
||||
<td>≤4</td>
|
||||
<td>5</td>
|
||||
<td>6</td>
|
||||
<td>7</td>
|
||||
<td>8</td>
|
||||
<td>≥9</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>8</td>
|
||||
<td>Longest detecting 6 errors</td>
|
||||
<td colspan="3">0</td>
|
||||
<td>1.127</td>
|
||||
<td>0.909</td>
|
||||
<td>n/a</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>18</td>
|
||||
<td>Longest detecting 5 errors</td>
|
||||
<td colspan="2">0</td>
|
||||
<td>0.965</td>
|
||||
<td>0.929</td>
|
||||
<td>0.932</td>
|
||||
<td>0.931</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>19</td>
|
||||
<td>Worst case for 6 errors</td>
|
||||
<td>0</td>
|
||||
<td>0.093</td>
|
||||
<td>0.972</td>
|
||||
<td>0.928</td>
|
||||
<td colspan="2">0.931</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>39</td>
|
||||
<td>Length ≤ 39 characters</td>
|
||||
<td>0</td>
|
||||
<td>0.756</td>
|
||||
<td>0.935</td>
|
||||
<td>0.932</td>
|
||||
<td colspan="2">0.931</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>59</td>
|
||||
<td>Length ≤ 59 characters</td>
|
||||
<td>0</td>
|
||||
<td>0.805</td>
|
||||
<td>0.933</td>
|
||||
<td colspan="3">0.931</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>71</td>
|
||||
<td>Length ≤ 71 characters</td>
|
||||
<td>0</td>
|
||||
<td>0.830</td>
|
||||
<td>0.934</td>
|
||||
<td colspan="3">0.931</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>89</td>
|
||||
<td>Longest detecting 4 errors</td>
|
||||
<td>0</td>
|
||||
<td>0.867</td>
|
||||
<td>0.933</td>
|
||||
<td colspan="3">0.931</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>TODO: fill in table for a Sapling payment address, and check the following paragraph.</p>
|
||||
<p>This means that when 5 changed characters occur randomly distributed in the 77 characters (excluding the separator) of a Sapling payment address, there is a chance of at most 0.867 per billion that it will go undetected. When those 5 changes occur randomly within a 19-character window, that chance goes down to 0.093 per billion. As the number of errors goes up, the chance converges towards 1 in 2<sup>30</sup> = 0.931 per billion.</p>
|
||||
<p>The chosen code performs reasonably well up to 1023 characters, but is best for lengths up to 89 characters (excluding the separator). Since the search for suitable codes was based on the requirements for Bitcoin P2WPKH and P2WSH addresses, it is not quite optimal for the address lengths used by Sapling, but the advantages of compatibility with existing Bitcoin libraries were considered to outweigh this consideration.</p>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This document is closely based on BIP 173 written by Pieter Wuille and Greg Maxwell, which was inspired by the <a href="https://rusty.ozlabs.org/?p=578">address proposal</a> by Rusty Russell and the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html">base32</a> proposal by Mark Friedenbach. BIP 173 also had input from Luke Dashjr, Johnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0205" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0013" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki">BIP 13: Address Format for pay-to-script-hash</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>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,470 @@
|
|||
::
|
||||
|
||||
ZIP: 173
|
||||
Title: Bech32 Format
|
||||
Author: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Pieter Wuille <pieter.wuille@gmail.com>
|
||||
Greg Maxwell <greg@xiph.org>
|
||||
Rusty Russell
|
||||
Mark Friedenbach
|
||||
Status: Final
|
||||
Category: Standards / Wallet
|
||||
Created: 2018-06-13
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are
|
||||
to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as described in
|
||||
ZIP 200. [#zip-0200]_
|
||||
|
||||
The term "Sapling" in this document is to be interpreted as described in ZIP 205.
|
||||
[#zip-0205]_
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This document proposes a checksummed base32 format, "Bech32", and a standard for
|
||||
Sapling addresses and keys using it.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256
|
||||
checksum, inherited from Bitcoin. They were part of the original Bitcoin software
|
||||
and their scope was extended in BIP 13 [#bip-0013]_ for P2SH (Pay-to-Script-Hash)
|
||||
addresses. However, both the character set and the checksum algorithm have
|
||||
limitations:
|
||||
|
||||
* Base58 needs a lot of space in QR codes, as it cannot use the
|
||||
''alphanumeric mode''.
|
||||
|
||||
* The mixed case in Base58 makes it inconvenient to reliably write down, type on
|
||||
mobile keyboards, or read out loud.
|
||||
|
||||
* The double-SHA256 checksum is slow and has no error-detection guarantees.
|
||||
|
||||
* Most of the research on error-detecting codes only applies to character-set
|
||||
sizes that are a `prime power <https://en.wikipedia.org/wiki/Prime_power>`_,
|
||||
which 58 is not.
|
||||
|
||||
* Base58 decoding is complicated and relatively slow.
|
||||
|
||||
To address these issues, Bitcoin adopted a new encoding called Bech32 [#bip-0173]_,
|
||||
for use with address types added by its Segregated Witness proposal. Zcash does
|
||||
not implement Segregated Witness, but it reuses Bech32 with address and key types
|
||||
introduced by the Sapling network upgrade [#zip-0205]_.
|
||||
|
||||
Since the description of Bech32 in [#bip-0173]_ is partially entangled with
|
||||
Segregated Witness address formats, we have found it clearer to write this ZIP to
|
||||
specify Bech32 separately. This specification should be read in conjunction with
|
||||
section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol
|
||||
specification [#protocol]_, and with ZIP 32 which specifies additional key types
|
||||
for support of shielded hierarchical deterministic wallets [#zip-0032]_.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
We describe the general checksummed base32 format called ''Bech32''. Its use for
|
||||
Sapling payment addresses and keys is defined in the Sapling protocol specification
|
||||
[#protocol]_.
|
||||
|
||||
A Bech32 string consists of:
|
||||
|
||||
* The *human-readable part*, which is intended to convey the type of data, or
|
||||
anything else that is relevant to the reader. This part MUST contain 1 to 83
|
||||
US-ASCII characters, with each character having a value in the range [33-126].
|
||||
HRP validity may be further restricted by specific applications.
|
||||
|
||||
* The *separator*, which is always "1". In case "1" is allowed inside the
|
||||
human-readable part, the last one in the string is the separator.
|
||||
|
||||
* The *data part*, which is at least 6 characters long and only consists of
|
||||
alphanumeric characters excluding "1", "b", "i", and "o".
|
||||
|
||||
+-----+---+---+---+---+---+---+---+---+
|
||||
| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|
||||
+=====+===+===+===+===+===+===+===+===+
|
||||
| +0 | q | p | z | r | y | 9 | x | 8 |
|
||||
+-----+---+---+---+---+---+---+---+---+
|
||||
| +8 | g | f | 2 | t | v | d | w | 0 |
|
||||
+-----+---+---+---+---+---+---+---+---+
|
||||
| +16 | s | 3 | j | n | 5 | 4 | k | h |
|
||||
+-----+---+---+---+---+---+---+---+---+
|
||||
| +24 | c | e | 6 | m | u | a | 7 | l |
|
||||
+-----+---+---+---+---+---+---+---+---+
|
||||
|
||||
|
||||
Checksum
|
||||
--------
|
||||
|
||||
The last six characters of the data part form a checksum and contain no information.
|
||||
Valid strings MUST pass the criteria for validity specified by the Python3 code
|
||||
snippet below. The checksum is defined so that the function ``bech32_verify_checksum``
|
||||
returns true when its arguments are:
|
||||
|
||||
* ``hrp``: the human-readable part as a string;
|
||||
* ``data``: the data part as a list of integers representing the characters after
|
||||
conversion using the table above.
|
||||
|
||||
::
|
||||
|
||||
def bech32_polymod(values):
|
||||
GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
|
||||
chk = 1
|
||||
for v in values:
|
||||
b = (chk >> 25)
|
||||
chk = (chk & 0x1ffffff) << 5 ^ v
|
||||
for i in range(5):
|
||||
chk ^= GEN[i] if ((b >> i) & 1) else 0
|
||||
return chk
|
||||
|
||||
def bech32_hrp_expand(s):
|
||||
return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]
|
||||
|
||||
def bech32_verify_checksum(hrp, data):
|
||||
return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1
|
||||
|
||||
|
||||
This implements a `BCH code <https://en.wikipedia.org/wiki/BCH_code>`_;
|
||||
in the case where the encoded string is at most 90 characters, this code
|
||||
guarantees detection of *any error affecting at most 4 characters* and has
|
||||
less than a 1 in 10\ :sup:`9` chance of failing to detect more errors.
|
||||
More details about the properties can be found in the Checksum Design section.
|
||||
The human-readable part is processed by first feeding the higher 3 bits of each
|
||||
character's US-ASCII value into the checksum calculation followed by a zero
|
||||
and then the lower 5 bits of each US-ASCII value.
|
||||
|
||||
To construct a valid checksum given the human-readable part and (non-checksum)
|
||||
values of the data-part characters, the code below can be used:
|
||||
|
||||
::
|
||||
|
||||
def bech32_create_checksum(hrp, data):
|
||||
values = bech32_hrp_expand(hrp) + data
|
||||
polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1
|
||||
return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)]
|
||||
|
||||
|
||||
Error correction
|
||||
''''''''''''''''
|
||||
|
||||
One of the properties of these BCH codes is that they can be used for error
|
||||
correction. An unfortunate side effect of error correction is that it erodes
|
||||
error detection: correction changes invalid inputs into valid inputs, but if
|
||||
more than a few errors were made then the valid input may not be the correct
|
||||
input. Use of an incorrect but valid input can cause funds to be lost
|
||||
irrecoverably. Because of this, implementations SHOULD NOT implement correction
|
||||
beyond potentially suggesting to the user where in the string an error might be
|
||||
found, without suggesting the correction to make.
|
||||
|
||||
Uppercase/lowercase
|
||||
'''''''''''''''''''
|
||||
|
||||
The lowercase form is used when determining a character's value for checksum
|
||||
purposes.
|
||||
|
||||
Encoders MUST always output an all-lowercase Bech32 string. If an uppercase
|
||||
version of the encoding result is desired (e.g. for presentation purposes, or
|
||||
QR code use), then an uppercasing procedure can be performed external to the
|
||||
encoding process.
|
||||
|
||||
Decoders MUST NOT accept strings where some characters are uppercase and some
|
||||
are lowercase (such strings are referred to as mixed-case strings).
|
||||
|
||||
For presentation, lowercase is usually preferable, but inside QR codes
|
||||
uppercase SHOULD be used, as those permit the use of `alphanumeric mode
|
||||
<https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding>`_,
|
||||
which is 45% more compact than the `byte mode
|
||||
<https://www.thonky.com/qr-code-tutorial/byte-mode-encoding>`_ that would
|
||||
otherwise be used.
|
||||
|
||||
Encoding
|
||||
''''''''
|
||||
|
||||
* Start with the bits of the raw encoding of the appropriate address or key
|
||||
type, most significant bit per byte first.
|
||||
|
||||
* Re-arrange those bits into groups of 5, and pad with zeroes at the end if
|
||||
needed.
|
||||
|
||||
* Translate those bits, most significant bit first, to characters using the
|
||||
table above.
|
||||
|
||||
Decoding
|
||||
''''''''
|
||||
|
||||
Software interpreting a Bech32-encoded address MUST first verify that the
|
||||
human-readable part matches that of a specified address type, and similarly
|
||||
for keys.
|
||||
|
||||
If this check passes, convert the rest of the data to bytes:
|
||||
|
||||
* Translate the values using the table above to 5 bits, most significant bit
|
||||
first.
|
||||
|
||||
* Re-arrange those bits into groups of 8 bits. Any incomplete group at the
|
||||
end MUST be 4 bits or fewer, MUST be all zeroes, and is discarded.
|
||||
|
||||
* The resulting groups are interpreted as the raw encoding of the appropriate
|
||||
address or key type, with the most significant bit first in each byte.
|
||||
|
||||
Decoders SHOULD enforce known-length restrictions on address and key types.
|
||||
|
||||
For example, [#protocol]_ specifies that the length of the raw encoding of a
|
||||
Sapling payment address is 43 bytes (88 + 256 bits). This results in a
|
||||
Bech32-encoded Sapling payment address being 78 characters long.
|
||||
|
||||
|
||||
Compatibility
|
||||
=============
|
||||
|
||||
Only software supporting the Sapling network upgrade is able to use these
|
||||
addresses.
|
||||
|
||||
There is no effect on support for transparent addresses and keys, or for Sprout
|
||||
z-addresses and keys; these will continue to be encoded using Base58Check, and
|
||||
MUST NOT be encoded using Bech32.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
Why use base32 at all?
|
||||
----------------------
|
||||
|
||||
The lack of mixed case makes it more efficient to read out loud or to put into
|
||||
QR codes. It does come with a 15% length increase. However, the length of a
|
||||
Bech32-encoded Sapling payment address remains below 80 characters, which
|
||||
reduces the likelihood of line splitting in terminals or email. Thus,
|
||||
cutting-and-pasting of addresses is still reliable.
|
||||
|
||||
Why call it Bech32?
|
||||
-------------------
|
||||
|
||||
"Bech" contains the characters BCH (the error detection algorithm used) and
|
||||
sounds a bit like "base". The term Bech32 is established for Bitcoin and there
|
||||
was no reason to use a different name for it in Zcash Sapling.
|
||||
|
||||
Why not support Bech32 encoding of Sprout or transparent addresses?
|
||||
-------------------------------------------------------------------
|
||||
|
||||
This was not considered to be sufficiently well-motivated given the
|
||||
compatibility issues that would arise from having two formats for these
|
||||
address types, with pre-Sapling software not supporting the new format.
|
||||
|
||||
Why include a separator in addresses?
|
||||
-------------------------------------
|
||||
|
||||
That way the human-readable part is unambiguously separated from the data part,
|
||||
avoiding potential collisions with other human-readable parts that share a
|
||||
prefix. It also allows us to avoid having character-set restrictions on the
|
||||
human-readable part. The separator is ''1'' because using a non-alphanumeric
|
||||
character would complicate copy-pasting of addresses (with no double-click
|
||||
selection in several applications). Therefore an alphanumeric character outside
|
||||
the normal character set was chosen.
|
||||
|
||||
Why not use an existing base32 character set?
|
||||
---------------------------------------------
|
||||
|
||||
Existing character sets for base-32 encodings include
|
||||
`RFC 3548 <https://www.rfc-editor.org/rfc/rfc3548.html>`_ and
|
||||
`z-base-32 <https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt>`_.
|
||||
The set used for Bech32 was chosen to minimize ambiguity according to
|
||||
`this <https://hissa.nist.gov/~black/GTLD/>`_ visual similarity data, and the
|
||||
ordering is chosen to minimize the number of pairs of similar characters
|
||||
(according to the same data) that differ in more than 1 bit. As the checksum is
|
||||
chosen to maximize detection capabilities for low numbers of bit errors, this
|
||||
choice improves its performance under some error models.
|
||||
|
||||
Why are the high bits of the human-readable part processed first?
|
||||
-----------------------------------------------------------------
|
||||
|
||||
This design choice had a rationale for Bitcoin Segregated Witness addresses
|
||||
(see [#bip-0173]_) that does not apply to Zcash Sapling addresses. It is
|
||||
retained for compatibility with Bech32 encoders/decoders written for Bitcoin.
|
||||
|
||||
|
||||
Reference implementations
|
||||
=========================
|
||||
|
||||
* The encoder/decoder used by ``zcashd``:
|
||||
|
||||
* `In C++ <https://github.com/zcash/zcash/blob/master/src/bech32.cpp>`_
|
||||
|
||||
* Encoders and decoders written for Bitcoin:
|
||||
|
||||
* `For C <https://github.com/sipa/bech32/tree/master/ref/c>`_
|
||||
* `For C++ <https://github.com/sipa/bech32/tree/master/ref/c++>`_
|
||||
* `For Javascript <https://github.com/sipa/bech32/tree/master/ref/javascript>`_
|
||||
* `For Go <https://github.com/sipa/bech32/tree/master/ref/go>`_
|
||||
* `For Python <https://github.com/sipa/bech32/tree/master/ref/python>`_
|
||||
* `For Haskell <https://github.com/sipa/bech32/tree/master/ref/haskell>`_
|
||||
* `For Ruby <https://github.com/sipa/bech32/tree/master/ref/ruby>`_
|
||||
* `For Rust <https://github.com/sipa/bech32/tree/master/ref/rust>`_
|
||||
|
||||
* Fancy decoder written for Bitcoin that localizes errors:
|
||||
|
||||
* `Fancy decoder for Javascript <https://github.com/sipa/bech32/tree/master/ecc/javascript>`_
|
||||
(`demo website <HTTP://bitcoin.sipa.be/bech32/demo/demo.html>`_)
|
||||
|
||||
Note that the encoders written for Bitcoin may make assumptions specific to
|
||||
Segregated Witness address formats that do not apply to Zcash. Only the Python
|
||||
one has been tested with Zcash at the time of writing.
|
||||
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
TODO: add valid Sapling payment addresses and keys, and their corresponding raw encodings.
|
||||
|
||||
|
||||
Test vectors
|
||||
============
|
||||
|
||||
The following strings are valid Bech32:
|
||||
|
||||
* ``A12UEL5L``
|
||||
* ``a12uel5l``
|
||||
* ``an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs``
|
||||
* ``abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw``
|
||||
* ``11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j``
|
||||
* ``split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w``
|
||||
* ``?1ezyfcl``
|
||||
|
||||
The following strings are not valid Bech32 (with reason for invalidity):
|
||||
|
||||
* 0x20 + ``1nwldj5``: HRP character out of range
|
||||
* 0x7F + ``1axkwrx``: HRP character out of range
|
||||
* 0x80 + ``1eym55h``: HRP character out of range
|
||||
* ``pzry9x0s0muk``: No separator character
|
||||
* ``1pzry9x0s0muk``: Empty HRP
|
||||
* ``x1b4n0q5v``: Invalid data character
|
||||
* ``li1dgmt3``: Too short checksum
|
||||
* ``de1lg7wt`` + 0xFF: Invalid character in checksum
|
||||
* ``A1G7SGD8``: checksum calculated with uppercase form of HRP
|
||||
* ``10a06t8``: empty HRP
|
||||
* ``1qzzfhee``: empty HRP
|
||||
* ``bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5``: Invalid checksum
|
||||
* ``tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sL5k7``: Mixed case
|
||||
* ``bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du``: Zero padding of more than 4 bits
|
||||
* ``tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv``: Non-zero padding in 8-to-5 conversion
|
||||
|
||||
|
||||
Checksum design
|
||||
===============
|
||||
|
||||
Design choices
|
||||
--------------
|
||||
|
||||
BCH codes can be constructed over any prime-power alphabet and can be chosen to
|
||||
have a good trade-off between size and error-detection capabilities. Unlike
|
||||
`Reed-Solomon codes <https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction>`_,
|
||||
they are not restricted in length to one less than the alphabet size. While they
|
||||
also support efficient error correction, the implementation of just error detection
|
||||
is very simple.
|
||||
|
||||
We pick 6 checksum characters as a trade-off between length of the addresses and
|
||||
the error-detection capabilities, as 6 characters is the lowest number sufficient
|
||||
for a random failure chance below 1 per billion. For the length of data we're
|
||||
most interested in protecting (up to 77 bytes excluding the separator, for a
|
||||
Sapling payment address), BCH codes can be constructed that guarantee detecting
|
||||
up to 4 errors. Longer data is also supported with slightly weaker error detection.
|
||||
|
||||
Selected properties
|
||||
'''''''''''''''''''
|
||||
|
||||
Many of these codes perform badly when dealing with more errors than they are
|
||||
designed to detect, but not all. For that reason, we consider codes that are
|
||||
designed to detect only 3 errors as well as 4 errors, and analyse how well they
|
||||
perform in practice.
|
||||
|
||||
The specific code chosen here is the result of:
|
||||
|
||||
* Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4
|
||||
errors up to length 93, 151, 165, 341, 1023, and 1057.
|
||||
|
||||
* From those, requiring the detection of 4 errors up to length 71, resulting in
|
||||
28825 remaining codes.
|
||||
|
||||
* From those, choosing the codes with the best worst-case window for 5-character
|
||||
errors, resulting in 310 remaining codes.
|
||||
|
||||
* From those, picking the code with the lowest chance for not detecting small
|
||||
numbers of ''bit'' errors.
|
||||
|
||||
As a naive search would require over 6.5 \* 10\ :sup:`19` checksum evaluations,
|
||||
a collision-search approach was used for analysis. The code can be found
|
||||
`here <https://github.com/sipa/ezbase32/>`_.
|
||||
|
||||
Properties
|
||||
''''''''''
|
||||
|
||||
The following table summarizes the chances for detection failure (as multiples of
|
||||
1 in 10\ :sup:`9`).
|
||||
|
||||
+-------------------------------------+-----------------------------------------------+
|
||||
| Window length | Number of wrong characters |
|
||||
+--------+----------------------------+-------+-------+-------+-------+-------+-------+
|
||||
| Length | Description | ≤4 | 5 | 6 | 7 | 8 | ≥9 |
|
||||
+--------+----------------------------+-------+-------+-------+-------+-------+-------+
|
||||
| 8 | Longest detecting 6 errors | 0 | 1.127 | 0.909 | n/a |
|
||||
+--------+----------------------------+---------------+-------+-------+-------+-------+
|
||||
| 18 | Longest detecting 5 errors | 0 | 0.965 | 0.929 | 0.932 | 0.931 |
|
||||
+--------+----------------------------+-------+-------+-------+-------+-------+-------+
|
||||
| 19 | Worst case for 6 errors | 0 | 0.093 | 0.972 | 0.928 | 0.931 |
|
||||
+--------+----------------------------+-------+-------+-------+-------+---------------+
|
||||
| 39 | Length ≤ 39 characters | 0 | 0.756 | 0.935 | 0.932 | 0.931 |
|
||||
+--------+----------------------------+-------+-------+-------+-------+---------------+
|
||||
| 59 | Length ≤ 59 characters | 0 | 0.805 | 0.933 | 0.931 |
|
||||
+--------+----------------------------+-------+-------+-------+-----------------------+
|
||||
| 71 | Length ≤ 71 characters | 0 | 0.830 | 0.934 | 0.931 |
|
||||
+--------+----------------------------+-------+-------+-------+-----------------------+
|
||||
| 89 | Longest detecting 4 errors | 0 | 0.867 | 0.933 | 0.931 |
|
||||
+--------+----------------------------+-------+-------+-------+-----------------------+
|
||||
|
||||
TODO: fill in table for a Sapling payment address, and check the following paragraph.
|
||||
|
||||
This means that when 5 changed characters occur randomly distributed in the 77
|
||||
characters (excluding the separator) of a Sapling payment address, there is a chance
|
||||
of at most 0.867 per billion that it will go undetected. When those 5 changes occur
|
||||
randomly within a 19-character window, that chance goes down to 0.093 per billion.
|
||||
As the number of errors goes up, the chance converges towards 1 in 2\ :sup:`30` =
|
||||
0.931 per billion.
|
||||
|
||||
The chosen code performs reasonably well up to 1023 characters, but is best for
|
||||
lengths up to 89 characters (excluding the separator). Since the search for suitable
|
||||
codes was based on the requirements for Bitcoin P2WPKH and P2WSH addresses, it is
|
||||
not quite optimal for the address lengths used by Sapling, but the advantages of
|
||||
compatibility with existing Bitcoin libraries were considered to outweigh this
|
||||
consideration.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
================
|
||||
|
||||
This document is closely based on BIP 173 written by Pieter Wuille and Greg Maxwell,
|
||||
which was inspired by the `address proposal <https://rusty.ozlabs.org/?p=578>`_ by
|
||||
Rusty Russell and the `base32
|
||||
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html>`_
|
||||
proposal by Mark Friedenbach. BIP 173 also had input from Luke Dashjr, Johnson Lau,
|
||||
Eric Lombrozo, Peter Todd, and various other reviewers.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
|
||||
.. [#bip-0013] `BIP 13: Address Format for pay-to-script-hash <https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki>`_
|
||||
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
|
|
@ -0,0 +1,176 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 200: Network Upgrade Mechanism</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 200
|
||||
Title: Network Upgrade Mechanism
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-08
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD 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>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Block chain</dt>
|
||||
<dd>A sequence of blocks starting at the genesis block, where the header of each block refers to the previous block in the sequence.</dd>
|
||||
<dt>Consensus rule set</dt>
|
||||
<dd>A set of validation rules that determine which block chains are considered valid.</dd>
|
||||
<dt>Consensus rule change</dt>
|
||||
<dd>A change in the consensus rule set of the network, such that nodes that do not recognize the new rules will follow a different block chain.</dd>
|
||||
<dt>Consensus branch</dt>
|
||||
<dd>A block chain with a common consensus rule set, where the first block in the chain is either the genesis block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block is a member of a different consensus branch). By definition, every block belongs to at most one consensus branch.</dd>
|
||||
<dt>Network upgrade</dt>
|
||||
<dd>An intentional consensus rule change undertaken by the community in order to improve the network.</dd>
|
||||
</dl>
|
||||
</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 coordinating upgrades of the Zcash network, in order to remove ambiguity about when network upgrades will activate, provide defined periods in which users should upgrade their local software, and minimize the risks to both the upgrading network and any users opting out of the changes.</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>Zcash is a <em>consensual currency</em>: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. <a id="id2" class="footnote_reference" href="#consensual-currency">2</a> As such, different sub-communities will always have the freedom to choose different variants or branches which offer different design trade-offs.</p>
|
||||
<p>The current Zcash software includes an <em>End-of-Service halt</em> feature, causing nodes running a particular version to automatically shut down approximately 16 weeks after that version was released (specifically, at the block height <code>DEPRECATION_HEIGHT</code> defined in the source code for that version). This was implemented for several reasons: <a id="id3" class="footnote_reference" href="#release-lifecycle">3</a></p>
|
||||
<ul>
|
||||
<li>It gives the same systemic advantage of removing old software as auto-upgrade behavior.</li>
|
||||
<li>It requires users to individually choose one of the following options:
|
||||
<ul>
|
||||
<li>Upgrade to a more recent software release from the main network.</li>
|
||||
<li>Upgrade to an alternative release.</li>
|
||||
<li>Modify their node in order to keep running the older software.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Developers can rely on this cadence for coordinating network upgrades. Once the last pre-upgrade software version has been deprecated, they can reasonably assume that all node operators on the network either support the upgraded rules, or have explicitly chosen not to follow them.</p>
|
||||
<p>However, this behaviour is not sufficient for performing network upgrades. A globally-understood on-chain activation mechanism is necessary so that nodes can unambiguously know at what point the changes from an upgrade come into effect (and can enforce consensus rule changes, for example).</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following constants are defined for every network upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd>
|
||||
<p>A globally-unique non-zero 32-bit identifier.</p>
|
||||
<p>Implementations MAY use a value of zero in consensus branch ID fields to indicate the absence of any upgrade (i.e. that the Sprout consensus rules apply).</p>
|
||||
</dd>
|
||||
<dt>ACTIVATION_HEIGHT</dt>
|
||||
<dd>
|
||||
<p>The non-zero block height at which the network upgrade rules will come into effect, and be enforced as part of the block chain consensus.</p>
|
||||
<p>For removal of ambiguity, the block at height <code>ACTIVATION_HEIGHT - 1</code> is subject to the pre-upgrade consensus rules, and would be the last common block in the event of a persistent pre-upgrade consensus branch.</p>
|
||||
<p>It MUST be greater than the value of <code>DEPRECATION_HEIGHT</code> in the last software version that will not contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after the first software version containing support for the network upgrade is released, for the following reason:</p>
|
||||
<ul>
|
||||
<li>As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo End-of-Service halt 16 weeks after release. Thus, if version <code>X</code> contains support for a network upgrade, version <code>X-1</code> will be deprecated 10 weeks after the release of version <code>X</code>, which is about 2.3 months. A three-month window provides ample time for users to upgrade their nodes after End-of-Service halt, and re-integrate into the network prior to activation of the network upgrade.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
</dl>
|
||||
<p>The relationship between <code>CONSENSUS_BRANCH_ID</code> and <code>ACTIVATION_HEIGHT</code> is many-to-one: it is possible for many distinct consensus branches to descend from the same parent block (and thus have the same <code>ACTIVATION_HEIGHT</code>), but a specific consensus branch can only have one parent block. Concretely, this means that if the <code>ACTIVATION_HEIGHT</code> of a network upgrade is changed for any reason (e.g. security vulnerabilities or consensus bugs are discovered), the <code>CONSENSUS_BRANCH_ID</code> MUST also be changed.</p>
|
||||
<section id="activation-mechanism"><h3><span class="section-heading">Activation mechanism</span><span class="section-anchor"> <a rel="bookmark" href="#activation-mechanism"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Zcash block chain is broken into "epochs" of block height intervals <code>[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})</code> (i.e. including <code>ACTIVATION_HEIGHT_N</code> and excluding <code>ACTIVATION_HEIGHT_{N+1}</code>), on which consensus rule sets are defined.</p>
|
||||
<p>When a consensus rule depends on activation of a particular upgrade, its implementation (and that of any network behavior or surrounding code that depends on it) MUST be gated by a block height check. For example:</p>
|
||||
<pre data-language="cpp"><span class="k">if</span> <span class="p">(</span><span class="n">CurrentEpoch</span><span class="p">(</span><span class="n">chainActive</span><span class="p">.</span><span class="n">Height</span><span class="p">(),</span> <span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">())</span> <span class="o">==</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="c1">// Overwinter-specific logic</span>
|
||||
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
|
||||
<span class="c1">// Non-Overwinter logic</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="c1">// ...</span>
|
||||
|
||||
<span class="k">if</span> <span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">pindex</span><span class="o">-></span><span class="n">nHeight</span><span class="p">,</span> <span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">(),</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">))</span> <span class="p">{</span>
|
||||
<span class="c1">// Overwinter consensus rules applied to block</span>
|
||||
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
|
||||
<span class="c1">// Pre-Overwinter consensus rules applied to block</span>
|
||||
<span class="p">}</span></pre>
|
||||
<section id="block-validation"><h4><span class="section-heading">Block validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be validated under the consensus rules corresponding to the expected consensus branch ID for that height.</p>
|
||||
<p>Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown) MAY be cached, so that they can be reconsidered in the future after all their parents have been received.</p>
|
||||
</section>
|
||||
<section id="chain-reorganization"><h4><span class="section-heading">Chain reorganization</span><span class="section-anchor"> <a rel="bookmark" href="#chain-reorganization"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>It is possible for a reorganization to occur that rolls back from after the activation height, to before that height. This can be handled in the same way as any regular chain orphaning or reorganization, as long as the new chain is valid.</p>
|
||||
</section>
|
||||
<section id="post-activation-upgrading"><h4><span class="section-heading">Post-activation upgrading</span><span class="section-anchor"> <a rel="bookmark" href="#post-activation-upgrading"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>If a user does not upgrade their node to a compatible software version before <code>ACTIVATION_HEIGHT</code> is reached, and the node continues running (which could normally only occur if the End-of-Service halt were bypassed), then the node will follow any pre-upgrade consensus branch that persists. In this case it may download blocks that are incompatible with the post-upgrade consensus branch. If the user subsequently upgrades their node to a compatible software version, the node will consider these blocks to be invalid, and if there are a significant number of invalid blocks it SHOULD shut down and alert the user of the issue.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="memory-pool"><h3><span class="section-heading">Memory pool</span><span class="section-anchor"> <a rel="bookmark" href="#memory-pool"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>While the current chain tip height is below <code>ACTIVATION_HEIGHT</code>, nodes SHOULD NOT accept transactions that will only be valid on the post-upgrade consensus branch.</p>
|
||||
<p>When the current chain tip height reaches <code>ACTIVATION_HEIGHT</code>, the node's local transaction memory pool SHOULD be cleared of transactions that will never be valid on the post-upgrade consensus branch.</p>
|
||||
</section>
|
||||
<section id="two-way-replay-protection"><h3><span class="section-heading">Two-way replay protection</span><span class="section-anchor"> <a rel="bookmark" href="#two-way-replay-protection"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the most significant bit of the transaction version is set to 1. <a id="id4" class="footnote_reference" href="#zip-0202">6</a> From the perspective of old nodes, the transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes old transactions invalid on the Overwinter consensus branch.</p>
|
||||
<p>After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific <code>CONSENSUS_BRANCH_ID</code>. <a id="id5" class="footnote_reference" href="#zip-0143">4</a></p>
|
||||
</section>
|
||||
<section id="wipe-out-protection"><h3><span class="section-heading">Wipe-out protection</span><span class="section-anchor"> <a rel="bookmark" href="#wipe-out-protection"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from <code>ACTIVATION_HEIGHT</code>. The chain from that height will not reorganize to a pre-upgrade consensus branch if any block in that consensus branch would violate the new consensus rules.</p>
|
||||
<p>Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not differ. For example, if the non-upgraded chain only contained empty blocks from <code>ACTIVATION_HEIGHT</code>, and the coinbase transactions were valid under both the old and new consensus rules, a wipe-out could occur. The Overwinter network upgrade is not susceptible to this because all previous transaction versions will become invalid, meaning that the coinbase transactions must use the newer transaction version. More generally, this issue could be addressed in a future network upgrade by modifying the block header to include a commitment to the <code>CONSENSUS_BRANCH_ID</code>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. <a id="id6" class="footnote_reference" href="#zip-0201">5</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2898">https://github.com/zcash/zcash/pull/2898</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="consensual-currency" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="https://electriccoin.co/blog/consensual-currency/">Consensual Currency. Electric Coin Company blog</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="release-lifecycle" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td>
|
||||
<ul>
|
||||
<li><a href="https://electriccoin.co/blog/release-cycle-and-lifetimes/">Release Cycle and Lifetimes. Electric Coin Company blog</a></li>
|
||||
<li><a href="https://electriccoin.co/blog/release-cycle-update/">Release Cycle Update. Electric Coin Company blog</a></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0143" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0202" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="zip-0202">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
83
zip-0200.rst
|
@ -2,7 +2,8 @@
|
|||
|
||||
ZIP: 200
|
||||
Title: Network Upgrade Mechanism
|
||||
Author: Jack Grigg <jack@z.cash>
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-08
|
||||
License: MIT
|
||||
|
@ -27,10 +28,11 @@ Consensus rule change
|
|||
A change in the consensus rule set of the network, such that nodes that do not recognize the new rules will
|
||||
follow a different block chain.
|
||||
|
||||
Branch
|
||||
Consensus branch
|
||||
A block chain with a common consensus rule set, where the first block in the chain is either the genesis
|
||||
block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block
|
||||
is a member of a different branch). By definition, every block belongs to at most one branch.
|
||||
is a member of a different consensus branch). By definition, every block belongs to at most one consensus
|
||||
branch.
|
||||
|
||||
Network upgrade
|
||||
An intentional consensus rule change undertaken by the community in order to improve the network.
|
||||
|
@ -48,10 +50,11 @@ Motivation
|
|||
==========
|
||||
|
||||
Zcash is a *consensual currency*: nobody is ever going to force someone to use a specific software
|
||||
implementation or a specific branch of Zcash. [#consensual-currency]_ As such, different sub-communities will
|
||||
always have the freedom to choose different variants or branches which offer different design trade-offs.
|
||||
implementation or a specific consensus branch of Zcash. [#consensual-currency]_ As such, different
|
||||
sub-communities will always have the freedom to choose different variants or branches which offer different
|
||||
design trade-offs.
|
||||
|
||||
The current Zcash software includes an *auto-senescence* feature, causing nodes running a particular version
|
||||
The current Zcash software includes an *End-of-Service halt* feature, causing nodes running a particular version
|
||||
to automatically shut down approximately 16 weeks after that version was released (specifically, at the block
|
||||
height ``DEPRECATION_HEIGHT`` defined in the source code for that version). This was implemented for several
|
||||
reasons: [#release-lifecycle]_
|
||||
|
@ -80,34 +83,35 @@ Specification
|
|||
|
||||
The following constants are defined for every network upgrade:
|
||||
|
||||
BRANCH_ID
|
||||
CONSENSUS_BRANCH_ID
|
||||
A globally-unique non-zero 32-bit identifier.
|
||||
|
||||
Implementations MAY use a value of zero in branch ID fields to indicate the absence of any upgrade (i.e.
|
||||
that the Sprout consensus rules apply).
|
||||
Implementations MAY use a value of zero in consensus branch ID fields to indicate the absence of any
|
||||
upgrade (i.e. that the Sprout consensus rules apply).
|
||||
|
||||
ACTIVATION_HEIGHT
|
||||
The non-zero block height at which the network upgrade rules will come into effect, and be enforced as part
|
||||
of the block chain consensus.
|
||||
|
||||
For removal of ambiguity, the block at height ``ACTIVATION_HEIGHT - 1`` is subject to the pre-upgrade
|
||||
consensus rules, and would be the last common block in the event of a persistent pre-upgrade branch.
|
||||
consensus rules, and would be the last common block in the event of a persistent pre-upgrade consensus
|
||||
branch.
|
||||
|
||||
It MUST be greater than the value of ``DEPRECATION_HEIGHT`` in the last software version that will not
|
||||
contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after
|
||||
the first software version containing support for the network upgrade is released, for the following reason:
|
||||
|
||||
- As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo
|
||||
auto-senescence 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade,
|
||||
End-of-Service halt 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade,
|
||||
version ``X-1`` will be deprecated 10 weeks after the release of version ``X``, which is about 2.3 months.
|
||||
A three-month window provides ample time for users to upgrade their nodes after auto-senescence, and
|
||||
A three-month window provides ample time for users to upgrade their nodes after End-of-Service halt, and
|
||||
re-integrate into the network prior to activation of the network upgrade.
|
||||
|
||||
The relationship between ``BRANCH_ID`` and ``ACTIVATION_HEIGHT`` is many-to-one: it is possible for many
|
||||
distinct branches to descend from the same parent block (and thus have the same ``ACTIVATION_HEIGHT``), but a
|
||||
specific branch can only have one parent block. Concretely, this means that if the ``ACTIVATION_HEIGHT`` of a
|
||||
network upgrade is changed for any reason (e.g. security vulnerabilities or consensus bugs are discovered),
|
||||
the ``BRANCH_ID`` MUST also be changed.
|
||||
The relationship between ``CONSENSUS_BRANCH_ID`` and ``ACTIVATION_HEIGHT`` is many-to-one: it is possible
|
||||
for many distinct consensus branches to descend from the same parent block (and thus have the same
|
||||
``ACTIVATION_HEIGHT``), but a specific consensus branch can only have one parent block. Concretely, this
|
||||
means that if the ``ACTIVATION_HEIGHT`` of a network upgrade is changed for any reason (e.g. security
|
||||
vulnerabilities or consensus bugs are discovered), the ``CONSENSUS_BRANCH_ID`` MUST also be changed.
|
||||
|
||||
Activation mechanism
|
||||
--------------------
|
||||
|
@ -139,7 +143,7 @@ network behavior or surrounding code that depends on it) MUST be gated by a bloc
|
|||
Block validation
|
||||
````````````````
|
||||
Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be
|
||||
validated under the consensus rules corresponding to the expected branch ID for that height.
|
||||
validated under the consensus rules corresponding to the expected consensus branch ID for that height.
|
||||
|
||||
Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown)
|
||||
MAY be cached, so that they can be reconsidered in the future after all their parents have been received.
|
||||
|
@ -147,25 +151,26 @@ MAY be cached, so that they can be reconsidered in the future after all their pa
|
|||
Chain reorganization
|
||||
````````````````````
|
||||
It is possible for a reorganization to occur that rolls back from after the activation height, to before that
|
||||
height. This can handled in the same way as any regular chain orphaning or reorganization, as long as the new
|
||||
chain is valid.
|
||||
height. This can be handled in the same way as any regular chain orphaning or reorganization, as long as the
|
||||
new chain is valid.
|
||||
|
||||
Post-activation upgrading
|
||||
`````````````````````````
|
||||
If a user does not upgrade their node to a compatible software version before ``ACTIVATION_HEIGHT`` is
|
||||
reached, their node will follow any pre-upgrade branch that persists, and may download blocks that are
|
||||
incompatible with the post-upgrade branch. If the user subsequently upgrades their node to a compatible
|
||||
software version, the node will consider these blocks to be invalid, and if there are a significant number of
|
||||
invalid blocks it SHOULD shut down and alert the user of the issue.
|
||||
reached, and the node continues running (which could normally only occur if the End-of-Service halt were
|
||||
bypassed), then the node will follow any pre-upgrade consensus branch that persists. In this case it may
|
||||
download blocks that are incompatible with the post-upgrade consensus branch. If the user subsequently
|
||||
upgrades their node to a compatible software version, the node will consider these blocks to be invalid,
|
||||
and if there are a significant number of invalid blocks it SHOULD shut down and alert the user of the issue.
|
||||
|
||||
Memory pool
|
||||
-----------
|
||||
|
||||
While the current chain tip height is below ``ACTIVATION_HEIGHT``, nodes SHOULD NOT accept transactions that
|
||||
will only be valid on the post-upgrade branch.
|
||||
will only be valid on the post-upgrade consensus branch.
|
||||
|
||||
When the current chain tip height reaches ``ACTIVATION_HEIGHT``, the node's local transaction memory pool
|
||||
SHOULD be cleared of transactions that will never be valid on the post-upgrade branch.
|
||||
SHOULD be cleared of transactions that will never be valid on the post-upgrade consensus branch.
|
||||
|
||||
Two-way replay protection
|
||||
-------------------------
|
||||
|
@ -173,17 +178,17 @@ Two-way replay protection
|
|||
Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the
|
||||
most significant bit of the transaction version is set to 1. [#zip-0202]_ From the perspective of old nodes,
|
||||
the transactions will have a negative version number, which is invalid under the old consensus rules.
|
||||
Enforcing this rule trivially makes old transactions invalid on the Overwinter branch.
|
||||
Enforcing this rule trivially makes old transactions invalid on the Overwinter consensus branch.
|
||||
|
||||
After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures
|
||||
committing to a specific ``BRANCH_ID``. [#zip-0143]_
|
||||
committing to a specific ``CONSENSUS_BRANCH_ID``. [#zip-0143]_
|
||||
|
||||
Wipe-out protection
|
||||
-------------------
|
||||
|
||||
Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from
|
||||
``ACTIVATION_HEIGHT``. The chain from that height will not reorganize to a pre-upgrade branch if any block in
|
||||
that branch would violate the new consensus rules.
|
||||
``ACTIVATION_HEIGHT``. The chain from that height will not reorganize to a pre-upgrade consensus branch if
|
||||
any block in that consensus branch would violate the new consensus rules.
|
||||
|
||||
Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not
|
||||
differ. For example, if the non-upgraded chain only contained empty blocks from ``ACTIVATION_HEIGHT``, and the
|
||||
|
@ -191,7 +196,7 @@ coinbase transactions were valid under both the old and new consensus rules, a w
|
|||
Overwinter network upgrade is not susceptible to this because all previous transaction versions will become
|
||||
invalid, meaning that the coinbase transactions must use the newer transaction version. More generally, this
|
||||
issue could be addressed in a future network upgrade by modifying the block header to include a commitment to
|
||||
the ``BRANCH_ID``.
|
||||
the ``CONSENSUS_BRANCH_ID``.
|
||||
|
||||
|
||||
Deployment
|
||||
|
@ -206,7 +211,7 @@ Backward compatibility
|
|||
This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this
|
||||
mechanism requires that all network participants upgrade their software to a compatible version within the
|
||||
upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade
|
||||
branch that persists.
|
||||
consensus branch that persists.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
|
@ -218,11 +223,11 @@ https://github.com/zcash/zcash/pull/2898
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#consensual-currency] https://z.cash/blog/consensual-currency.html
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#consensual-currency] `Consensual Currency. Electric Coin Company blog <https://electriccoin.co/blog/consensual-currency/>`_
|
||||
.. [#release-lifecycle]
|
||||
- https://z.cash/blog/release-cycle-and-lifetimes.html
|
||||
- https://z.cash/blog/release-cycle-update.html
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
|
||||
- `Release Cycle and Lifetimes. Electric Coin Company blog <https://electriccoin.co/blog/release-cycle-and-lifetimes/>`_
|
||||
- `Release Cycle Update. Electric Coin Company blog <https://electriccoin.co/blog/release-cycle-update/>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_
|
||||
|
|
|
@ -0,0 +1,271 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 201: Network Peer Management for Overwinter</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 201
|
||||
Title: Network Peer Management for Overwinter
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu
|
||||
Status: Final
|
||||
Category: Network
|
||||
Created: 2018-01-15
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", 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>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Overwinter</dt>
|
||||
<dd>Code-name for the first Zcash network upgrade, also known as Network Upgrade Zero.</dd>
|
||||
</dl>
|
||||
</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 an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Mechanism <a id="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>Related to:</p>
|
||||
<ul>
|
||||
<li>Transaction Signature Validation for Overwinter <a id="id4" class="footnote_reference" href="#zip-0143">2</a>.</li>
|
||||
<li>Version 3 Transaction Format for Overwinter <a id="id5" class="footnote_reference" href="#zip-0202">4</a>.</li>
|
||||
<li>Transaction Expiry <a id="id6" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
</ul>
|
||||
</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>With scheduled network upgrades, at the activation height, nodes on each consensus branch should disconnect from nodes on other consensus branches and only accept new incoming connections from nodes on the same consensus branch.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>When a new inbound connection is received or an outbound connection created, a CNode object is instantiated with the version field set to INIT_PROTO_VERSION which has a value of 209. This value is not transmitted across the network, but for legacy reasons and technical debt beyond the scope of this ZIP, this value will not be changed.</p>
|
||||
<p>Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake <a id="id7" class="footnote_reference" href="#bitcoin-version-handshake">8</a> involves "version" and "verack" messages being exchanged.:</p>
|
||||
<pre>L -> R: Send version message with the local peer's version
|
||||
R -> L: Send version message back
|
||||
R -> L: Send verack message
|
||||
R: Sets version to the minimum of the 2 versions
|
||||
L -> R: Send verack message after receiving version message from R
|
||||
L: Sets version to the minimum of the 2 versions</pre>
|
||||
<p>To send a version message, the node will invoke <code>PushVersion()</code>:</p>
|
||||
<pre>void CNode::PushVersion() {
|
||||
...
|
||||
PushMessage("version", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe, ...);
|
||||
...
|
||||
}</pre>
|
||||
<p>where <code>PROTOCOL_VERSION</code> is the highest protocol version supported by the node.</p>
|
||||
<section id="rejecting-pre-overwinter-connections"><h3><span class="section-heading">Rejecting Pre-Overwinter Connections</span><span class="section-anchor"> <a rel="bookmark" href="#rejecting-pre-overwinter-connections"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Currently, nodes will reject connections from peers with an advertised protocol version lower than the other node's minimum supported protocol version.</p>
|
||||
<p>This value is defined as:</p>
|
||||
<pre>//! disconnect from peers older than this proto version
|
||||
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
|
||||
<p>With rejection implemented as:</p>
|
||||
<pre>if (pfrom->nVersion < MIN_PEER_PROTO_VERSION)
|
||||
{
|
||||
// disconnect from old peers running protocol version we don't support.</pre>
|
||||
<p>Activation of Overwinter will take place first on testnet, and if successful, followed by mainnet.</p>
|
||||
<p>To prepare for testnet activation, Overwinter nodes will contain the following constants:</p>
|
||||
<pre>static const int PROTOCOL_VERSION = 170003;
|
||||
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
|
||||
<p>Nodes running protocol version 170003 have a testnet activation height set, but do not have a mainnet activation height set.</p>
|
||||
<p>On testnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170002.</p>
|
||||
<p>These constants allow pre-Overwinter nodes that support protocol version 170002, and Overwinter nodes (which support both protocol versions 170002 and 170003 before Overwinter activation) to remain connected until the activation.</p>
|
||||
<p>To prepare for mainnet activation, Overwinter nodes will contain the following constants:</p>
|
||||
<pre>static const int PROTOCOL_VERSION = 170005;
|
||||
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
|
||||
<p>On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the <code>NODE_BLOOM</code> service bit defined in <a id="id8" class="footnote_reference" href="#bip-0111">6</a>.)</p>
|
||||
<p>These constants allow pre-Overwinter nodes that support protocol versions 170002 to 170004 inclusive, and Overwinter nodes (which support protocol versions 170002 to 170005 inclusive before Overwinter activation) to remain connected until the activation.</p>
|
||||
<p>As these constants cannot be changed at run-time, once Overwinter activates on testnet or mainnet, Overwinter nodes should take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Overwinter nodes;</li>
|
||||
<li>disconnect any existing connections to pre-Overwinter nodes.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="network-coalescence"><h3><span class="section-heading">Network Coalescence</span><span class="section-anchor"> <a rel="bookmark" href="#network-coalescence"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to the activation of Overwinter, nodes running a pre-Overwinter protocol version (e.g. 170002) and the Overwinter protocol version (170003 for testnet; 170005 for mainnet) remain connected with the same consensus rules, but it is desirable for nodes supporting Overwinter to connect preferentially to other nodes supporting Overwinter.</p>
|
||||
<p>This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. <a id="id9" class="footnote_reference" href="#eclipse-attack">9</a></p>
|
||||
<p>To assist network coalescence before the activation height, we update the eviction process to place a higher priority on evicting Sprout nodes.</p>
|
||||
<p>Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers:</p>
|
||||
<pre>if (nInbound >= nMaxInbound)
|
||||
{
|
||||
if (!AttemptToEvictConnection(whitelisted)) {
|
||||
// No connection to evict, disconnect the new connection
|
||||
LogPrint("net", "failed to find an eviction candidate - connection dropped (full)\n");
|
||||
CloseSocket(hSocket);
|
||||
return;
|
||||
}
|
||||
}</pre>
|
||||
<p>We update this process by adding behaviour so that the set of eviction candidates will prefer pre-Overwinter nodes, when the chain tip is in a period N blocks before the activation block height, where N is defined as:</p>
|
||||
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
|
||||
<p>The eviction candidates can be modified as so:</p>
|
||||
<pre>static bool AttemptToEvictConnection(bool fPreferNewConnection) {
|
||||
...
|
||||
// Protect connections with certain characteristics
|
||||
...
|
||||
// Check version of eviction candidates...
|
||||
// If we are connected to any pre-Overwinter nodes, keep them in the eviction set and remove any Overwinter nodes
|
||||
// If we are only connected to Overwinter nodes, continue with existing behaviour.
|
||||
if (nActivationHeight > 0 &&
|
||||
height < nActivationHeight &&
|
||||
height >= nActivationHeight - NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD)
|
||||
{
|
||||
// Find any nodes which don't support Overwinter protocol version
|
||||
BOOST_FOREACH(const CNodeRef &node, vEvictionCandidates) {
|
||||
if (node->nVersion < params.vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion) {
|
||||
vTmpEvictionCandidates.push_back(node);
|
||||
}
|
||||
}
|
||||
|
||||
// Prioritize these nodes by replacing eviction set with them
|
||||
if (vTmpEvictionCandidates.size() > 0) {
|
||||
vEvictionCandidates = vTmpEvictionCandidates;
|
||||
}
|
||||
}</pre>
|
||||
<p>The existing method of disconnecting a candidate remains:</p>
|
||||
<blockquote>
|
||||
<p>vEvictionCandidates[0]->fDisconnect = true;</p>
|
||||
</blockquote>
|
||||
<p>The existing eviction process will classify and divide eviction candidates into buckets called netgroups. If a netgroup only has one peer, it will not be evicted. This means at least one pre-Overwinter node will remain connected upto the activation block height, barring any network issues or a high ban score.</p>
|
||||
</section>
|
||||
<section id="disconnecting-existing-connections"><h3><span class="section-heading">Disconnecting Existing Connections</span><span class="section-anchor"> <a rel="bookmark" href="#disconnecting-existing-connections"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>At the activation block height, an Overwinter node may still remain connected to pre-Overwinter nodes. Currently, when connecting, a node can only perform the networking handshake once, where it sends the version message before any other messages are processed. To disconnect existing pre-Overwinter connections, <code>ProcessMessage</code> is modified so that once Overwinter activates, if necessary, the protocol version of an existing peer is validated when inbound messages arrive.</p>
|
||||
<p>Example code:</p>
|
||||
<pre>bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv, int64_t nTimeReceived)
|
||||
...
|
||||
else if (pfrom->nVersion == 0)
|
||||
{
|
||||
// Must have a version message before anything else
|
||||
Misbehaving(pfrom->GetId(), 1);
|
||||
return false;
|
||||
}
|
||||
else if (strCommand == "verack")
|
||||
{
|
||||
...
|
||||
}
|
||||
|
||||
// Disconnect existing peer connection when:
|
||||
// 1. The version message has been received
|
||||
// 2. Overwinter is active
|
||||
// 3. Peer version is pre-Overwinter
|
||||
else if (NetworkUpgradeActive(GetHeight(), chainparams.GetConsensus(), Consensus::UPGRADE_OVERWINTER)
|
||||
&& (pfrom->nVersion < chainparams.GetConsensus().vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion))
|
||||
{
|
||||
LogPrintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->id, pfrom->nVersion);
|
||||
pfrom->PushMessage("reject", strCommand, REJECT_OBSOLETE,
|
||||
strprintf("Version must be %d or greater",
|
||||
chainparams.GetConsensus().vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion));
|
||||
pfrom->fDisconnect = true;
|
||||
return false;
|
||||
}</pre>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment-of-overwinter"><h2><span class="section-heading">Deployment of Overwinter</span><span class="section-anchor"> <a rel="bookmark" href="#deployment-of-overwinter"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Overwinter network upgrade defines the following network upgrade constants <a id="id10" class="footnote_reference" href="#zip-0200">3</a>:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0x5ba81b19</code></dd>
|
||||
<dt>ACTIVATION_HEIGHT</dt>
|
||||
<dd>
|
||||
<p>Testnet: 207500</p>
|
||||
<p>Mainnet: 347500</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p>The following ZIPs are deployed by Overwinter:</p>
|
||||
<ul>
|
||||
<li>ZIP 200 <a id="id11" class="footnote_reference" href="#zip-0200">3</a></li>
|
||||
<li>ZIP 201 (this ZIP)</li>
|
||||
<li>ZIP 202 <a id="id12" class="footnote_reference" href="#zip-0202">4</a></li>
|
||||
<li>ZIP 203 <a id="id13" class="footnote_reference" href="#zip-0203">5</a></li>
|
||||
<li>ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">2</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating, Overwinter and pre-Overwinter nodes are compatible and can connect to each other. However, Overwinter nodes will have a preference for connecting to other Overwinter nodes, so pre-Overwinter nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Overwinter nodes can still accept the numerically larger protocol version used by Overwinter as being valid, Overwinter nodes will always disconnect peers using lower protocol versions.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2919">https://github.com/zcash/zcash/pull/2919</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="zip-0143" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0202" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0202">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0203" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0111" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki">BIP 111: NODE_BLOOM service bit</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bitcoin-verson" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#version">https://en.bitcoin.it/wiki/Protocol_documentation#version</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bitcoin-version-handshake" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Version_Handshake">https://en.bitcoin.it/wiki/Version_Handshake</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="eclipse-attack" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="https://eprint.iacr.org/2015/263">Eclipse Attacks on Bitcoin’s Peer-to-Peer Network</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="partition-discussion" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="https://github.com/zcash/zcash/issues/2775">Partition nodes with old protocol version from network in advance of hard fork</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
32
zip-0201.rst
|
@ -2,17 +2,22 @@
|
|||
|
||||
ZIP: 201
|
||||
Title: Network Peer Management for Overwinter
|
||||
Author: Simon Liu <simon@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu
|
||||
Status: Final
|
||||
Category: Network
|
||||
Created: 2018-01-15
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described
|
||||
in RFC 2119. [#RFC2119]_
|
||||
|
||||
The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_
|
||||
The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in
|
||||
ZIP 200. [#zip-0200]_
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
|
@ -23,18 +28,21 @@ Overwinter
|
|||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Activation Mechanism [#zip-0200]_.
|
||||
This proposal defines an upgrade to the network handshake and peer management required for network upgrades
|
||||
following the Network Upgrade Mechanism [#zip-0200]_.
|
||||
|
||||
Related to:
|
||||
|
||||
- Transaction Signature Verification for Overwinter [#zip-0143]_.
|
||||
- Transaction Signature Validation for Overwinter [#zip-0143]_.
|
||||
- Version 3 Transaction Format for Overwinter [#zip-0202]_.
|
||||
- Transaction Expiry [#zip-0203]_.
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
With scheduled network upgrades, at the activation height, nodes on each branch should disconnect from nodes on other branches and only accept new incoming connections from nodes on the same branch.
|
||||
With scheduled network upgrades, at the activation height, nodes on each consensus branch should disconnect
|
||||
from nodes on other consensus branches and only accept new incoming connections from nodes on the same
|
||||
consensus branch.
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
@ -206,7 +214,7 @@ Deployment of Overwinter
|
|||
|
||||
The Overwinter network upgrade defines the following network upgrade constants [#zip-0200]_:
|
||||
|
||||
BRANCH_ID
|
||||
CONSENSUS_BRANCH_ID
|
||||
``0x5ba81b19``
|
||||
|
||||
ACTIVATION_HEIGHT
|
||||
|
@ -240,11 +248,11 @@ https://github.com/zcash/zcash/pull/2919
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
|
||||
.. [#bip-0111] `BIP 111: NODE_BLOOM service bit <https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki>`_
|
||||
.. [#bitcoin-verson] https://en.bitcoin.it/wiki/Protocol_documentation#version
|
||||
.. [#bitcoin-version-handshake] https://en.bitcoin.it/wiki/Version_Handshake
|
||||
|
|
|
@ -0,0 +1,377 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 202: Version 3 Transaction Format for Overwinter</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 202
|
||||
Title: Version 3 Transaction Format for Overwinter
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-10
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", 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>The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="id3" class="footnote_reference" href="#zip-0201">4</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 new transaction format required for Network Upgrade Mechanism <a id="id4" class="footnote_reference" href="#zip-0200">3</a> and Transaction Expiry <a id="id5" class="footnote_reference" href="#zip-0203">5</a>.</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>Zcash launched with support for upstream Bitcoin version 1 transactions and defined a new version 2 transaction format which added fields required for shielded transactions.</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Field</th>
|
||||
<th>Description</th>
|
||||
<th>Type</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>version</code></td>
|
||||
<td>positive value</td>
|
||||
<td><code>int32</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_in_count</code></td>
|
||||
<td>variable-length integer</td>
|
||||
<td><code>compactSize</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_in</code></td>
|
||||
<td>list of inputs</td>
|
||||
<td><code>vector</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_out_count</code></td>
|
||||
<td>variable-length integer</td>
|
||||
<td><code>compactSize</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_out</code></td>
|
||||
<td>list of outputs</td>
|
||||
<td><code>vector</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>lock_time</code></td>
|
||||
<td>block height or timestamp</td>
|
||||
<td><code>uint32</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>nJoinSplit</code></td>
|
||||
<td>variable-length integer</td>
|
||||
<td><code>compactSize</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>vJoinSplit</code></td>
|
||||
<td>list of joinsplits</td>
|
||||
<td><code>vector</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>joinSplitPubKey</code></td>
|
||||
<td>joinsplit_sig public key</td>
|
||||
<td>32 bytes</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>joinSplitSig</code></td>
|
||||
<td>signature</td>
|
||||
<td>64 bytes</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>A new transaction format is required to:</p>
|
||||
<ul>
|
||||
<li>support safe network upgrades as specified in Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a>;</li>
|
||||
<li>provide replay protection between pre-Overwinter and Overwinter consensus branches during upgrades;</li>
|
||||
<li>provide replay protection between different consensus branches post-Overwinter;</li>
|
||||
<li>enable a consensus branch to support multiple transaction version formats;</li>
|
||||
<li>ensure transaction formats are parsed uniquely across parallel consensus branches;</li>
|
||||
<li>support transaction expiry <a id="id7" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="transaction-format-version-3"><h3><span class="section-heading">Transaction format version 3</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-format-version-3"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A new version 3 transaction format will be introduced for Overwinter.</p>
|
||||
<p>The version 3 format differs from the version 2 format in the following ways:</p>
|
||||
<ul>
|
||||
<li>header (first four bytes, little-endian encoded)
|
||||
<ul>
|
||||
<li><code>fOverwintered</code> flag : bit 31, must be set</li>
|
||||
<li><code>nVersion</code> : bits 30-0, positive integer</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><code>nVersionGroupId</code></li>
|
||||
<li><code>nExpiryHeight</code></li>
|
||||
</ul>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Field</th>
|
||||
<th>Description</th>
|
||||
<th>Type</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>>= 3</td>
|
||||
<td>header</td>
|
||||
<td>
|
||||
<p>contains:</p>
|
||||
<ul>
|
||||
<li><code>fOverwintered</code> flag (bit 31, always set)</li>
|
||||
<li><code>nVersion</code> (bits 30-0)</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td><code>uint32</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 3</td>
|
||||
<td><code>nVersionGroupId</code></td>
|
||||
<td>version group ID (not zero)</td>
|
||||
<td><code>uint32</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_in_count</code></td>
|
||||
<td>variable-length integer</td>
|
||||
<td><code>compactSize</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_in</code></td>
|
||||
<td>list of inputs</td>
|
||||
<td><code>vector</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_out_count</code></td>
|
||||
<td>variable-length integer</td>
|
||||
<td><code>compactSize</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>tx_out</code></td>
|
||||
<td>list of outputs</td>
|
||||
<td><code>vector</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 1</td>
|
||||
<td><code>lock_time</code></td>
|
||||
<td>block height or timestamp</td>
|
||||
<td><code>uint32</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 3</td>
|
||||
<td><code>expiryHeight</code></td>
|
||||
<td>block height</td>
|
||||
<td><code>uint32</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>nJoinSplit</code></td>
|
||||
<td>variable-length integer</td>
|
||||
<td><code>compactSize</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>vJoinSplit</code></td>
|
||||
<td>list of joinsplits</td>
|
||||
<td><code>vector</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>joinSplitPubKey</code></td>
|
||||
<td>joinsplit_sig public key</td>
|
||||
<td>32 bytes</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>>= 2</td>
|
||||
<td><code>joinSplitSig</code></td>
|
||||
<td>signature</td>
|
||||
<td>64 bytes</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<section id="header-field"><h3><span class="section-heading">Header Field</span><span class="section-anchor"> <a rel="bookmark" href="#header-field"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The first four bytes of pre-Overwinter and Overwinter transactions are little-endian encoded.</p>
|
||||
<p>Version 1 transaction (txid <a href="https://blockchair.com/zcash/transaction/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061">5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061</a>)</p>
|
||||
<ul>
|
||||
<li>begins with little-endian byte sequence [0x01, 0x00, 0x00, 0x00];</li>
|
||||
<li>deserialized as 32-bit signed integer with decimal value of 1.</li>
|
||||
</ul>
|
||||
<p>Version 2 transaction (txid <a href="https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b">4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b</a>)</p>
|
||||
<ul>
|
||||
<li>begins with little-endian byte sequence [0x02, 0x00, 0x00, 0x00];</li>
|
||||
<li>deserialized as 32-bit signed integer with decimal value of 2.</li>
|
||||
</ul>
|
||||
<p>Transaction parsers for versions of Zcash prior to Overwinter, and for most other Bitcoin forks, require the transaction version number to be positive.</p>
|
||||
<p>With the version 3 transaction format, the first four bytes of a serialized transaction, the 32-bit header, are made up of two fields as shown in the table above:</p>
|
||||
<ul>
|
||||
<li>1-bit <code>fOverwintered</code> flag, must be set;</li>
|
||||
<li>31-bit unsigned int for the version.</li>
|
||||
</ul>
|
||||
<p>Pre-Overwinter parsers will deserialize these four bytes as a 32-bit signed integer. With two's complement integers, the most significant bit indicates whether an integer is positive or negative. With the Overwinter flag set, the transaction version will be negative, resulting in pre-Overwinter parsers rejecting the transaction as invalid. This provides transaction replay protection between pre-Overwinter and Overwinter software.</p>
|
||||
<p>Consider the following example of a serialized version 3 transaction.</p>
|
||||
<p>Pre-Overwinter parser:</p>
|
||||
<ul>
|
||||
<li>data begins with little-endian byte sequence: [0x03, 0x00, 0x00, 0x80];</li>
|
||||
<li>deserialized as 32-bit signed integer.
|
||||
<ul>
|
||||
<li>with hexadecimal value of 0x80000003 (most significant bit is set);</li>
|
||||
<li>decimal value of -2147483645.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Legacy parsers will expect the version to be a positive value, such as 1 or 2, and will thus reject the Overwinter transaction as invalid.</p>
|
||||
<p>Overwinter parser:</p>
|
||||
<ul>
|
||||
<li>data begins with little-endian byte sequence: [0x03, 0x00, 0x00, 0x80];</li>
|
||||
<li>deserialized as 32-bit unsigned integer
|
||||
<ul>
|
||||
<li>with binary value of 0b10000000000000000000000000000011;</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>the 32-bits are decomposed into two fields:
|
||||
<ul>
|
||||
<li><code>fOverwintered</code> flag (bit 31) as a boolean, expected to be set;</li>
|
||||
<li>version (bits 30 - bit 0) as an unsigned integer, expected to have a decimal value of 3.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Overwinter parsers will accept the transaction as valid as the most significant bit of the header has been set. By masking off (unsetting) the most significant bit, the parser can retrieve the transaction version number:</p>
|
||||
<pre>0x80000003 & 0x7FFFFFFF = 0x00000003 = 3</pre>
|
||||
</section>
|
||||
<section id="version-group-id"><h3><span class="section-heading">Version Group ID</span><span class="section-anchor"> <a rel="bookmark" href="#version-group-id"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The version group ID is a non-zero, random and unique identifier, of type <code>uint32</code>, assigned to a transaction format version, or a group of soft-forking transaction format versions. The version group ID helps nodes disambiguate between consensus branches using the same version number.</p>
|
||||
<p>That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another consensus branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own unique version group ID, so that they can reject v3 transactions with unknown version group IDs.</p>
|
||||
<p>The combination of transaction version and version group ID, <code>nVersion || nVersionGroupId</code>, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed.</p>
|
||||
<p>By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group ID will be assigned to that transaction version.</p>
|
||||
<p>However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.</p>
|
||||
</section>
|
||||
<section id="expiry-height"><h3><span class="section-heading">Expiry Height</span><span class="section-anchor"> <a rel="bookmark" href="#expiry-height"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="id8" class="footnote_reference" href="#zip-0203">5</a>, stores the block height after which a transaction can no longer be mined.</p>
|
||||
</section>
|
||||
<section id="transaction-validation"><h3><span class="section-heading">Transaction Validation</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A valid Overwinter transaction intended for Zcash MUST have:</p>
|
||||
<ul>
|
||||
<li>version number 3; and</li>
|
||||
<li>version group ID 0x03C48270; and</li>
|
||||
<li><code>fOverwintered</code> flag set.</li>
|
||||
</ul>
|
||||
<p>Overwinter validators MUST reject transactions for violating consensus rules if:</p>
|
||||
<ul>
|
||||
<li>the <code>fOverwintered</code> flag is not set; or</li>
|
||||
<li>the version group ID is unknown; or</li>
|
||||
<li>the version number is unknown.</li>
|
||||
</ul>
|
||||
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id9" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The comments and code samples in this section apply to the reference C++ implementation of Zcash. Other implementations may vary.</p>
|
||||
<section id="transaction-version"><h3><span class="section-heading">Transaction Version</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-version"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Transaction version remains a positive value. The main Zcash chain will follow convention and continue to order transaction versions in an ascending order.</p>
|
||||
<p>Tests can continue to check for the existence of forwards-compatible transaction fields by checking the transaction version using comparison operators:</p>
|
||||
<pre>if (tx.nVersion >= 2) {
|
||||
for (int js = 0; js < joinsplits; js++) {
|
||||
...
|
||||
}
|
||||
}</pre>
|
||||
<p>When (de)serializing v3 transactions, the version group ID must also be checked in case the transaction is intended for a consensus branch which has a different format for its version 3 transaction:</p>
|
||||
<pre>if (tx.nVersion == 3 && tx.nVersionGroupId == OVERWINTER_VERSION_GROUP_ID) {
|
||||
auto expiryHeight = tx.nExpiryHeight;
|
||||
}</pre>
|
||||
<p>Tests can continue to set the version to zero as an error condition:</p>
|
||||
<pre>mtx.nVersion = 0</pre>
|
||||
</section>
|
||||
<section id="overwinter-validation"><h3><span class="section-heading">Overwinter Validation</span><span class="section-anchor"> <a rel="bookmark" href="#overwinter-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>To test if the format of an Overwinter transaction is v3 or not:</p>
|
||||
<pre>if (tx.fOverwintered && tx.nVersion == 3) {
|
||||
// Valid v3 format transaction
|
||||
}</pre>
|
||||
<p>This only tests that the format of the transaction matches the v3 specification described above.</p>
|
||||
<p>To test if the format of an Overwinter transaction is both v3 and the transaction itself is intended for the client's chain:</p>
|
||||
<pre>if (tx.fOverwintered &&
|
||||
tx.nVersionGroupId == OVERWINTER_VERSION_GROUP_ID) &&
|
||||
tx.nVersion == 3) {
|
||||
// Valid v3 format transaction intended for this client's chain
|
||||
}</pre>
|
||||
<p>It is expected that this test involving <code>nVersionGroupId</code> is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.</p>
|
||||
<p>However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.</p>
|
||||
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id10" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="id11" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
</section>
|
||||
<section id="backwards-compatibility"><h2><span class="section-heading">Backwards compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backwards-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change" <a id="id12" class="footnote_reference" href="#zip-0200">3</a> between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.</p>
|
||||
<p>Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group IDs.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2925">https://github.com/zcash/zcash/pull/2925</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="zip-0143" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0201">ZIP 201: Network Handshaking for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0203" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
97
zip-0202.rst
|
@ -2,24 +2,31 @@
|
|||
|
||||
ZIP: 202
|
||||
Title: Version 3 Transaction Format for Overwinter
|
||||
Author: Simon Liu <simon@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-10
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in
|
||||
RFC 2119. [#RFC2119]_
|
||||
|
||||
The terms "branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_
|
||||
The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are
|
||||
to be interpreted as described in ZIP 200. [#zip-0200]_
|
||||
|
||||
The term "Overwinter" in this document is to be interpreted as described in ZIP 201. [#zip-0201]_
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines a new transaction format required for Network Upgrade Activation Mechanism [#zip-0200]_ and Transaction Expiry [#zip-0203]_.
|
||||
This proposal defines a new transaction format required for Network Upgrade Mechanism [#zip-0200]_ and Transaction Expiry [#zip-0203]_.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
@ -41,16 +48,16 @@ Version Field Description Type
|
|||
>= 2 ``joinSplitSig`` signature 64 bytes
|
||||
======== ====================== =========================== ===============
|
||||
|
||||
|
||||
A new transaction format is required to:
|
||||
|
||||
* support safe network upgrades as specified in Network Upgrade Activation Mechanism [#zip-0200]_;
|
||||
* provide replay protection between pre-Overwinter and Overwinter branches during upgrades;
|
||||
* provide replay protection between different branches post-Overwinter;
|
||||
* enable a branch to support multiple transaction version formats;
|
||||
* ensure transaction formats are parsed uniquely across parallel branches;
|
||||
* support safe network upgrades as specified in Network Upgrade Mechanism [#zip-0200]_;
|
||||
* provide replay protection between pre-Overwinter and Overwinter consensus branches during upgrades;
|
||||
* provide replay protection between different consensus branches post-Overwinter;
|
||||
* enable a consensus branch to support multiple transaction version formats;
|
||||
* ensure transaction formats are parsed uniquely across parallel consensus branches;
|
||||
* support transaction expiry [#zip-0203]_.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
|
@ -76,7 +83,7 @@ Version Field Description Type
|
|||
- ``fOverwintered`` flag
|
||||
(bit 31, always set)
|
||||
- ``nVersion`` (bits 30-0)
|
||||
>= 3 ``nVersionGroupId`` version group id (not zero) ``uint32``
|
||||
>= 3 ``nVersionGroupId`` version group ID (not zero) ``uint32``
|
||||
>= 1 ``tx_in_count`` variable-length integer ``compactSize``
|
||||
>= 1 ``tx_in`` list of inputs ``vector``
|
||||
>= 1 ``tx_out_count`` variable-length integer ``compactSize``
|
||||
|
@ -95,12 +102,12 @@ Header Field
|
|||
|
||||
The first four bytes of pre-Overwinter and Overwinter transactions are little-endian encoded.
|
||||
|
||||
Version 1 transaction (txid 5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061 https://zcash.blockexplorer.com/tx/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061)
|
||||
Version 1 transaction (txid `5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061 <https://blockchair.com/zcash/transaction/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061>`_)
|
||||
|
||||
* begins with little-endian byte sequence [0x01, 0x00, 0x00, 0x00];
|
||||
* deserialized as 32-bit signed integer with decimal value of 1.
|
||||
|
||||
Version 2 transaction (txid 4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b https://zcash.blockexplorer.com/tx/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b)
|
||||
Version 2 transaction (txid `4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b <https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b>`_)
|
||||
|
||||
* begins with little-endian byte sequence [0x02, 0x00, 0x00, 0x00];
|
||||
* deserialized as 32-bit signed integer with decimal value of 2.
|
||||
|
@ -141,18 +148,29 @@ Overwinter parsers will accept the transaction as valid as the most significant
|
|||
|
||||
0x80000003 & 0x7FFFFFFF = 0x00000003 = 3
|
||||
|
||||
Version Group Id
|
||||
Version Group ID
|
||||
----------------
|
||||
|
||||
The version group id is a non-zero, random and unique identifier, of type ``uint32``, assigned to a transaction format version, or a group of soft-forking transaction format versions. The version group id helps nodes disambiguate between branches using the same version number.
|
||||
The version group ID is a non-zero, random and unique identifier, of type ``uint32``, assigned
|
||||
to a transaction format version, or a group of soft-forking transaction format versions. The
|
||||
version group ID helps nodes disambiguate between consensus branches using the same version number.
|
||||
|
||||
That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own unique version group id, so that they can reject v3 transactions with unknown version group ids.
|
||||
That is, it prevents a client on one branch of the network from attempting to parse transactions
|
||||
intended for another consensus branch, in the situation where the transactions share the same
|
||||
format version number but are actually specified differently. For example, Zcash and a clone of
|
||||
Zcash might both define their own custom v3 transaction formats, but each will have its own
|
||||
unique version group ID, so that they can reject v3 transactions with unknown version group IDs.
|
||||
|
||||
The combination of transaction version and version group id, ``nVersion || nVersionGroupId``, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed.
|
||||
The combination of transaction version and version group ID, ``nVersion || nVersionGroupId``,
|
||||
uniquely defines the transaction format, thus enabling parsers to reject transactions from outside
|
||||
the client's chain which cannot be parsed.
|
||||
|
||||
By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group id will be assigned to that transaction version.
|
||||
By convention, it is expected that when introducing a new transaction version requiring a network
|
||||
upgrade, a new unique version group ID will be assigned to that transaction version.
|
||||
|
||||
However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group id MAY be re-used.
|
||||
However, if a new transaction version can be correctly parsed according to the format of a
|
||||
preceding version (that is, it only restricts the format, or defines fields that were previously
|
||||
reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.
|
||||
|
||||
Expiry Height
|
||||
-------------
|
||||
|
@ -160,21 +178,22 @@ Expiry Height
|
|||
The expiry height field, as defined in the Transaction Expiry ZIP [#zip-0203]_, stores the block height after which a transaction can no longer be mined.
|
||||
|
||||
Transaction Validation
|
||||
======================
|
||||
----------------------
|
||||
|
||||
A valid Overwinter transaction intended for Zcash MUST have:
|
||||
|
||||
- version number 3; and
|
||||
- version group id 0x03C48270 [#versiongroupid]_; and
|
||||
- version group ID 0x03C48270; and
|
||||
- ``fOverwintered`` flag set.
|
||||
|
||||
Overwinter validators MUST reject transactions for violating consensus rules if:
|
||||
|
||||
- the ``fOverwintered`` flag is not set; or
|
||||
- the version group id is unknown; or
|
||||
- the version group ID is unknown; or
|
||||
- the version number is unknown.
|
||||
|
||||
Validation of version 3 transactions MUST use the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_.
|
||||
Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP [#zip-0143]_.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
@ -194,7 +213,9 @@ Tests can continue to check for the existence of forwards-compatible transaction
|
|||
}
|
||||
}
|
||||
|
||||
When (de)serializing v3 transactions, the version group id must also be checked in case the transaction is intended for a branch which has a different format for its version 3 transaction::
|
||||
When (de)serializing v3 transactions, the version group ID must also be checked in case the
|
||||
transaction is intended for a consensus branch which has a different format for its version 3
|
||||
transaction::
|
||||
|
||||
if (tx.nVersion == 3 && tx.nVersionGroupId == OVERWINTER_VERSION_GROUP_ID) {
|
||||
auto expiryHeight = tx.nExpiryHeight;
|
||||
|
@ -226,21 +247,29 @@ To test if the format of an Overwinter transaction is both v3 and the transactio
|
|||
|
||||
It is expected that this test involving ``nVersionGroupId`` is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.
|
||||
|
||||
However, it's possible that a clone of Zcash is using the same version group id and passes the conditional.
|
||||
However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.
|
||||
|
||||
Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP [#zip-0143]_.
|
||||
|
||||
Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_.
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in [#zip-0201]_.
|
||||
|
||||
|
||||
Backwards compatibility
|
||||
=======================
|
||||
|
||||
This proposal intentionally creates what is known as a "bilateral consensus rule change" [#zip-0200]_ between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.
|
||||
This proposal intentionally creates what is known as a "bilateral consensus rule change"
|
||||
[#zip-0200]_ between pre-Overwinter software and Overwinter-compatible software. Use of
|
||||
this new transaction format requires that all network participants upgrade their software
|
||||
to a compatible version within the upgrade window. Pre-Overwinter software will treat
|
||||
Overwinter transactions as invalid.
|
||||
|
||||
Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group ids.
|
||||
Once Overwinter has activated, Overwinter-compatible software will reject version 1 and
|
||||
version 2 transactions, and will only accept transactions based upon supported transaction
|
||||
version numbers and recognized version group IDs.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
|
@ -248,12 +277,12 @@ Reference Implementation
|
|||
|
||||
https://github.com/zcash/zcash/pull/2925
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
|
||||
.. [#versiongroupid] `OVERWINTER_VERSION_GROUP_ID <https://github.com/zcash/zcash/pull/2925/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR311>`_
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
|
||||
|
|
|
@ -0,0 +1,114 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 203: Transaction Expiry</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: 203
|
||||
Title: Transaction Expiry
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Jay Graber
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-09
|
||||
License: MIT</pre>
|
||||
<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 is a Standards ZIP describing a new consensus rule to set an expiration time after which a transaction cannot be mined. If it is not mined within that time, the transaction will be removed from nodes' mempools.</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>Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing a transaction to set a block height after which it cannot be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent.</p>
|
||||
<p>Advantages include optimizing mempool performance by removing transactions that will not be mined, and potentially simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states, since transactions not committed to the chain could expire and become invalid after a period of time.</p>
|
||||
<p>If the expiry is at block height
|
||||
<span class="math">\(N\)</span>
|
||||
, then the transaction must be included in block
|
||||
<span class="math">\(N\)</span>
|
||||
or earlier. Block
|
||||
<span class="math">\(N+1\)</span>
|
||||
will be too late, and the transaction will be removed from the mempool.</p>
|
||||
<p>The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than
|
||||
<span class="math">\(N\)</span>
|
||||
, and blocks that include expired transactions will not be considered valid.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Transactions will have a new field, <code>nExpiryHeight</code>, which will set the block height after which transactions will be removed from the mempool if they have not been mined.</p>
|
||||
<p>The data type for <code>nExpiryHeight</code> will be <code>uint32_t</code>. <code>nExpiryHeight</code> will never be a UNIX timestamp, unlike <code>nLockTime</code> values, and thus the maximum expiry height will be 499999999 (but see the exception for coinbase transactions described in <a href="#changes-for-nu5">Changes for NU5</a>).</p>
|
||||
<p>Note: a previous version of this ZIP incorrectly specified an interaction between <code>nExpiryHeight</code> and <code>nLockTime</code> that was never implemented.</p>
|
||||
<p>For the example below, the last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool.</p>
|
||||
<pre>"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f",
|
||||
"version": 3,
|
||||
"locktime": 2089,
|
||||
"expiryheight": 3539,</pre>
|
||||
<p>Default: 20 blocks from the current height, or about 50 minutes at 2.5-minute target block spacing. A configuration option can be used to set the user's default.</p>
|
||||
<p>Minimum: No minimum</p>
|
||||
<p>Maximum: 499999999, which is about 1185 years from now at 75 seconds/block.</p>
|
||||
<p>No limit: To set no limit on transactions (so that they do not expire), <code>nExpiryHeight</code> should be set to 0.</p>
|
||||
<p>Coinbase: <code>nExpiryHeight</code> on coinbase transactions is ignored, and is set to 0 by convention.</p>
|
||||
<p>Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions.</p>
|
||||
<section id="changes-for-blossom"><h3><span class="section-heading">Changes for Blossom</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-blossom"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>On Blossom activation <a id="id1" class="footnote_reference" href="#zip-0206">2</a>, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.</p>
|
||||
</section>
|
||||
<section id="changes-for-nu5"><h3><span class="section-heading">Changes for NU5</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-nu5"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="id2" class="footnote_reference" href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">4</a>.</p>
|
||||
</section>
|
||||
<section id="wallet-behavior-and-ui"><h3><span class="section-heading">Wallet behavior and UI</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-behavior-and-ui"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.</p>
|
||||
<p>Wallet should notify the user of expired transactions that must be re-sent.</p>
|
||||
</section>
|
||||
<section id="rpc"><h3><span class="section-heading">RPC</span><span class="section-anchor"> <a rel="bookmark" href="#rpc"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>For Overwinter, transaction expiry will be set to a default that can be overridden by a flag <cite>txexpirydelta</cite> set in the config file.</p>
|
||||
<p><code>-txexpirydelta=</code> set the number of blocks after which a transaction that has not been mined will become invalid</p>
|
||||
<p>To view: <cite>listtransactions</cite> has a new filter attribute, showing expired transactions only:</p>
|
||||
<pre>listtransactions "*" 10 0 "expired"</pre>
|
||||
<p>WalletTxToJSON shows a boolean expired true/false.</p>
|
||||
</section>
|
||||
<section id="config"><h3><span class="section-heading">Config</span><span class="section-anchor"> <a rel="bookmark" href="#config"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The default will be user-configurable with the option <cite>txexpirydelta</cite>.</p>
|
||||
<p><cite>--txexpirydelta=100</cite></p>
|
||||
</section>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This feature will be deployed with Overwinter. The activation blockheight proposal is in <a id="id4" class="footnote_reference" href="#zip-0201">1</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/2874">https://github.com/zcash/zcash/pull/2874</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>1</th>
|
||||
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0206" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0252" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-txnencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
127
zip-0203.rst
|
@ -2,85 +2,137 @@
|
|||
|
||||
ZIP: 203
|
||||
Title: Transaction Expiry
|
||||
Author: Jay Graber <jay@z.cash>
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Jay Graber
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2018-01-09
|
||||
License: MIT
|
||||
|
||||
|
||||
Abstract
|
||||
===========
|
||||
========
|
||||
|
||||
This is a Standards ZIP describing a new consensus rule to set an expiration time after
|
||||
which a transaction cannot be mined. If it is not mined within that time, the transaction
|
||||
will be removed from nodes' mempools.
|
||||
|
||||
This is a Standards ZIP describing a new consensus rule to set an expiration time after which a transaction cannot be mined. If it is not mined within that time, the transaction will be removed from nodes' mempools.
|
||||
|
||||
Motivation
|
||||
===========
|
||||
==========
|
||||
|
||||
Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing a transaction to set a block height after which it cannot be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent.
|
||||
Transactions that have insufficient fees are often not mined. This indeterminism is a
|
||||
source of confusion for users and wallets. Allowing a transaction to set a block height
|
||||
after which it cannot be mined would provide certainty around how long a transaction has
|
||||
to confirm before it is rejected by the network and must be re-sent.
|
||||
|
||||
Advantages include optimizing mempool performance by removing transactions that will not be mined, and potentially simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states, since transactions not committed to the chain could expire and become invalid after a period of time.
|
||||
Advantages include optimizing mempool performance by removing transactions that will not
|
||||
be mined, and potentially simplifying bidirectional payment channels by reducing the need
|
||||
to store and compress revocations for past states, since transactions not committed to the
|
||||
chain could expire and become invalid after a period of time.
|
||||
|
||||
If the expiry is at block height N, then the transaction must be included in block N or earlier. Block N+1 will be too late, and the transaction will be removed from the mempool.
|
||||
If the expiry is at block height :math:`N`, then the transaction must be included in block
|
||||
:math:`N` or earlier. Block :math:`N+1` will be too late, and the transaction will be
|
||||
removed from the mempool.
|
||||
|
||||
The new consensus rule will enforce that the transaction will not be considered valid if
|
||||
included in block of height greater than :math:`N`, and blocks that include expired
|
||||
transactions will not be considered valid.
|
||||
|
||||
The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than N, and blocks that include expired transactions will not be considered valid.
|
||||
|
||||
Specification
|
||||
===============
|
||||
=============
|
||||
|
||||
Transactions will have a new field, ``nExpiryHeight``, which will set the block height after which transactions will be removed from the mempool if they have not been mined.
|
||||
Transactions will have a new field, ``nExpiryHeight``, which will set the block height
|
||||
after which transactions will be removed from the mempool if they have not been mined.
|
||||
|
||||
The data type for ``nExpiryHeight`` will be ``uint32_t``. If used in combination with ``nLockTime``, both ``nLockTime`` and ``nExpiryHeight`` must be block heights. ``nExpiryHeight`` will never be a UNIX timestamp, unlike ``nLockTime`` values, and thus the maximum expiry height will be 499999999.
|
||||
The data type for ``nExpiryHeight`` will be ``uint32_t``. ``nExpiryHeight`` will never
|
||||
be a UNIX timestamp, unlike ``nLockTime`` values, and thus the maximum expiry height
|
||||
will be 499999999 (but see the exception for coinbase transactions described in
|
||||
`Changes for NU5`_).
|
||||
|
||||
For the example below, the last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool.
|
||||
Note: a previous version of this ZIP incorrectly specified an interaction between
|
||||
``nExpiryHeight`` and ``nLockTime`` that was never implemented.
|
||||
|
||||
```
|
||||
"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f",
|
||||
"version": 3,
|
||||
"locktime": 2089,
|
||||
"expiryheight": 3539,
|
||||
```
|
||||
For the example below, the last block that the transaction below could possibly be
|
||||
included in is 3539. After that, it will be removed from the mempool.
|
||||
|
||||
::
|
||||
|
||||
"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f",
|
||||
"version": 3,
|
||||
"locktime": 2089,
|
||||
"expiryheight": 3539,
|
||||
|
||||
Default: 20 blocks from the current height, or about 50 minutes at 2.5-minute target
|
||||
block spacing. A configuration option can be used to set the user's default.
|
||||
|
||||
Default: 20 blocks, or about 1 hour assuming 2.5 minute block times. A configuration option can be used to set the user's default.
|
||||
Minimum: No minimum
|
||||
Maximum: 499999999, about 380 years
|
||||
No limit: To set no limit on transactions (so that they do not expire), ``nExpiryHeight`` should be set to 0.
|
||||
Coinbase: ``nExpiryHeight`` on coinbase transactions is ignored, and is set to 0 by convention.
|
||||
|
||||
Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions.
|
||||
Maximum: 499999999, which is about 1185 years from now at 75 seconds/block.
|
||||
|
||||
No limit: To set no limit on transactions (so that they do not expire), ``nExpiryHeight``
|
||||
should be set to 0.
|
||||
|
||||
Coinbase: ``nExpiryHeight`` on coinbase transactions is ignored, and is set to 0 by
|
||||
convention.
|
||||
|
||||
Every time a transaction expires and should be removed from the mempool, so should all
|
||||
of its dependent transactions.
|
||||
|
||||
Changes for Blossom
|
||||
-------------------
|
||||
|
||||
On Blossom activation [#zip-0206]_, the default changes to 40 blocks from the current
|
||||
height, which still represents about 50 minutes at the revised 75-second target block
|
||||
spacing.
|
||||
|
||||
Changes for NU5
|
||||
---------------
|
||||
|
||||
As mentioned above, ``nExpiryHeight`` is ignored for coinbase transactions. However, from
|
||||
NU5 activation [#zip-0252]_, the ``nExpiryHeight`` field of a coinbase transaction MUST
|
||||
be set equal to the block height. Also, for coinbase transactions only, the bound of
|
||||
499999999 on ``nExpiryHeight`` is removed. The motivation is to ensure that transaction
|
||||
IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol
|
||||
specification [#protocol-txnencoding]_.
|
||||
|
||||
Wallet behavior and UI
|
||||
-----------------------
|
||||
----------------------
|
||||
|
||||
With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.
|
||||
With the addition of this feature, zero-confirmation transactions with an expiration block
|
||||
height set will have even less guarantee of inclusion. This means that UIs and services
|
||||
must never rely on zero-confirmation transactions in Zcash.
|
||||
|
||||
Wallet should notify the user of expired transactions that must be re-sent.
|
||||
Wallet should notify the user of expired transactions that must be re-sent.
|
||||
|
||||
RPC
|
||||
-----
|
||||
---
|
||||
|
||||
To make changes to the sendtoaddress and z_sendmany commands backwards compatible for future changes, keyword arguments should be accepted by the RPC interface.
|
||||
For Overwinter, transaction expiry will be set to a default that can be overridden by a
|
||||
flag `txexpirydelta` set in the config file.
|
||||
|
||||
For Overwinter, tx expiry will be set to a default that can be overridden by a flag `txexpirydelta` set in the config file.
|
||||
``-txexpirydelta=`` set the number of blocks after which a transaction that has not been
|
||||
mined will become invalid
|
||||
|
||||
-txexpirydelta= set the number of blocks after which a transaction that has not been mined will become invalid
|
||||
To view: `listtransactions` has a new filter attribute, showing expired transactions only::
|
||||
|
||||
To view:
|
||||
listtransactions has a new filter attribute, showing expired transactions only:
|
||||
listtransactions "*" 10 0 "expired"
|
||||
|
||||
WalletTxToJSON shows a boolean expired true/false.
|
||||
|
||||
Config
|
||||
-------
|
||||
------
|
||||
|
||||
The default will be user-configurable with the option `txexpirydelta`.
|
||||
|
||||
`--txexpirydelta=100`
|
||||
|
||||
Deployment
|
||||
------------
|
||||
----------
|
||||
|
||||
This feature will be deployed with Overwinter. The activation blockheight proposal is in [#zip-0201]_.
|
||||
This feature will be deployed with Overwinter. The activation blockheight proposal is in
|
||||
[#zip-0201]_.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
|
@ -92,4 +144,7 @@ https://github.com/zcash/zcash/pull/2874
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
|
||||
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
|
||||
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
|
||||
|
|
|
@ -0,0 +1,16 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 204: Zcash P2P Network Protocol</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 204
|
||||
Title: Zcash P2P Network Protocol
|
||||
Status: Reserved
|
||||
Category: Network
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/352">https://github.com/zcash/zips/issues/352</a>></pre>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,7 @@
|
|||
::
|
||||
|
||||
ZIP: 204
|
||||
Title: Zcash P2P Network Protocol
|
||||
Status: Reserved
|
||||
Category: Network
|
||||
Discussions-To: <https://github.com/zcash/zips/issues/352>
|
|
@ -0,0 +1,152 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 205: Deployment of the Sapling Network Upgrade</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 205
|
||||
Title: Deployment of the Sapling Network Upgrade
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
Created: 2018-10-08
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">7</a></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">3</a>.</p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Sapling</dt>
|
||||
<dd>Code-name for the second Zcash network upgrade, also known as Network Upgrade 1.</dd>
|
||||
</dl>
|
||||
</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 the deployment of the Sapling network upgrade. In addition, it describes a hard fork that occurred on Testnet to allow "minimum-difficulty" blocks.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="sapling-deployment"><h3><span class="section-heading">Sapling deployment</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Sapling consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a>.</li>
|
||||
<li>Transaction Signature Validation for Sapling <a id="id5" class="footnote_reference" href="#zip-0243">9</a>.</li>
|
||||
<li>Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">7</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in <a id="id7" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id8" class="footnote_reference" href="#zip-0200">7</a> are defined for the Sapling upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0x76b809bb</code></dd>
|
||||
<dt>ACTIVATION_HEIGHT (Sapling)</dt>
|
||||
<dd>
|
||||
<p>Testnet: 280000</p>
|
||||
<p>Mainnet: 419200</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p>On Testnet, Sapling had activated prior to this height, but that consensus branch was rolled back. A subsequent hard fork occurred on Testnet, changing the difficulty algorithm to accept "minimum-difficulty" blocks under certain conditions starting at block height 299188.</p>
|
||||
<p>On both Mainnet and Testnet, Sapling-compatible nodes MUST advertise protocol version 170007 or later. The minimum peer protocol version that Sapling-compatible nodes will connect to, remains 170002.</p>
|
||||
<p>Pre-Sapling nodes are defined as nodes advertising a protocol version less than 170007.</p>
|
||||
<p>Approximately three days (defined in terms of block height) before the Sapling activation height, Sapling-compatible nodes will change the behaviour of their peer connection logic in order to prefer pre-Sapling peers for eviction from the set of peer connections.</p>
|
||||
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id9" class="footnote_reference" href="#zip-0201">8</a>.</p>
|
||||
<p>Once Sapling activates on Testnet or Mainnet, Sapling nodes SHOULD take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Sapling nodes;</li>
|
||||
<li>disconnect any existing connections to pre-Sapling nodes.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Section 7.6.3 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">5</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
|
||||
<p>This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id12" class="footnote_reference" href="#protocol-nbits">6</a>.</p>
|
||||
<p>Note: a previous revision of this ZIP incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
|
||||
<p>This change does not affect Mainnet.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating, Sapling and pre-Sapling nodes are compatible and can connect to each other. However, Sapling nodes will have a preference for connecting to other Sapling nodes, so pre-Sapling nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Sapling nodes can still accept the numerically larger protocol version used by Sapling as being valid, Sapling nodes will always disconnect peers using lower protocol versions.</p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Sapling consensus rules was implemented in zcashd version 2.0.0. The majority of support for RPC calls and persistence of Sapling z-addresses was implemented in version 2.0.1. Both of these versions advertise protocol version 170007.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-constants" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-diffadjustment" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-nbits" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0243" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0243">ZIP 243: Transaction Signature Validation for Sapling</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,154 @@
|
|||
::
|
||||
|
||||
ZIP: 205
|
||||
Title: Deployment of the Sapling Network Upgrade
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
Created: 2018-10-08
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST" and "SHOULD" in this document are to be interpreted as
|
||||
described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The terms "consensus branch" and "network upgrade" in this document are to be
|
||||
interpreted as described in ZIP 200. [#zip-0200]_
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
Sapling
|
||||
Code-name for the second Zcash network upgrade, also known as Network Upgrade 1.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines the deployment of the Sapling network upgrade. In addition,
|
||||
it describes a hard fork that occurred on Testnet to allow "minimum-difficulty"
|
||||
blocks.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
Sapling deployment
|
||||
------------------
|
||||
|
||||
The primary sources of information about Sapling consensus protocol changes are:
|
||||
|
||||
- The Zcash Protocol Specification [#protocol]_.
|
||||
- Transaction Signature Validation for Sapling [#zip-0243]_.
|
||||
- Network Upgrade Mechanism [#zip-0200]_.
|
||||
|
||||
The network handshake and peer management mechanisms defined in [#zip-0201]_ also
|
||||
apply to this upgrade.
|
||||
|
||||
|
||||
The following network upgrade constants [#zip-0200]_ are defined for the Sapling
|
||||
upgrade:
|
||||
|
||||
CONSENSUS_BRANCH_ID
|
||||
``0x76b809bb``
|
||||
|
||||
ACTIVATION_HEIGHT (Sapling)
|
||||
Testnet: 280000
|
||||
|
||||
Mainnet: 419200
|
||||
|
||||
|
||||
On Testnet, Sapling had activated prior to this height, but that consensus branch
|
||||
was rolled back. A subsequent hard fork occurred on Testnet, changing the
|
||||
difficulty algorithm to accept "minimum-difficulty" blocks under certain
|
||||
conditions starting at block height 299188.
|
||||
|
||||
On both Mainnet and Testnet, Sapling-compatible nodes MUST advertise protocol
|
||||
version 170007 or later. The minimum peer protocol version that Sapling-compatible
|
||||
nodes will connect to, remains 170002.
|
||||
|
||||
Pre-Sapling nodes are defined as nodes advertising a protocol version less than
|
||||
170007.
|
||||
|
||||
Approximately three days (defined in terms of block height) before the Sapling
|
||||
activation height, Sapling-compatible nodes will change the behaviour of their peer
|
||||
connection logic in order to prefer pre-Sapling peers for eviction from the set of
|
||||
peer connections.
|
||||
|
||||
::
|
||||
|
||||
/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
|
||||
|
||||
The implementation is similar to that for Overwinter which was described in
|
||||
[#zip-0201]_.
|
||||
|
||||
Once Sapling activates on Testnet or Mainnet, Sapling nodes SHOULD take steps to:
|
||||
|
||||
- reject new connections from pre-Sapling nodes;
|
||||
- disconnect any existing connections to pre-Sapling nodes.
|
||||
|
||||
|
||||
Change to difficulty adjustment on Testnet
|
||||
------------------------------------------
|
||||
|
||||
Section 7.6.3 of the Zcash Protocol Specification [#protocol-diffadjustment]_
|
||||
describes the algorithm used to adjust the difficulty of a block (defined in terms
|
||||
of a "target threshold") based on the ``nTime`` and ``nBits`` fields of preceding
|
||||
blocks.
|
||||
|
||||
This algorithm changed on Testnet, starting from block 299188, to allow
|
||||
"minimum-difficulty" blocks. If the block time of a block from this height onward
|
||||
is greater than 15 minutes after that of the preceding block, then the block is a
|
||||
minimum-difficulty block. In that case its ``nBits`` field MUST be set to
|
||||
ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3
|
||||
of the Zcash Protocol Specification [#protocol-constants]_, and ToCompact is as
|
||||
defined in section 7.7.4 of that specification [#protocol-nbits]_.
|
||||
|
||||
Note: a previous revision of this ZIP incorrectly said that only the target
|
||||
threshold of minimum-difficulty blocks is affected. In fact the ``nBits`` field
|
||||
is modified as well, and this affects difficulty adjustment for subsequent blocks.
|
||||
|
||||
This change does not affect Mainnet.
|
||||
|
||||
|
||||
Backward compatibility
|
||||
======================
|
||||
|
||||
Prior to the network upgrade activating, Sapling and pre-Sapling nodes are
|
||||
compatible and can connect to each other. However, Sapling nodes will have a
|
||||
preference for connecting to other Sapling nodes, so pre-Sapling nodes will
|
||||
gradually be disconnected in the run up to activation.
|
||||
|
||||
Once the network upgrades, even though pre-Sapling nodes can still accept the
|
||||
numerically larger protocol version used by Sapling as being valid, Sapling nodes
|
||||
will always disconnect peers using lower protocol versions.
|
||||
|
||||
|
||||
Support in zcashd
|
||||
=================
|
||||
|
||||
Support for Sapling consensus rules was implemented in zcashd version 2.0.0.
|
||||
The majority of support for RPC calls and persistence of Sapling z-addresses
|
||||
was implemented in version 2.0.1. Both of these versions advertise protocol
|
||||
version 170007.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
|
||||
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
|
||||
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion <protocol/protocol.pdf#nbits>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling <zip-0243.rst>`_
|
|
@ -0,0 +1,117 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 206: Deployment of the Blossom Network Upgrade</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 206
|
||||
Title: Deployment of the Blossom Network Upgrade
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
Created: 2019-07-29
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", 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>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Blossom</dt>
|
||||
<dd>Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
</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 the deployment of the Blossom network upgrade.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="blossom-deployment"><h3><span class="section-heading">Blossom deployment</span><span class="section-anchor"> <a rel="bookmark" href="#blossom-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Blossom consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a>.</li>
|
||||
<li>Shorter Block Target Spacing <a id="id6" class="footnote_reference" href="#zip-0208">5</a>.</li>
|
||||
<li>Network Upgrade Mechanism <a id="id7" class="footnote_reference" href="#zip-0200">3</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in <a id="id8" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id9" class="footnote_reference" href="#zip-0200">3</a> are defined for the Blossom upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0x2BB40E60</code></dd>
|
||||
<dt>ACTIVATION_HEIGHT (Blossom)</dt>
|
||||
<dd>
|
||||
<p>Testnet: 584000</p>
|
||||
<p>Mainnet: 653600</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p>Nodes compatible with Blossom activation on testnet MUST advertise protocol version 170008 or later. Nodes compatible with Blossom activation on mainnet MUST advertise protocol version 170009 or later. The minimum peer protocol version that Blossom-compatible nodes will connect to is 170002.</p>
|
||||
<p>Pre-Blossom testnet nodes are defined as nodes on testnet advertising a protocol version less than 170008. Pre-Blossom mainnet nodes are defined as nodes on mainnet advertising a protocol version less than 170009.</p>
|
||||
<p>For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding Blossom activation height, nodes compatible with Blossom activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Blossom peers on that network for eviction from the set of peer connections:</p>
|
||||
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id10" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
<p>Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Blossom nodes on that network;</li>
|
||||
<li>disconnect any existing connections to pre-Blossom nodes on that network.</li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Blossom and pre-Blossom nodes are compatible and can connect to each other. However, Blossom nodes will have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Blossom nodes can still accept the numerically larger protocol version used by Blossom as being valid, Blossom nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="id11" class="footnote_reference" href="#protocol">2</a> section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.</p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Blossom on testnet is implemented in <code>zcashd</code> version 2.0.7, which advertises protocol version 170008. Support for Blossom on mainnet is implemented in <code>zcashd</code> version 2.1.0, which advertises protocol version 170009.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0208" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,128 @@
|
|||
::
|
||||
|
||||
ZIP: 206
|
||||
Title: Deployment of the Blossom Network Upgrade
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus / Network
|
||||
Created: 2019-07-29
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
|
||||
interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as described in
|
||||
ZIP 200. [#zip-0200]_
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
Blossom
|
||||
Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.
|
||||
Testnet
|
||||
The Zcash test network, as defined in [#protocol]_.
|
||||
Mainnet
|
||||
The Zcash production network, as defined in [#protocol]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines the deployment of the Blossom network upgrade.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
Blossom deployment
|
||||
------------------
|
||||
|
||||
The primary sources of information about Blossom consensus protocol changes are:
|
||||
|
||||
- The Zcash Protocol Specification [#protocol]_.
|
||||
- Shorter Block Target Spacing [#zip-0208]_.
|
||||
- Network Upgrade Mechanism [#zip-0200]_.
|
||||
|
||||
The network handshake and peer management mechanisms defined in [#zip-0201]_ also
|
||||
apply to this upgrade.
|
||||
|
||||
|
||||
The following network upgrade constants [#zip-0200]_ are defined for the Blossom
|
||||
upgrade:
|
||||
|
||||
CONSENSUS_BRANCH_ID
|
||||
``0x2BB40E60``
|
||||
|
||||
|
||||
ACTIVATION_HEIGHT (Blossom)
|
||||
Testnet: 584000
|
||||
|
||||
Mainnet: 653600
|
||||
|
||||
|
||||
Nodes compatible with Blossom activation on testnet MUST advertise protocol version
|
||||
170008 or later. Nodes compatible with Blossom activation on mainnet MUST advertise
|
||||
protocol version 170009 or later. The minimum peer protocol version that
|
||||
Blossom-compatible nodes will connect to is 170002.
|
||||
|
||||
Pre-Blossom testnet nodes are defined as nodes on testnet advertising a protocol
|
||||
version less than 170008. Pre-Blossom mainnet nodes are defined as nodes on mainnet
|
||||
advertising a protocol version less than 170009.
|
||||
|
||||
For each network (testnet and mainnet), approximately three days (defined in terms of
|
||||
block height) before the corresponding Blossom activation height, nodes compatible
|
||||
with Blossom activation on that network will change the behaviour of their peer
|
||||
connection logic in order to prefer pre-Blossom peers on that network for eviction
|
||||
from the set of peer connections::
|
||||
|
||||
/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
|
||||
|
||||
The implementation is similar to that for Overwinter which was described in
|
||||
[#zip-0201]_.
|
||||
|
||||
Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:
|
||||
|
||||
- reject new connections from pre-Blossom nodes on that network;
|
||||
- disconnect any existing connections to pre-Blossom nodes on that network.
|
||||
|
||||
|
||||
Backward compatibility
|
||||
======================
|
||||
|
||||
Prior to the network upgrade activating on each network, Blossom and pre-Blossom
|
||||
nodes are compatible and can connect to each other. However, Blossom nodes will
|
||||
have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will
|
||||
gradually be disconnected in the run up to activation.
|
||||
|
||||
Once the network upgrades, even though pre-Blossom nodes can still accept the
|
||||
numerically larger protocol version used by Blossom as being valid, Blossom nodes
|
||||
will always disconnect peers using lower protocol versions.
|
||||
|
||||
Unlike Overwinter and Sapling, Blossom does not define a new transaction version.
|
||||
Blossom transactions are therefore in the same v4 format as Sapling transactions,
|
||||
and use the same version group ID, i.e. 0x892F2085 as defined in [#protocol]_
|
||||
section 7.1. This does not imply that transactions are valid across the Blossom
|
||||
activation, since signatures MUST use the appropriate consensus branch ID.
|
||||
|
||||
|
||||
Support in zcashd
|
||||
=================
|
||||
|
||||
Support for Blossom on testnet is implemented in ``zcashd`` version 2.0.7, which
|
||||
advertises protocol version 170008. Support for Blossom on mainnet is implemented
|
||||
in ``zcashd`` version 2.1.0, which advertises protocol version 170009.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
|
@ -0,0 +1,357 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 207: Funding Streams</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: 207
|
||||
Title: Funding Streams
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-01-04
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD 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>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">7</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">10</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Canopy</dt>
|
||||
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol-networks">4</a></dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-networks">4</a></dd>
|
||||
</dl>
|
||||
</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 specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">14</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">16</a>, which describes the high-level requirements for that fund.</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>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">16</a>.</p>
|
||||
<p>This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">14</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">16</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>As for the original Founders' Reward, a mechanism is provided to allow addresses for a given funding stream to be changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We use the following constants and functions defined in <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, <a id="id13" class="footnote_reference" href="#protocol-diffadjustment">6</a>, <a id="id14" class="footnote_reference" href="#protocol-subsidies">7</a>, and <a id="id15" class="footnote_reference" href="#protocol-foundersreward">8</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BlossomActivationHeight}\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{PostBlossomHalvingInterval}\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{Halving}(\mathsf{height})\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BlockSubsidy}(\mathsf{height})\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{RedeemScriptHash}(\mathsf{height})\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>We also define the following function:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{HeightForHalving}(\mathsf{halving})\)</span>
|
||||
: Smallest
|
||||
<span class="math">\(\mathsf{height}\)</span>
|
||||
such that
|
||||
<span class="math">\(\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}\)</span>
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="funding-streams"><h3><span class="section-heading">Funding streams</span><span class="section-anchor"> <a rel="bookmark" href="#funding-streams"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).</p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="id16" class="footnote_reference" href="#zip-0208">11</a></p>
|
||||
<p>The value of a funding stream at a given block height is defined as:</p>
|
||||
<div class="math">\(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
|
||||
\mathsf{floor}\left(
|
||||
\frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}}
|
||||
\right)\)</div>
|
||||
<p>An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height.</p>
|
||||
<p>Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.</p>
|
||||
<p>Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:</p>
|
||||
<div class="math">\(\begin{eqnarray*}
|
||||
\mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\
|
||||
\mathsf{AddressPeriod}(\mathsf{height}) &=&
|
||||
\mathsf{floor}\left(
|
||||
{\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}}
|
||||
\right) \\
|
||||
\mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &=&
|
||||
\mathsf{AddressPeriod}(\mathsf{height}) - \\&&\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\
|
||||
\mathsf{FundingStream[FUND].Address}(\mathsf{height}) &=& \mathsf{FundingStream[FUND].Addresses[} \\&&\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]}
|
||||
\end{eqnarray*}\)</div>
|
||||
<p>This has the property that all active funding streams change the address they are using on the same block height schedule, aligned to the height of the first halving so that 48 funding periods fit cleanly within a halving interval. This can be leveraged to simplify implementations, by batching the necessary outputs for each funding period.</p>
|
||||
<p>Below is a visual representation of how stream addresses align with funding periods:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Example height</th>
|
||||
<th>Stream A</th>
|
||||
<th>Stream B</th>
|
||||
<th>Stream C</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>AddressChangeInterval - 2</code></td>
|
||||
<td>A0</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>AddressChangeInterval - 1</code></td>
|
||||
<td>A0</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>AddressChangeInterval</code></td>
|
||||
<td>A1</td>
|
||||
<td>B0</td>
|
||||
<td>C0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>AddressChangeInterval + 1</code></td>
|
||||
<td>A1</td>
|
||||
<td>B0</td>
|
||||
<td>C0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>...</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>2*AddressChangeInterval - 2</code></td>
|
||||
<td>A1</td>
|
||||
<td>B0</td>
|
||||
<td>C0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>2*AddressChangeInterval - 1</code></td>
|
||||
<td>A1</td>
|
||||
<td>B0</td>
|
||||
<td>C0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>2*AddressChangeInterval</code></td>
|
||||
<td>A2</td>
|
||||
<td></td>
|
||||
<td>C1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>2*AddressChangeInterval + 1</code></td>
|
||||
<td>A2</td>
|
||||
<td></td>
|
||||
<td>C1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>...</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PostBlossomHalvingInterval - 2</code></td>
|
||||
<td>A2</td>
|
||||
<td></td>
|
||||
<td>C1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PostBlossomHalvingInterval - 1</code></td>
|
||||
<td>A2</td>
|
||||
<td></td>
|
||||
<td>C1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PostBlossomHalvingInterval</code></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>C2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PostBlossomHalvingInterval + 1</code></td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
<td>C2</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p>On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.</p>
|
||||
</section>
|
||||
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rules"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id17" class="footnote_reference" href="#protocol-foundersreward">8</a></p>
|
||||
<p>Once the Canopy network upgrade activates:</p>
|
||||
<ul>
|
||||
<li>The existing consensus rule for payment of the Founders' Reward <a id="id18" class="footnote_reference" href="#protocol-foundersreward">8</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
|
||||
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id19" class="footnote_reference" href="#zip-0213">13</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
|
||||
<span class="math">\(\mathbf{0x02}\)</span>
|
||||
, as specified in <a id="id20" class="footnote_reference" href="#zip-0212">12</a>.</li>
|
||||
</ul>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id21" class="footnote_reference" href="#zip-0214">14</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id22" class="footnote_reference" href="#zip-0000">9</a></p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id23" class="footnote_reference" href="#zip-0251">15</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</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/zcash/pull/4560">https://github.com/zcash/zcash/pull/4560</a></li>
|
||||
<li><a href="https://github.com/zcash/zcash/pull/4675">https://github.com/zcash/zcash/pull/4675</a></li>
|
||||
<li><a href="https://github.com/zcash/zcash/pull/4830">https://github.com/zcash/zcash/pull/4830</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="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-subsidyconcepts" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-constants" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-diffadjustment" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-subsidies" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-foundersreward" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#foundersreward">Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0000" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0000">ZIP 0: ZIP Process</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0208" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0212" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0213" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0214" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-1014" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,251 @@
|
|||
::
|
||||
|
||||
ZIP: 207
|
||||
Title: Funding Streams
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-01-04
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are
|
||||
to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The terms "block subsidy" and "halving" in this document are to be interpreted
|
||||
as described in sections 3.9 and 7.7 of the Zcash Protocol Specification.
|
||||
[#protocol-subsidyconcepts]_ [#protocol-subsidies]_
|
||||
|
||||
The terms "consensus branch" and "network upgrade" in this document are to be
|
||||
interpreted as described in ZIP 200. [#zip-0200]_
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
Canopy
|
||||
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
|
||||
Testnet
|
||||
The Zcash test network, as defined in the Zcash Protocol Specification. [#protocol-networks]_
|
||||
Mainnet
|
||||
The Zcash production network, as defined in the Zcash Protocol Specification. [#protocol-networks]_
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal specifies a mechanism to support funding streams, distributed
|
||||
from a portion of the block subsidy for a specified range of block heights.
|
||||
|
||||
This is intended as a means of implementing the Zcash Development Fund,
|
||||
using the funding stream definitions specified in ZIP 214 [#zip-0214]_. It
|
||||
should be read in conjunction with ZIP 1014 [#zip-1014]_, which describes
|
||||
the high-level requirements for that fund.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Motivation for the Zcash Development Fund is considered in ZIP 1014 [#zip-1014]_.
|
||||
|
||||
This ZIP 207 was originally proposed for the Blossom network upgrade, as a
|
||||
means of splitting the original Founders' Reward into several streams. It was
|
||||
then withdrawn when such splitting was judged to be unnecessary at the consensus
|
||||
level. Since the capabilities of the funding stream mechanism match the
|
||||
requirements for the Zcash Development Fund, the ZIP is being reintroduced
|
||||
for that purpose in order to reuse specification, analysis, and implementation
|
||||
effort.
|
||||
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
The primary requirement of this ZIP is to provide a mechanism for specifying
|
||||
the funding streams that are used in ZIP 214 [#zip-0214]_ to implement the Zcash
|
||||
Development Fund. It should be sufficiently expressive to handle both the main
|
||||
three "slices" (BP, ZF, and MG) defined in ZIP 1014 [#zip-1014]_, and also
|
||||
(with additional funding stream definitions) the "direct grant option" described
|
||||
in that ZIP.
|
||||
|
||||
As for the original Founders' Reward, a mechanism is provided to allow addresses
|
||||
for a given funding stream to be changed on a roughly-monthly basis, so that keys
|
||||
that are not yet needed may be kept off-line as a security measure.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
Definitions
|
||||
-----------
|
||||
|
||||
We use the following constants and functions defined in [#protocol-constants]_,
|
||||
[#protocol-diffadjustment]_, [#protocol-subsidies]_, and [#protocol-foundersreward]_:
|
||||
|
||||
- :math:`\mathsf{BlossomActivationHeight}`
|
||||
- :math:`\mathsf{PostBlossomHalvingInterval}`
|
||||
- :math:`\mathsf{Halving}(\mathsf{height})`
|
||||
- :math:`\mathsf{BlockSubsidy}(\mathsf{height})`
|
||||
- :math:`\mathsf{RedeemScriptHash}(\mathsf{height})`.
|
||||
|
||||
We also define the following function:
|
||||
|
||||
- :math:`\mathsf{HeightForHalving}(\mathsf{halving})`: Smallest :math:`\mathsf{height}` such that
|
||||
:math:`\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}`
|
||||
|
||||
|
||||
Funding streams
|
||||
---------------
|
||||
|
||||
A funding stream is defined by a block subsidy fraction (represented as a
|
||||
numerator and a denominator), a start height (inclusive), and an end height
|
||||
(exclusive).
|
||||
|
||||
By defining the issuance as a proportion of the total block subsidy, rather
|
||||
than absolute zatoshis, this ZIP dovetails with any changes to both block
|
||||
target spacing and issuance-per-block rates. Such a change occurred at the
|
||||
Blossom network upgrade, for example. [#zip-0208]_
|
||||
|
||||
The value of a funding stream at a given block height is defined as:
|
||||
|
||||
.. math::
|
||||
|
||||
\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
|
||||
\mathsf{floor}\left(
|
||||
\frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}}
|
||||
\right)
|
||||
|
||||
An active funding stream at a given block height is defined as a funding
|
||||
stream for which the block height is less than its end height, but not less
|
||||
than its start height.
|
||||
|
||||
Each funding stream has an associated sequence of recipient addresses,
|
||||
each of which MUST be either a transparent P2SH address or a Sapling address.
|
||||
|
||||
Each address is used for at most 1/48th of a halving interval, creating a
|
||||
roughly-monthly sequence of funding periods. The address to be used for a
|
||||
given block height is defined as follows:
|
||||
|
||||
.. math::
|
||||
|
||||
\begin{eqnarray*}
|
||||
\mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\
|
||||
\mathsf{AddressPeriod}(\mathsf{height}) &=&
|
||||
\mathsf{floor}\left(
|
||||
{\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}}
|
||||
\right) \\
|
||||
\mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &=&
|
||||
\mathsf{AddressPeriod}(\mathsf{height}) - \\&&\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\
|
||||
\mathsf{FundingStream[FUND].Address}(\mathsf{height}) &=& \mathsf{FundingStream[FUND].Addresses[} \\&&\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]}
|
||||
\end{eqnarray*}
|
||||
|
||||
This has the property that all active funding streams change the address they
|
||||
are using on the same block height schedule, aligned to the height of the
|
||||
first halving so that 48 funding periods fit cleanly within a halving
|
||||
interval. This can be leveraged to simplify implementations, by batching the
|
||||
necessary outputs for each funding period.
|
||||
|
||||
Below is a visual representation of how stream addresses align with funding
|
||||
periods:
|
||||
|
||||
================================== ======== ======== ========
|
||||
Example height Stream A Stream B Stream C
|
||||
================================== ======== ======== ========
|
||||
``AddressChangeInterval - 2`` A0
|
||||
``AddressChangeInterval - 1`` A0
|
||||
``AddressChangeInterval`` A1 B0 C0
|
||||
``AddressChangeInterval + 1`` A1 B0 C0
|
||||
\...
|
||||
``2*AddressChangeInterval - 2`` A1 B0 C0
|
||||
``2*AddressChangeInterval - 1`` A1 B0 C0
|
||||
``2*AddressChangeInterval`` A2 C1
|
||||
``2*AddressChangeInterval + 1`` A2 C1
|
||||
\...
|
||||
``PostBlossomHalvingInterval - 2`` A2 C1
|
||||
``PostBlossomHalvingInterval - 1`` A2 C1
|
||||
``PostBlossomHalvingInterval`` C2
|
||||
``PostBlossomHalvingInterval + 1`` C2
|
||||
================================== ======== ======== ========
|
||||
|
||||
On Mainnet, Canopy is planned to activate exactly at the point when the Founders'
|
||||
Reward expires, at block height 1046400. On Testnet, there will be a shortened
|
||||
Founders' Reward address period prior to Canopy activation.
|
||||
|
||||
|
||||
Consensus rules
|
||||
---------------
|
||||
|
||||
Prior to activation of the Canopy network upgrade, the existing consensus rule
|
||||
for payment of the original Founders' Reward is enforced. [#protocol-foundersreward]_
|
||||
|
||||
Once the Canopy network upgrade activates:
|
||||
|
||||
- The existing consensus rule for payment of the Founders' Reward [#protocol-foundersreward]_
|
||||
is no longer active.
|
||||
(This would be the case under the preexisting consensus rules for Mainnet, but
|
||||
not for Testnet.)
|
||||
|
||||
- The coinbase transaction in each block MUST contain at least one output per
|
||||
active funding stream that pays the stream's value in the prescribed way to
|
||||
the stream's recipient address for the block's height.
|
||||
|
||||
- The "prescribed way" to pay a transparent P2SH address is to use a standard
|
||||
P2SH script of the form ``OP_HASH160 RedeemScriptHash(height) OP_EQUAL`` as
|
||||
the ``scriptPubKey``.
|
||||
|
||||
- The "prescribed way" to pay a Sapling address is as defined in [#zip-0213]_.
|
||||
That is, all Sapling outputs in coinbase transactions (including, but not
|
||||
limited to, outputs for funding streams) MUST have valid note commitments
|
||||
when recovered using a 32-byte array of zeroes as the outgoing viewing key.
|
||||
In this case the note plaintext lead byte MUST be :math:`\mathbf{0x02}`, as
|
||||
specified in [#zip-0212]_.
|
||||
|
||||
For the funding stream definitions to be activated at Canopy, see ZIP 214. [#zip-0214]_
|
||||
Funding stream definitions can be added, changed, or deleted in ZIPs associated
|
||||
with subsequent network upgrades, subject to the ZIP process. [#zip-0000]_
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This proposal is intended to be deployed with Canopy. [#zip-0251]_
|
||||
|
||||
|
||||
Backward compatibility
|
||||
======================
|
||||
|
||||
This proposal intentionally creates what is known as a "bilateral consensus
|
||||
rule change". Use of this mechanism requires that all network participants
|
||||
upgrade their software to a compatible version within the upgrade window.
|
||||
Older software will treat post-upgrade blocks as invalid, and will follow any
|
||||
pre-upgrade consensus branch that persists.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
* https://github.com/zcash/zcash/pull/4560
|
||||
* https://github.com/zcash/zcash/pull/4675
|
||||
* https://github.com/zcash/zcash/pull/4830
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
|
||||
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
|
||||
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward <protocol/protocol.pdf#subsidies>`_
|
||||
.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward <protocol/protocol.pdf#foundersreward>`_
|
||||
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
||||
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
|
||||
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
|
||||
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
|
||||
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
|
||||
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_
|
|
@ -0,0 +1,313 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 208: Shorter Block Target Spacing</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 208
|
||||
Title: Shorter Block Target Spacing
|
||||
Owner: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Daira Hopwood
|
||||
Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-01-10
|
||||
License: MIT
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/237">https://github.com/zcash/zips/pull/237</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">9</a>.</p>
|
||||
<p>The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-diffadjustment">6</a>.)</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-networks">4</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 specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="id5" class="footnote_reference" href="#zip-0206">11</a>.</p>
|
||||
<p>The emission schedule of mined ZEC will be approximately the same in terms of time, but this requires the emission per block to be adjusted to take account of the changed block target spacing.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The motivations for decreasing the block target spacing are:</p>
|
||||
<ul>
|
||||
<li>Reduced latency for considering transactions to be sufficiently confirmed;</li>
|
||||
<li>Greater throughput of transactions in unit time.</li>
|
||||
</ul>
|
||||
<p>The latter goal could alternatively be achieved by increasing the block size limit, but that would not also achieve the former goal.</p>
|
||||
<p>Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See <a id="id6" class="footnote_reference" href="#slowfastblocks">13</a> for further analysis in various attack models.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes described in this section are to be made in the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol">3</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
|
||||
<section id="consensus-changes"><h3><span class="section-heading">Consensus changes</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from <a id="id8" class="footnote_reference" href="#preblossom-protocol">2</a> of 840000 (blocks) and 150 (seconds) respectively.</p>
|
||||
<p>In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing to the list of integer constants.</p>
|
||||
<p>In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.</p>
|
||||
<p>For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in <a id="id9" class="footnote_reference" href="#zip-0206">11</a>.</p>
|
||||
<p>In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the following changes:</p>
|
||||
<p>Define IsBlossomActivated(<em>height</em>) to return true if <em>height</em> ≥ BlossomActivationHeight, otherwise false.</p>
|
||||
<p>This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.</p>
|
||||
<p>Define:</p>
|
||||
<ul>
|
||||
<li>BlossomPoWTargetSpacingRatio := PreBlossomPoWTargetSpacing / PostBlossomPoWTargetSpacing</li>
|
||||
<li>PostBlossomHalvingInterval := floor(PreBlossomHalvingInterval · BlossomPoWTargetSpacingRatio).</li>
|
||||
</ul>
|
||||
<p>In the same section, redefine PoWTargetSpacing as a function taking a <em>height</em> parameter, as follows:</p>
|
||||
<ul>
|
||||
<li>PoWTargetSpacing(<em>height</em>) :=
|
||||
<ul>
|
||||
<li>PreBlossomPoWTargetSpacing, if not IsBlossomActivated(<em>height</em>)</li>
|
||||
<li>PostBlossomPoWTargetSpacing, otherwise.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Also redefine AveragingWindowTimespan, MinActualTimespan, MaxActualTimespan, ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:</p>
|
||||
<ul>
|
||||
<li>add a <em>height</em> parameter to each of these functions that does not already have one;</li>
|
||||
<li>ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the <em>height</em> parameter.</li>
|
||||
</ul>
|
||||
<p>In section 7.7 (Calculation of Block Subsidy and Founders’ Reward) [later moved to section 7.8], redefine the Halving and BlockSubsidy functions as follows:</p>
|
||||
<ul>
|
||||
<li>Halving(<em>height</em>) :=
|
||||
<ul>
|
||||
<li>floor((<em>height</em> - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(<em>height</em>)</li>
|
||||
<li>floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (<em>height</em> - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>BlockSubsidy(<em>height</em>) :=
|
||||
<ul>
|
||||
<li>SlowStartRate · <em>height</em>, if <em>height</em> < SlowStartInterval / 2</li>
|
||||
<li>SlowStartRate · (<em>height</em> + 1), if SlowStartInterval / 2 ≤ <em>height</em> and <em>height</em> < SlowStartInterval</li>
|
||||
<li>floor(MaxBlockSubsidy / 2<sup>Halving(*height*)</sup>), if SlowStartInterval ≤ <em>height</em> and not IsBlossomActivated(<em>height</em>)</li>
|
||||
<li>floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2<sup>Halving(*height*)</sup>)), otherwise</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTargetSpacing are chosen so that:</p>
|
||||
<ul>
|
||||
<li>(BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (<em>height</em> - BlossomActivationHeight) / PostBlossomHalvingInterval) is exactly 1 for some integer <em>height</em>.</li>
|
||||
<li>MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2<sup>Halving(*height*)</sup>) is an integer for the next few periods.</li>
|
||||
</ul>
|
||||
<p>In section 7.8 (Payment of Founders’ Reward) [later moved to section 7.9], define:</p>
|
||||
<ul>
|
||||
<li>FounderAddressAdjustedHeight(<em>height</em>) :=
|
||||
<ul>
|
||||
<li><em>height</em>, if not IsBlossomActivated(<em>height</em>)</li>
|
||||
<li>BlossomActivationHeight + floor((<em>height</em> - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>and in the definition of FounderAddressIndex, replace the use of <em>height</em> with FounderAddressAdjustedHeight(<em>height</em>).</p>
|
||||
<p>Also define:</p>
|
||||
<ul>
|
||||
<li>FoundersRewardLastBlockHeight := max({ <em>height</em> ⦂ N | Halving(<em>height</em>) < 1 })</li>
|
||||
</ul>
|
||||
<p>Replace the first note in that section with:</p>
|
||||
<ul>
|
||||
<li>No Founders’ Reward is required to be paid for <em>height</em> > FoundersRewardLastBlockHeight (i.e. after the first halving), or for <em>height</em> = 0 (i.e. the genesis block).</li>
|
||||
</ul>
|
||||
<p>and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with FoundersRewardLastBlockHeight.</p>
|
||||
</section>
|
||||
<section id="effect-on-difficulty-adjustment"><h3><span class="section-heading">Effect on difficulty adjustment</span><span class="section-anchor"> <a rel="bookmark" href="#effect-on-difficulty-adjustment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The difficulty adjustment parameters PoWAveragingWindow and PoWMedianBlockSpan refer to numbers of blocks, but do <em>not</em> change at Blossom activation. This is because the amount of damping/averaging required is expected to be roughly the same, in terms of the number of blocks, after the change in block target spacing.</p>
|
||||
<p>The change in the effective value of PoWTargetSpacing will cause the block spacing to adjust to the new target, at the normal rate for a difficulty adjustment. The results of simulations are consistent with this expected behaviour.</p>
|
||||
<p>Note that the change in AveragingWindowTimespan(height) takes effect immediately when calculating the target difficulty starting from the block at the Blossom activation height, even though the difficulty of the preceding PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target spacing. Therefore it is likely that the difficulty adjustment for the first few blocks after activation will be limited by PoWMaxAdjustDown. This is not anticipated to cause any problem.</p>
|
||||
<section id="minimum-difficulty-blocks-on-testnet"><h4><span class="section-heading">Minimum difficulty blocks on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-testnet"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>On Testnet from block height 299188 onward, the difficulty adjustment algorithm <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">6</a> allows minimum-difficulty blocks, as described in <a id="id11" class="footnote_reference" href="#zip-0205">10</a>, when the block time is greater than a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
|
||||
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is greater than 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
|
||||
<p>Note: a previous revision of this ZIP (and <a id="id14" class="footnote_reference" href="#zip-0205">10</a>) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
|
||||
<p>This change does not affect Mainnet.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="non-consensus-node-behaviour"><h3><span class="section-heading">Non-consensus node behaviour</span><span class="section-anchor"> <a rel="bookmark" href="#non-consensus-node-behaviour"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="end-of-service-halt"><h4><span class="section-heading">End-of-Service halt</span><span class="section-anchor"> <a rel="bookmark" href="#end-of-service-halt"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p><cite>zcashd</cite> implements an "End-of-Service halt" behaviour that halts the node at a block height that corresponds approximately to a given time after release. This interval SHOULD be adjusted in releases where the End-of-Service halt time will follow Blossom activation.</p>
|
||||
</section>
|
||||
<section id="default-expiry-delta"><h4><span class="section-heading">Default expiry delta</span><span class="section-anchor"> <a rel="bookmark" href="#default-expiry-delta"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>When not overridden by the <code>-txexpirydelta</code> option, <cite>zcashd</cite> RPC calls that create transactions use a default value for the number of blocks after which a transaction will expire. The default in recent versions of <cite>zcashd</cite> is 20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 50 minutes.</p>
|
||||
<p>This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after Blossom activation, to maintain the approximate expiry time of 50 minutes.</p>
|
||||
<p>If the <code>-txexpirydelta</code> option is set, then the set value SHOULD be used both before and after Blossom activation.</p>
|
||||
</section>
|
||||
<section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-to-sapling-migration"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ZIP 308 <a id="id15" class="footnote_reference" href="#zip-0308">12</a> defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.</p>
|
||||
<p>The 500-block constant has not been changed. Therefore, migration transactions are now sent roughly every 10.42 hours after Blossom activation. This has been noted in the ZIP, and a table showing the expected time to complete migration has been updated accordingly.</p>
|
||||
</section>
|
||||
<section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a rel="bookmark" href="#fingerprinting-mitigation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>A "fingerprinting attack" is a network analysis technique in which nodes are identified across network sessions, for example using information about which blocks they request or send.</p>
|
||||
<p><cite>zcashd</cite> inherits from Bitcoin Core the following behaviour, described in a comment in <code>main.cpp</code>, intended as a fingerprinting mitigation:</p>
|
||||
<pre>// To prevent fingerprinting attacks, only send blocks outside of the active
|
||||
// chain if they are valid, and no more than a month older (both in time, and in
|
||||
// best equivalent proof of work) than the best header chain we know about.</pre>
|
||||
<p>We make no assertion about the significance of fingerprinting for Zcash, and (despite the word "prevent" in the above comment) no claim about the effectiveness of this mitigation.</p>
|
||||
<p>In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.7.5 of the Zcash Protocol Specification <a id="id16" class="footnote_reference" href="#protocol-workdef">8</a>, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
|
||||
<p>It is not a requirement of the Zcash protocol that this fingerprinting mitigation is used; however, if it is used, then it SHOULD use the target block spacing at the same block height that is used for the current work estimate.</p>
|
||||
</section>
|
||||
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p><cite>zcashd</cite> previously did this monitoring every 150 seconds; it is now done every 60 seconds.</p>
|
||||
</section>
|
||||
<section id="block-timeout"><h4><span class="section-heading">Block timeout</span><span class="section-anchor"> <a rel="bookmark" href="#block-timeout"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The timeout for a requested block is calculated as the target block time, multiplied by 2 + (the number of queued validated headers)/2.</p>
|
||||
</section>
|
||||
<section id="latency-optimization-when-requesting-blocks"><h4><span class="section-heading">Latency optimization when requesting blocks</span><span class="section-anchor"> <a rel="bookmark" href="#latency-optimization-when-requesting-blocks"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>When <cite>zcashd</cite> sees an announced block that chains from headers that it does not already have, it will first ask for the headers, and then the block itself. A latency optimization is performed only if the chain is "nearly synced":</p>
|
||||
<pre>// First request the headers preceding the announced block. In the normal fully-synced
|
||||
// case where a new block is announced that succeeds the current tip (no reorganization),
|
||||
// there are no such headers.
|
||||
// Secondly, and only when we are close to being synced, we request the announced block directly,
|
||||
// to avoid an extra round-trip. Note that we must *first* ask for the headers, so by the
|
||||
// time the block arrives, the header chain leading up to it is already validated. Not
|
||||
// doing this will result in the received block being rejected as an orphan in case it is
|
||||
// not a direct successor.</pre>
|
||||
<p>The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In <cite>zcashd</cite> this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.</p>
|
||||
</section>
|
||||
<section id="response-to-getblocks-message-when-pruning"><h4><span class="section-heading">Response to getblocks message when pruning</span><span class="section-anchor"> <a rel="bookmark" href="#response-to-getblocks-message-when-pruning"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>If pruning is enabled, when <cite>zcashd</cite> responds to an "getblocks" peer-to-peer message, it will only include blocks that it has on disk, and is likely to still have on disk an hour after responding to the message:</p>
|
||||
<pre>// If pruning, don't inv blocks unless we have on disk and are likely to still have
|
||||
// for some reasonable time window (1 hour) that block relay might require.</pre>
|
||||
<p>For each block, when estimating whether it will still be on disk after an hour, we take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected in one hour at the target block spacing as of that block. Around Blossom activation, this might underestimate the number of blocks in the next hour, but given the value of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.</p>
|
||||
</section>
|
||||
<section id="estimation-of-fully-synced-chain-height"><h4><span class="section-heading">Estimation of fully synced chain height</span><span class="section-anchor"> <a rel="bookmark" href="#estimation-of-fully-synced-chain-height"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p><cite>zcashd</cite> uses the <code>EstimateNetHeight</code> function to estimate the approximate height of the fully synced chain, so that the progress of block download can be displayed to the node operator. This function has been rewritten, simplified, and changed to take account of cases where the time period that needs to be estimated crosses Blossom activation.</p>
|
||||
</section>
|
||||
<section id="other-block-related-constants"><h4><span class="section-heading">Other block-related constants</span><span class="section-anchor"> <a rel="bookmark" href="#other-block-related-constants"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The following constants, measured in number of blocks, were reviewed and a decision was made not to change them:</p>
|
||||
<pre>/** The number of blocks within expiry height when a tx is considered to be expiring soon */
|
||||
TX_EXPIRING_SOON_THRESHOLD = 3
|
||||
|
||||
/** Maximum reorg length we will accept before we shut down and alert the user. */
|
||||
MAX_REORG_LENGTH = COINBASE_MATURITY - 1;
|
||||
|
||||
static const int COINBASE_MATURITY = 100;
|
||||
|
||||
/** Number of blocks that can be requested at any given time from a single peer. */
|
||||
static const int MAX_BLOCKS_IN_TRANSIT_PER_PEER = 16;
|
||||
|
||||
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;
|
||||
|
||||
/** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */
|
||||
static const unsigned int MIN_BLOCKS_TO_KEEP = 288;
|
||||
|
||||
/**
|
||||
* The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks).
|
||||
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
|
||||
*/
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Blossom network upgrade. <a id="id17" class="footnote_reference" href="#zip-0206">11</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/4025">https://github.com/zcash/zcash/pull/4025</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="preblossom-protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-37 (exactly)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-constants" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-diffadjustment" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-nbits" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-workdef" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#workdef">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0205" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0206" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0308" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="zip-0308">ZIP 308: Sprout to Sapling Migration</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="slowfastblocks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/">On Slow and Fast Block Times</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,409 @@
|
|||
::
|
||||
|
||||
ZIP: 208
|
||||
Title: Shorter Block Target Spacing
|
||||
Owner: Daira Hopwood <daira@electriccoin.co>
|
||||
Original-Authors: Daira Hopwood
|
||||
Simon Liu
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-01-10
|
||||
License: MIT
|
||||
Pull-Request: <https://github.com/zcash/zips/pull/237>
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST" and "SHOULD" in this document are to be interpreted as
|
||||
described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The terms "block chain", "consensus rule change", "consensus branch", and
|
||||
"network upgrade" are to be interpreted as defined in [#zip-0200]_.
|
||||
|
||||
The term "block target spacing" means the time interval between blocks targeted
|
||||
by the difficulty adjustment algorithm in a given consensus branch. It is normally
|
||||
measured in seconds. (This is also sometimes called the "target block time",
|
||||
but "block target spacing" is the term used in the Zcash Protocol Specification
|
||||
[#protocol-diffadjustment]_.)
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal specifies a change in the block target spacing, to take effect in
|
||||
the Blossom network upgrade [#zip-0206]_.
|
||||
|
||||
The emission schedule of mined ZEC will be approximately the same in terms of
|
||||
time, but this requires the emission per block to be adjusted to take account
|
||||
of the changed block target spacing.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
The motivations for decreasing the block target spacing are:
|
||||
|
||||
- Reduced latency for considering transactions to be sufficiently confirmed;
|
||||
- Greater throughput of transactions in unit time.
|
||||
|
||||
The latter goal could alternatively be achieved by increasing the block size
|
||||
limit, but that would not also achieve the former goal.
|
||||
|
||||
Note that, for a given security requirement (in terms of the expected cost
|
||||
distribution of a rollback attack), the number of confirmations needed
|
||||
increases more slowly than the decrease in block time, and so, up to a point,
|
||||
decreasing the block target spacing can provide a better trade-off between
|
||||
latency and security. This argument assumes that the validation and
|
||||
propagation time for a block remain small compared to the block target spacing.
|
||||
See [#slowfastblocks]_ for further analysis in various attack models.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
The changes described in this section are to be made in the Zcash Protocol Specification
|
||||
[#protocol]_, relative to the pre-Blossom specification in [#preblossom-protocol].
|
||||
|
||||
Consensus changes
|
||||
-----------------
|
||||
|
||||
Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval,
|
||||
and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain
|
||||
their values from [#preblossom-protocol]_ of 840000 (blocks) and 150 (seconds)
|
||||
respectively.
|
||||
|
||||
In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing
|
||||
to the list of integer constants.
|
||||
|
||||
In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.
|
||||
|
||||
For a given network (production or test), define BlossomActivationHeight as the
|
||||
height at which Blossom activates on that network, as specified in [#zip-0206]_.
|
||||
|
||||
In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the
|
||||
following changes:
|
||||
|
||||
Define IsBlossomActivated(*height*) to return true if *height* ≥ BlossomActivationHeight,
|
||||
otherwise false.
|
||||
|
||||
This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.
|
||||
|
||||
Define:
|
||||
|
||||
- BlossomPoWTargetSpacingRatio := PreBlossomPoWTargetSpacing / PostBlossomPoWTargetSpacing
|
||||
- PostBlossomHalvingInterval := floor(PreBlossomHalvingInterval · BlossomPoWTargetSpacingRatio).
|
||||
|
||||
In the same section, redefine PoWTargetSpacing as a function taking a *height*
|
||||
parameter, as follows:
|
||||
|
||||
- PoWTargetSpacing(*height*) :=
|
||||
|
||||
- PreBlossomPoWTargetSpacing, if not IsBlossomActivated(*height*)
|
||||
- PostBlossomPoWTargetSpacing, otherwise.
|
||||
|
||||
Also redefine AveragingWindowTimespan, MinActualTimespan, MaxActualTimespan,
|
||||
ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
|
||||
|
||||
- add a *height* parameter to each of these functions that does not already
|
||||
have one;
|
||||
- ensure that each reference to any of these values, or to PoWTargetSpacing,
|
||||
are replaced with a function call passing the *height* parameter.
|
||||
|
||||
In section 7.7 (Calculation of Block Subsidy and Founders’ Reward) [later moved
|
||||
to section 7.8], redefine the Halving and BlockSubsidy functions as follows:
|
||||
|
||||
- Halving(*height*) :=
|
||||
|
||||
- floor((*height* - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(*height*)
|
||||
- floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (*height* - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise
|
||||
|
||||
- BlockSubsidy(*height*) :=
|
||||
|
||||
- SlowStartRate · *height*, if *height* < SlowStartInterval / 2
|
||||
- SlowStartRate · (*height* + 1), if SlowStartInterval / 2 ≤ *height* and *height* < SlowStartInterval
|
||||
- floor(MaxBlockSubsidy / 2\ :sup:`Halving(*height*)`\ ), if SlowStartInterval ≤ *height* and not IsBlossomActivated(*height*)
|
||||
- floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )), otherwise
|
||||
|
||||
Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTargetSpacing are chosen so that:
|
||||
|
||||
- (BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (*height* - BlossomActivationHeight) / PostBlossomHalvingInterval)
|
||||
is exactly 1 for some integer *height*.
|
||||
- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )
|
||||
is an integer for the next few periods.
|
||||
|
||||
In section 7.8 (Payment of Founders’ Reward) [later moved to section 7.9], define:
|
||||
|
||||
- FounderAddressAdjustedHeight(*height*) :=
|
||||
|
||||
- *height*, if not IsBlossomActivated(*height*)
|
||||
- BlossomActivationHeight + floor((*height* - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise
|
||||
|
||||
and in the definition of FounderAddressIndex, replace the use of *height* with FounderAddressAdjustedHeight(*height*).
|
||||
|
||||
Also define:
|
||||
|
||||
- FoundersRewardLastBlockHeight := max({ *height* ⦂ N | Halving(*height*) < 1 })
|
||||
|
||||
Replace the first note in that section with:
|
||||
|
||||
- No Founders’ Reward is required to be paid for *height* > FoundersRewardLastBlockHeight
|
||||
(i.e. after the first halving), or for *height* = 0 (i.e. the genesis block).
|
||||
|
||||
and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with
|
||||
FoundersRewardLastBlockHeight.
|
||||
|
||||
|
||||
Effect on difficulty adjustment
|
||||
-------------------------------
|
||||
|
||||
The difficulty adjustment parameters PoWAveragingWindow and PoWMedianBlockSpan
|
||||
refer to numbers of blocks, but do *not* change at Blossom activation. This is
|
||||
because the amount of damping/averaging required is expected to be roughly the
|
||||
same, in terms of the number of blocks, after the change in block target
|
||||
spacing.
|
||||
|
||||
The change in the effective value of PoWTargetSpacing will cause the block
|
||||
spacing to adjust to the new target, at the normal rate for a difficulty
|
||||
adjustment. The results of simulations are consistent with this expected
|
||||
behaviour.
|
||||
|
||||
Note that the change in AveragingWindowTimespan(height) takes effect
|
||||
immediately when calculating the target difficulty starting from the block at
|
||||
the Blossom activation height, even though the difficulty of the preceding
|
||||
PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target
|
||||
spacing. Therefore it is likely that the difficulty adjustment for the first
|
||||
few blocks after activation will be limited by PoWMaxAdjustDown. This is not
|
||||
anticipated to cause any problem.
|
||||
|
||||
|
||||
Minimum difficulty blocks on Testnet
|
||||
''''''''''''''''''''''''''''''''''''
|
||||
|
||||
On Testnet from block height 299188 onward, the difficulty adjustment algorithm
|
||||
[#protocol-diffadjustment]_ allows minimum-difficulty blocks, as described in
|
||||
[#zip-0205]_, when the block time is greater than a given threshold. This
|
||||
specification changes this threshold to be proportional to the block target
|
||||
spacing.
|
||||
|
||||
That is, if the block time of a block at height *height* ≥ 299188 is greater than
|
||||
6 · PoWTargetSpacing(*height*) seconds after that of the preceding block,
|
||||
then the block is a minimum-difficulty block. In that case its ``nBits`` field
|
||||
MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet
|
||||
in section 5.3 of the Zcash Protocol Specification [#protocol-constants]_, and
|
||||
ToCompact is as defined in section 7.7.4 of that specification [#protocol-nbits]_.
|
||||
|
||||
Note: a previous revision of this ZIP (and [#zip-0205]_) incorrectly said that
|
||||
only the target threshold of minimum-difficulty blocks is affected. In fact
|
||||
the ``nBits`` field is modified as well, and this affects difficulty adjustment
|
||||
for subsequent blocks.
|
||||
|
||||
This change does not affect Mainnet.
|
||||
|
||||
|
||||
Non-consensus node behaviour
|
||||
----------------------------
|
||||
|
||||
End-of-Service halt
|
||||
'''''''''''''''''''
|
||||
|
||||
`zcashd` implements an "End-of-Service halt" behaviour that halts the node at a
|
||||
block height that corresponds approximately to a given time after release. This
|
||||
interval SHOULD be adjusted in releases where the End-of-Service halt time will
|
||||
follow Blossom activation.
|
||||
|
||||
|
||||
Default expiry delta
|
||||
''''''''''''''''''''
|
||||
|
||||
When not overridden by the ``-txexpirydelta`` option, `zcashd` RPC calls that
|
||||
create transactions use a default value for the number of blocks after which a
|
||||
transaction will expire. The default in recent versions of `zcashd` is
|
||||
20 blocks, which at the pre-Blossom block target spacing corresponds to roughly
|
||||
50 minutes.
|
||||
|
||||
This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after
|
||||
Blossom activation, to maintain the approximate expiry time of 50 minutes.
|
||||
|
||||
If the ``-txexpirydelta`` option is set, then the set value SHOULD be used both
|
||||
before and after Blossom activation.
|
||||
|
||||
|
||||
Sprout to Sapling migration
|
||||
'''''''''''''''''''''''''''
|
||||
|
||||
ZIP 308 [#zip-0308]_ defines a procedure for migrating funds from Sprout to
|
||||
Sapling z-addresses. In that procedure, migration transactions are sent every
|
||||
500 blocks, which corresponded to roughly 20.83 hours before Blossom.
|
||||
|
||||
The 500-block constant has not been changed. Therefore, migration transactions
|
||||
are now sent roughly every 10.42 hours after Blossom activation. This has been
|
||||
noted in the ZIP, and a table showing the expected time to complete migration
|
||||
has been updated accordingly.
|
||||
|
||||
|
||||
Fingerprinting mitigation
|
||||
'''''''''''''''''''''''''
|
||||
|
||||
A "fingerprinting attack" is a network analysis technique in which nodes are
|
||||
identified across network sessions, for example using information about which
|
||||
blocks they request or send.
|
||||
|
||||
`zcashd` inherits from Bitcoin Core the following behaviour, described in a
|
||||
comment in ``main.cpp``, intended as a fingerprinting mitigation::
|
||||
|
||||
// To prevent fingerprinting attacks, only send blocks outside of the active
|
||||
// chain if they are valid, and no more than a month older (both in time, and in
|
||||
// best equivalent proof of work) than the best header chain we know about.
|
||||
|
||||
We make no assertion about the significance of fingerprinting for Zcash,
|
||||
and (despite the word "prevent" in the above comment) no claim about the
|
||||
effectiveness of this mitigation.
|
||||
|
||||
In any case, to estimate the "best equivalent proof of work" of a given block
|
||||
chain (measured in units of time), we take the total work of the chain as
|
||||
defined in section 7.7.5 of the Zcash Protocol Specification [#protocol-workdef]_,
|
||||
divide by the work of the block at the active tip, and multiply by the target
|
||||
block spacing of that block.
|
||||
|
||||
It is not a requirement of the Zcash protocol that this fingerprinting
|
||||
mitigation is used; however, if it is used, then it SHOULD use the target
|
||||
block spacing at the same block height that is used for the current work
|
||||
estimate.
|
||||
|
||||
|
||||
Monitoring for quicker- or slower-than-expected blocks
|
||||
''''''''''''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
`zcashd` previously did this monitoring every 150 seconds; it is now done
|
||||
every 60 seconds.
|
||||
|
||||
|
||||
Block timeout
|
||||
'''''''''''''
|
||||
|
||||
The timeout for a requested block is calculated as the target block time,
|
||||
multiplied by 2 + (the number of queued validated headers)/2.
|
||||
|
||||
|
||||
Latency optimization when requesting blocks
|
||||
'''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
When `zcashd` sees an announced block that chains from headers that it does
|
||||
not already have, it will first ask for the headers, and then the block itself.
|
||||
A latency optimization is performed only if the chain is "nearly synced"::
|
||||
|
||||
// First request the headers preceding the announced block. In the normal fully-synced
|
||||
// case where a new block is announced that succeeds the current tip (no reorganization),
|
||||
// there are no such headers.
|
||||
// Secondly, and only when we are close to being synced, we request the announced block directly,
|
||||
// to avoid an extra round-trip. Note that we must *first* ask for the headers, so by the
|
||||
// time the block arrives, the header chain leading up to it is already validated. Not
|
||||
// doing this will result in the received block being rejected as an orphan in case it is
|
||||
// not a direct successor.
|
||||
|
||||
The heuristic for "nearly synced" is that the timestamp of the block at the active tip
|
||||
is no more than 20 block times before the current "adjusted time". In `zcashd` this
|
||||
calculation uses the block target spacing as of the best known header. Around Blossom
|
||||
activation when the block target spacing changes, this could cause the heuristic to be
|
||||
based on the pre-Blossom block target spacing until the node has synced headers past the
|
||||
activation block, but this is not anticipated to cause any problem.
|
||||
|
||||
|
||||
Response to getblocks message when pruning
|
||||
''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
If pruning is enabled, when `zcashd` responds to an "getblocks" peer-to-peer message,
|
||||
it will only include blocks that it has on disk, and is likely to still have on disk
|
||||
an hour after responding to the message::
|
||||
|
||||
// If pruning, don't inv blocks unless we have on disk and are likely to still have
|
||||
// for some reasonable time window (1 hour) that block relay might require.
|
||||
|
||||
For each block, when estimating whether it will still be on disk after an hour, we
|
||||
take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected
|
||||
in one hour at the target block spacing as of that block. Around Blossom activation,
|
||||
this might underestimate the number of blocks in the next hour, but given the value
|
||||
of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.
|
||||
|
||||
|
||||
Estimation of fully synced chain height
|
||||
'''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
`zcashd` uses the ``EstimateNetHeight`` function to estimate the approximate height
|
||||
of the fully synced chain, so that the progress of block download can be displayed to
|
||||
the node operator. This function has been rewritten, simplified, and changed to take
|
||||
account of cases where the time period that needs to be estimated crosses Blossom
|
||||
activation.
|
||||
|
||||
|
||||
Other block-related constants
|
||||
'''''''''''''''''''''''''''''
|
||||
|
||||
The following constants, measured in number of blocks, were reviewed and a
|
||||
decision was made not to change them::
|
||||
|
||||
/** The number of blocks within expiry height when a tx is considered to be expiring soon */
|
||||
TX_EXPIRING_SOON_THRESHOLD = 3
|
||||
|
||||
/** Maximum reorg length we will accept before we shut down and alert the user. */
|
||||
MAX_REORG_LENGTH = COINBASE_MATURITY - 1;
|
||||
|
||||
static const int COINBASE_MATURITY = 100;
|
||||
|
||||
/** Number of blocks that can be requested at any given time from a single peer. */
|
||||
static const int MAX_BLOCKS_IN_TRANSIT_PER_PEER = 16;
|
||||
|
||||
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;
|
||||
|
||||
/** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */
|
||||
static const unsigned int MIN_BLOCKS_TO_KEEP = 288;
|
||||
|
||||
/**
|
||||
* The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks).
|
||||
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
|
||||
*/
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This proposal will be deployed with the Blossom network upgrade. [#zip-0206]_
|
||||
|
||||
|
||||
Backward compatibility
|
||||
======================
|
||||
|
||||
This proposal intentionally creates what is known as a "bilateral consensus
|
||||
rule change". Use of this mechanism requires that all network participants
|
||||
upgrade their software to a compatible version within the upgrade window.
|
||||
Older software will treat post-upgrade blocks as invalid, and will follow any
|
||||
pre-upgrade consensus branch that persists.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
https://github.com/zcash/zcash/pull/4025
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
|
||||
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
|
||||
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion <protocol/protocol.pdf#nbits>`_
|
||||
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work <protocol/protocol.pdf#workdef>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
|
||||
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
|
||||
.. [#zip-0308] `ZIP 308: Sprout to Sapling Migration <zip-0308.rst>`_
|
||||
.. [#slowfastblocks] `On Slow and Fast Block Times <https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/>`_
|
|
@ -0,0 +1,77 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 209
|
||||
Title: Prohibit Negative Shielded Chain Value Pool Balances
|
||||
Owners: Sean Bowe <sean@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-02-25
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", 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>The term "block chain" and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The "Sprout chain value pool balance" for a given block chain is the sum of all <code>vpub_old</code> fields for transactions in the block chain, minus the sum of all <code>vpub_new</code> fields for transactions in the block chain.</p>
|
||||
<p>The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceSapling</code> fields for transactions in the block chain.</p>
|
||||
<p>The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceOrchard</code> fields for transactions in the block chain. (Before NU5 has activated, the Orchard chain value pool balance is zero.)</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">2</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 how the consensus rules are altered such that blocks that produce negative shielded chain value pool balances are prohibited.</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>It is possible for nodes to monitor the total value of notes that are shielded to, or unshielded from, each of the Sprout, Sapling, and Orchard value pools. If the total value that is unshielded exceeds the total value that was shielded for a given pool, a balance violation has occurred in the corresponding shielded transaction protocol.</p>
|
||||
<p>It would be preferable for the network to reject blocks that result in the aforementioned balance violation. However, nodes do not currently react to such an event. Remediation may therefore require chain rollbacks and other disruption.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or "Orchard chain value pool balance" would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.</p>
|
||||
<p>Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned restriction.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 <a id="id4" class="footnote_reference" href="#zip-0200">3</a> and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.</p>
|
||||
<p>There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s) will be produced that violate it, potentially leading to network fragmentation. This is considered sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.</p>
|
||||
<p>This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet. The application to the Orchard chain value pool balance will be deployed from NU5 activation <a id="id5" class="footnote_reference" href="#zip-0252">4</a>.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0252" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,89 @@
|
|||
::
|
||||
|
||||
ZIP: 209
|
||||
Title: Prohibit Negative Shielded Chain Value Pool Balances
|
||||
Owners: Sean Bowe <sean@electriccoin.co>
|
||||
Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-02-25
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in
|
||||
RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "block chain" and "network upgrade" are to be interpreted as defined in [#zip-0200]_.
|
||||
|
||||
The "Sprout chain value pool balance" for a given block chain is the sum of all ``vpub_old``
|
||||
fields for transactions in the block chain, minus the sum of all ``vpub_new`` fields for
|
||||
transactions in the block chain.
|
||||
|
||||
The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all
|
||||
``valueBalanceSapling`` fields for transactions in the block chain.
|
||||
|
||||
The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all
|
||||
``valueBalanceOrchard`` fields for transactions in the block chain. (Before NU5 has activated,
|
||||
the Orchard chain value pool balance is zero.)
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the
|
||||
Zcash Protocol Specification [#protocol-networks]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines how the consensus rules are altered such that blocks that produce negative
|
||||
shielded chain value pool balances are prohibited.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
It is possible for nodes to monitor the total value of notes that are shielded to, or unshielded from,
|
||||
each of the Sprout, Sapling, and Orchard value pools. If the total value that is unshielded exceeds the
|
||||
total value that was shielded for a given pool, a balance violation has occurred in the corresponding
|
||||
shielded transaction protocol.
|
||||
|
||||
It would be preferable for the network to reject blocks that result in the aforementioned balance violation.
|
||||
However, nodes do not currently react to such an event. Remediation may therefore require chain rollbacks
|
||||
and other disruption.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or
|
||||
"Orchard chain value pool balance" would become negative in the block chain created as a result of
|
||||
accepting a block, then all nodes MUST reject the block as invalid.
|
||||
|
||||
Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned
|
||||
restriction.
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 [#zip-0200]_
|
||||
and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all
|
||||
nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.
|
||||
|
||||
There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s)
|
||||
will be produced that violate it, potentially leading to network fragmentation. This is considered
|
||||
sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.
|
||||
|
||||
This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet.
|
||||
The application to the Orchard chain value pool balance will be deployed from NU5 activation
|
||||
[#zip-0252]_.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
|
|
@ -0,0 +1,96 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 210: Sapling Anchor Deduplication within Transactions</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 210
|
||||
Title: Sapling Anchor Deduplication within Transactions
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Status: Withdrawn
|
||||
Category: Consensus
|
||||
Created: 2019-03-27
|
||||
License: MIT</pre>
|
||||
<section id="status"><h2><span class="section-heading">Status</span><span class="section-anchor"> <a rel="bookmark" href="#status"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP has been withdrawn because a similar change has been incorporated into the ZIP 225 proposal for a version 5 transaction format. <a id="id1" class="footnote_reference" href="#zip-0225">5</a></p>
|
||||
</section>
|
||||
<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" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id2" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id4" class="footnote_reference" href="#zip-0205">4</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 modification to the transaction format whereby a single Sapling anchor is used for all Sapling spends. This change removes a potential implementation fingerprint, and reduces the size of Sapling transactions within the block chain.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Sapling network upgrade <a id="id5" class="footnote_reference" href="#zip-0205">4</a> introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.</p>
|
||||
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="id6" class="footnote_reference" href="#protocol-txnencoding">2</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
|
||||
<p>Modifying the transaction format to have a single Sapling anchor field, instead of one field per Sapling spend, removes the ability (within the new transaction format version) to create transactions with this fingerprint. It also reduces the size of the transaction, costing 32 bytes per transaction instead of 32 bytes per spend.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A new transaction format is defined, identical to the Sapling v4 transaction format except for two changes:</p>
|
||||
<ul>
|
||||
<li>The <code>anchor</code> field in <code>SpendDescription</code> is removed.</li>
|
||||
<li>A new field <code>saplingAnchor</code> is placed between <code>vShieldedOutput</code> and <code>vJoinSplit</code>, if and only if <code>vShieldedSpend</code> is not empty.</li>
|
||||
</ul>
|
||||
<p>Consensus rules that previously applied to individual <code>anchor</code> entries MUST be applied to <code>saplingAnchor</code>.</p>
|
||||
<p>TODO: If this is the only ZIP updating the transaction format in a NU, specify the full transaction format here. Otherwise, reference the new transaction format when specified.</p>
|
||||
<p>Implementations that support older transaction formats MAY copy <code>saplingAnchor</code> into each spend's in-memory representation during parsing to reduce code duplication, and MUST ensure that these per-spend in-memory anchors are all identical prior to serialization.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Placing the <code>saplingAnchor</code> field after <code>vShieldedOutput</code> means that it can be conditionally included (saving space when there are no Sapling spends), while ensuring that the transaction can still be parsed unambiguously.</p>
|
||||
<p>Requiring all Sapling spends to use the same anchor removes a possible performance optimisation in certain classes of (particularly light) wallets, where witnesses for older notes are only updated periodically instead of every block. This optimisation is exactly the kind of behaviour that can be used as a fingerprint in the v4 transaction format, and that we are choosing to prevent with this proposal.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal eliminates a possible avenue for distinguishing transactions based on the client implementation that created them.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>TBD</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="protocol-txnencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0205" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0225" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0225">ZIP 225: Version 5 Transaction Format</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,119 @@
|
|||
::
|
||||
|
||||
ZIP: 210
|
||||
Title: Sapling Anchor Deduplication within Transactions
|
||||
Owners: Jack Grigg <str4d@electriccoin.co>
|
||||
Status: Withdrawn
|
||||
Category: Consensus
|
||||
Created: 2019-03-27
|
||||
License: MIT
|
||||
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
This ZIP has been withdrawn because a similar change has been incorporated into the
|
||||
ZIP 225 proposal for a version 5 transaction format. [#zip-0225]_
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST" and "MAY" in this document are to be interpreted as described in
|
||||
RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as described in ZIP 200
|
||||
[#zip-0200]_.
|
||||
|
||||
The term "Sapling" in this document is to be interpreted as described in ZIP 205
|
||||
[#zip-0205]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines a modification to the transaction format whereby a single Sapling
|
||||
anchor is used for all Sapling spends. This change removes a potential implementation
|
||||
fingerprint, and reduces the size of Sapling transactions within the block chain.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
The Sapling network upgrade [#zip-0205]_ introduced new shielded inputs (spends) and
|
||||
outputs. Each spend proves the existence of the note being spent by including the anchor
|
||||
of a Merkle tree that contains the note's commitment, and proving in zero knowledge the
|
||||
existence of a path from the commitment to the anchor (a witness). Valid anchors
|
||||
correspond to the state of the Sapling commitment tree after each block in the chain.
|
||||
|
||||
The choice of anchor leaks information about the note being spent, namely that the note
|
||||
was created no later than the anchor's block height. This is an unavoidable outcome of the
|
||||
Zcash design, and the least information it is possible to leak about a note being spent.
|
||||
However, the Sapling v4 transaction format [#protocol-txnencoding]_ includes
|
||||
a separate anchor for each Sapling spend, and thus it is possible to leak additional
|
||||
information by using different anchors for different notes. The anchor selection choices
|
||||
could also be used as a fingerprint to identify transactions created by particular wallet
|
||||
implementations, reducing the privacy set.
|
||||
|
||||
Modifying the transaction format to have a single Sapling anchor field, instead of one
|
||||
field per Sapling spend, removes the ability (within the new transaction format version)
|
||||
to create transactions with this fingerprint. It also reduces the size of the transaction,
|
||||
costing 32 bytes per transaction instead of 32 bytes per spend.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
A new transaction format is defined, identical to the Sapling v4 transaction format
|
||||
except for two changes:
|
||||
|
||||
- The ``anchor`` field in ``SpendDescription`` is removed.
|
||||
- A new field ``saplingAnchor`` is placed between ``vShieldedOutput`` and ``vJoinSplit``,
|
||||
if and only if ``vShieldedSpend`` is not empty.
|
||||
|
||||
Consensus rules that previously applied to individual ``anchor`` entries MUST be applied
|
||||
to ``saplingAnchor``.
|
||||
|
||||
TODO: If this is the only ZIP updating the transaction format in a NU, specify the full
|
||||
transaction format here. Otherwise, reference the new transaction format when specified.
|
||||
|
||||
Implementations that support older transaction formats MAY copy ``saplingAnchor`` into
|
||||
each spend's in-memory representation during parsing to reduce code duplication, and MUST
|
||||
ensure that these per-spend in-memory anchors are all identical prior to serialization.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
Placing the ``saplingAnchor`` field after ``vShieldedOutput`` means that it can be
|
||||
conditionally included (saving space when there are no Sapling spends), while ensuring
|
||||
that the transaction can still be parsed unambiguously.
|
||||
|
||||
Requiring all Sapling spends to use the same anchor removes a possible performance
|
||||
optimisation in certain classes of (particularly light) wallets, where witnesses for older
|
||||
notes are only updated periodically instead of every block. This optimisation is exactly
|
||||
the kind of behaviour that can be used as a fingerprint in the v4 transaction format, and
|
||||
that we are choosing to prevent with this proposal.
|
||||
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
This proposal eliminates a possible avenue for distinguishing transactions based on the
|
||||
client implementation that created them.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
TBD
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
|
||||
.. [#zip-0225] `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`_
|
|
@ -0,0 +1,140 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 211
|
||||
Title: Disabling Addition of New Value to the Sprout Chain Value Pool
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Sean Bowe
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-03-29
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The term "Sprout shielded protocol" in this document refers to the shielded payment protocol defined at the launch of the Zcash network.</p>
|
||||
<p>The term "Sapling shielded protocol" in this document refers to the shielded payment protocol introduced in the Sapling network upgrade <a id="id3" class="footnote_reference" href="#zip-0205">4</a> <a id="id4" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>The term "Sprout chain value pool balance" in this document is to be interpreted as described in ZIP 209 <a id="id5" class="footnote_reference" href="#zip-0209">5</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 disables the ability to add new value to the Sprout chain value pool balance. This takes a step toward being able to remove the Sprout shielded protocol, thus reducing the overall complexity and attack surface of Zcash.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The first iteration of the Zcash network, called Sprout, provided a shielded payment protocol that was relatively closely based on the original Zerocash proposal. <a id="id6" class="footnote_reference" href="#zerocash">8</a></p>
|
||||
<p>The Sapling network upgrade <a id="id7" class="footnote_reference" href="#zip-0205">4</a> introduced significant efficiency and functionality improvements for shielded transactions. It is expected that over time, the use of Sapling will replace the use of Sprout in shielded transactions.</p>
|
||||
<p>The Sapling and Sprout shielded protocols employ different cryptographic designs. Since an adversary could potentially exploit any vulnerability in either design, supporting both presents additional risk over supporting only the newer Sapling shielded protocol.</p>
|
||||
<p>For example, a vulnerability was discovered in the zero-knowledge proving system originally used by Zcash that could have allowed counterfeiting <a id="id8" class="footnote_reference" href="#counterfeiting">9</a>. While this particular vulnerability was addressed (also for Sprout shielded transactions) by the Sapling upgrade, and we are not aware of others at the time of writing, the possibility of other cryptographic weaknesses cannot be entirely ruled out.</p>
|
||||
<p>In addition, the Zcash specification and implementation incurs complexity and "technical debt" from the requirement to support and test both shielded payment protocols.</p>
|
||||
<p>Removing the ability to add to the Sprout chain value pool balance, is a first step toward reducing this complexity and potential risk. This does not prevent extracting value held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses via the migration tool <a id="id9" class="footnote_reference" href="#zip-0308">7</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Consensus rule: From the relevant activation height, the <code>vpub_old</code> field of each JoinSplit description MUST be zero.</p>
|
||||
<p>When this proposal is activated, nodes and wallets MUST disable any facilities to create transactions that have both one or more outputs to Sprout addresses, and one or more inputs from non-Sprout addresses. This SHOULD be made clear in user interfaces and API documentation.</p>
|
||||
<p>Notes:</p>
|
||||
<ul>
|
||||
<li>The requirement on wallets is intentionally slightly stronger than that enforced by the consensus rule. It is possible to construct a mixed transaction with inputs from both Sprout and non-Sprout addresses, in which all <code>vpub_old</code> fields are zero, but there are nevertheless sufficient funds from Sprout inputs to balance the Sprout outputs. This is prohibited for usability reasons, but not by consensus.</li>
|
||||
<li>The facility to send to Sprout addresses, even before activation of this proposal, is OPTIONAL for a particular node or wallet implementation.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This design does not require any change to the JoinSplit circuit, thus minimizing the risk of security regressions, and avoiding the need for a new ceremony to generate circuit parameters.</p>
|
||||
<p>The code changes needed are very small and simple, and their security is easy to analyse.</p>
|
||||
<p>During the development of this proposal, alternative designs were considered that would have removed some fields of a JoinSplit description. These alternatives were abandoned for several reasons:</p>
|
||||
<ul>
|
||||
<li>Privacy concerns raised as a consequence of preventing the use of internal change between JoinSplits, and/or change sent back to the input Sprout addresses. This would have required the total value of the input Sprout notes (or, for some considered designs, the total value of the two Sprout inputs to each JoinSplit) to be leaked. As it is, there is an unavoidable leak of the total value extracted from the Sprout value pool, but not of the sum of values of particular subsets of notes.</li>
|
||||
<li>Modifications would have been needed to the design of the Sprout to Sapling migration procedure described in <a id="id10" class="footnote_reference" href="#zip-0308">7</a>.</li>
|
||||
<li>A new transaction version would have been required.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The security motivations for making this change are described in the Motivation section. Privacy concerns that led to the current design are discussed in the Rationale section.</p>
|
||||
<p>Since all clients change their behaviour at the same time from this proposal's activation height, there is no additional client distinguisher.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id11" class="footnote_reference" href="#zip-0251">6</a></p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/4489">https://github.com/zcash/zcash/pull/4489</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0205" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0209" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0209">ZIP 209: Prohibit Negative Shielded Value Pool</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0308" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="zip-0308">ZIP 308: Sprout to Sapling Migration</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zerocash" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="https://eprint.iacr.org/2014/349">Zerocash: Decentralized Anonymous Payments from Bitcoin (extended version)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="counterfeiting" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/">Zcash Counterfeiting Vulnerability Successfully Remediated</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,154 @@
|
|||
::
|
||||
|
||||
ZIP: 211
|
||||
Title: Disabling Addition of New Value to the Sprout Chain Value Pool
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Credits: Sean Bowe
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-03-29
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted
|
||||
as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as described in ZIP 200
|
||||
[#zip-0200]_.
|
||||
|
||||
The term "Sprout shielded protocol" in this document refers to the shielded payment protocol
|
||||
defined at the launch of the Zcash network.
|
||||
|
||||
The term "Sapling shielded protocol" in this document refers to the shielded payment protocol
|
||||
introduced in the Sapling network upgrade [#zip-0205]_ [#protocol]_.
|
||||
|
||||
The term "Sprout chain value pool balance" in this document is to be interpreted as described
|
||||
in ZIP 209 [#zip-0209]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal disables the ability to add new value to the Sprout chain value pool balance.
|
||||
This takes a step toward being able to remove the Sprout shielded protocol, thus reducing
|
||||
the overall complexity and attack surface of Zcash.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
The first iteration of the Zcash network, called Sprout, provided a shielded payment
|
||||
protocol that was relatively closely based on the original Zerocash proposal. [#zerocash]_
|
||||
|
||||
The Sapling network upgrade [#zip-0205]_ introduced significant efficiency and
|
||||
functionality improvements for shielded transactions. It is expected that over time,
|
||||
the use of Sapling will replace the use of Sprout in shielded transactions.
|
||||
|
||||
The Sapling and Sprout shielded protocols employ different cryptographic designs.
|
||||
Since an adversary could potentially exploit any vulnerability in either design,
|
||||
supporting both presents additional risk over supporting only the newer Sapling shielded
|
||||
protocol.
|
||||
|
||||
For example, a vulnerability was discovered in the zero-knowledge proving system
|
||||
originally used by Zcash that could have allowed counterfeiting [#counterfeiting]_.
|
||||
While this particular vulnerability was addressed (also for Sprout shielded transactions)
|
||||
by the Sapling upgrade, and we are not aware of others at the time of writing, the
|
||||
possibility of other cryptographic weaknesses cannot be entirely ruled out.
|
||||
|
||||
In addition, the Zcash specification and implementation incurs complexity and
|
||||
"technical debt" from the requirement to support and test both shielded payment
|
||||
protocols.
|
||||
|
||||
Removing the ability to add to the Sprout chain value pool balance, is a first step
|
||||
toward reducing this complexity and potential risk. This does not prevent extracting value
|
||||
held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses
|
||||
via the migration tool [#zip-0308]_.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
Consensus rule: From the relevant activation height, the ``vpub_old`` field of each
|
||||
JoinSplit description MUST be zero.
|
||||
|
||||
When this proposal is activated, nodes and wallets MUST disable any facilities to create
|
||||
transactions that have both one or more outputs to Sprout addresses, and one or more
|
||||
inputs from non-Sprout addresses. This SHOULD be made clear in user interfaces and API
|
||||
documentation.
|
||||
|
||||
Notes:
|
||||
|
||||
* The requirement on wallets is intentionally slightly stronger than that enforced
|
||||
by the consensus rule. It is possible to construct a mixed transaction with inputs
|
||||
from both Sprout and non-Sprout addresses, in which all ``vpub_old`` fields are zero,
|
||||
but there are nevertheless sufficient funds from Sprout inputs to balance the Sprout
|
||||
outputs. This is prohibited for usability reasons, but not by consensus.
|
||||
|
||||
* The facility to send to Sprout addresses, even before activation of this proposal,
|
||||
is OPTIONAL for a particular node or wallet implementation.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
This design does not require any change to the JoinSplit circuit, thus minimizing
|
||||
the risk of security regressions, and avoiding the need for a new ceremony to generate
|
||||
circuit parameters.
|
||||
|
||||
The code changes needed are very small and simple, and their security is easy to
|
||||
analyse.
|
||||
|
||||
During the development of this proposal, alternative designs were considered that
|
||||
would have removed some fields of a JoinSplit description. These alternatives were
|
||||
abandoned for several reasons:
|
||||
|
||||
* Privacy concerns raised as a consequence of preventing the use of internal change
|
||||
between JoinSplits, and/or change sent back to the input Sprout addresses. This
|
||||
would have required the total value of the input Sprout notes (or, for some considered
|
||||
designs, the total value of the two Sprout inputs to each JoinSplit) to be leaked.
|
||||
As it is, there is an unavoidable leak of the total value extracted from the Sprout
|
||||
value pool, but not of the sum of values of particular subsets of notes.
|
||||
|
||||
* Modifications would have been needed to the design of the Sprout to Sapling migration
|
||||
procedure described in [#zip-0308]_.
|
||||
|
||||
* A new transaction version would have been required.
|
||||
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
The security motivations for making this change are described in the Motivation section.
|
||||
Privacy concerns that led to the current design are discussed in the Rationale section.
|
||||
|
||||
Since all clients change their behaviour at the same time from this proposal's activation
|
||||
height, there is no additional client distinguisher.
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This proposal will be deployed with the Canopy network upgrade. [#zip-0251]_
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
https://github.com/zcash/zcash/pull/4489
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
|
||||
.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Value Pool <zip-0209.rst>`_
|
||||
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
|
||||
.. [#zip-0308] `ZIP 308: Sprout to Sapling Migration <zip-0308.rst>`_
|
||||
.. [#zerocash] `Zerocash: Decentralized Anonymous Payments from Bitcoin (extended version) <https://eprint.iacr.org/2014/349>`_
|
||||
.. [#counterfeiting] `Zcash Counterfeiting Vulnerability Successfully Remediated <https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/>`_
|
|
@ -0,0 +1,446 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext</title>
|
||||
<meta charset="utf-8" />
|
||||
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
<pre>ZIP: 212
|
||||
Title: Allow Recipient to Derive Ephemeral Secret from Note Plaintext
|
||||
Owners: Sean Bowe <sean@electriccoin.co>
|
||||
Status: Final
|
||||
Category: Consensus
|
||||
Created: 2019-03-31
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The following functions are defined in the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol">2</a> according to the type (Sapling or Orchard) of note plaintext being processed:</p>
|
||||
<ul>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{ToScalar}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{ToScalar^{Sapling}}\)</span>
|
||||
defined in section 4.2.2 <a id="id3" class="footnote_reference" href="#protocol-saplingkeycomponents">5</a> or
|
||||
<span class="math">\(\mathsf{ToScalar^{Orchard}}\)</span>
|
||||
defined in section 4.2.3 <a id="id4" class="footnote_reference" href="#protocol-orchardkeycomponents">6</a>;</li>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{DiversifyHash}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathsf{DiversifyHash^{Orchard}}\)</span>
|
||||
defined in section 5.4.1.6 <a id="id5" class="footnote_reference" href="#protocol-concretediversifyhash">12</a>;</li>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{KA}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{KA^{Sapling}}\)</span>
|
||||
defined in section 5.4.5.3 <a id="id6" class="footnote_reference" href="#protocol-concretesaplingkeyagreement">13</a> or
|
||||
<span class="math">\(\mathsf{KA^{Orchard}}\)</span>
|
||||
defined in section 5.4.5.5 <a id="id7" class="footnote_reference" href="#protocol-concreteorchardkeyagreement">14</a>;</li>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{NoteCommit}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{NoteCommit^{Sapling}}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathsf{NoteCommit^{Orchard}}\)</span>
|
||||
defined in section 4.1.8 <a id="id8" class="footnote_reference" href="#protocol-abstractcommit">4</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP proposes a new note plaintext format for Sapling Outputs (later extended to include Orchard Actions) in transactions. The new format allows recipients to verify that the sender of an Output or Action knows the private key corresponding to the ephemeral Diffie-Hellman key, in order to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Sapling and Orchard payment protocols have a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.</p>
|
||||
<p>The feature works by allowing payment addresses to become a tuple
|
||||
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
|
||||
of a public key
|
||||
<span class="math">\(\mathsf{pk_d}\)</span>
|
||||
and
|
||||
<span class="math">\(88\)</span>
|
||||
-bit diversifier
|
||||
<span class="math">\(\mathsf{d}\)</span>
|
||||
such that
|
||||
<span class="math">\(\mathsf{pk_d} = [\mathsf{ivk}]\, \mathsf{DiversifyHash}(\mathsf{d})\)</span>
|
||||
for some incoming viewing key
|
||||
<span class="math">\(\mathsf{ivk}\)</span>
|
||||
. The hash function
|
||||
<span class="math">\(\mathsf{DiversifyHash}(\mathsf{d})\)</span>
|
||||
maps from a diversifier to prime-order elements of the Jubjub or Pallas elliptic curve. It is possible for a user to choose many
|
||||
<span class="math">\(\mathsf{d}\)</span>
|
||||
to create several distinct and unlinkable payment addresses of this form.</p>
|
||||
<p>In order to make a payment to a Sapling or Orchard address, an ephemeral secret
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
is sampled by the sender and an ephemeral public key
|
||||
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{DiversifyHash}(\mathsf{d})\)</span>
|
||||
is included in the Output or Action description. Then, a shared Diffie-Hellman secret is computed by the sender as
|
||||
<span class="math">\(\mathsf{KA.Agree}(\mathsf{esk}, \mathsf{pk_d})\)</span>
|
||||
. The recipient can recover this shared secret without knowledge of the particular
|
||||
<span class="math">\(\mathsf{d}\)</span>
|
||||
by computing
|
||||
<span class="math">\(\mathsf{KA.Agree}(\mathsf{ivk}, \mathsf{epk})\)</span>
|
||||
. This shared secret is then used as part of note decryption.</p>
|
||||
<p>Naïvely, the recipient cannot know which
|
||||
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
|
||||
was used to compute the shared secret, but the sender is asked to include the
|
||||
<span class="math">\(\mathsf{d}\)</span>
|
||||
within the note plaintext to reconstruct the note. However, if the recipient has more than one known address, an attacker could use a different payment address to perform secret exchange and, by observing the behavior of the recipient, link the two diversified addresses together. (This attacker strategy was discovered by Brian Warner earlier in the design of the Sapling protocol.)</p>
|
||||
<p>In order to prevent this attack, before activation of this ZIP the protocol forced the sender to prove knowledge of the discrete logarithm of
|
||||
<span class="math">\(\mathsf{epk}\)</span>
|
||||
with respect to the
|
||||
<span class="math">\(\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})\)</span>
|
||||
included within the note commitment. This
|
||||
<span class="math">\(\mathsf{g_d}\)</span>
|
||||
is determined by
|
||||
<span class="math">\(\mathsf{d}\)</span>
|
||||
and recomputed during note decryption, and so either the note decryption will fail, or the sender will be unable to produce the proof that requires knowledge of the discrete logarithm.</p>
|
||||
<p>However, the latter proof was part of the Sapling Output statement, and so relied on the soundness of the underlying Groth16 zk-SNARK — hence on relatively strong cryptographic assumptions and a trusted setup. It is preferable to force the sender to transfer sufficient information in the note plaintext to allow deriving
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
, so that, during note decryption, the recipient can check that
|
||||
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
|
||||
for the expected
|
||||
<span class="math">\(\mathsf{g_d}\)</span>
|
||||
, and ignore the payment as invalid otherwise. For Sapling, this forms a line of defense in the case that soundness of the zk-SNARK does not hold. For Orchard, this check is essential because (for efficiency and simplicity)
|
||||
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
|
||||
is <em>not</em> checked in the Action statement.</p>
|
||||
<p>Merely sending
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
to the recipient in the note plaintext would require us to enlarge the note plaintext, but also would compromise the proof of IND-CCA2 security for in-band secret distribution. We avoid both of these concerns by using a key derivation to obtain both
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
and
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
|
||||
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
|
||||
for the purposes of this ZIP. This function is keyed by a 256-bit key
|
||||
<span class="math">\(\mathsf{sk}\)</span>
|
||||
and takes an arbitrary length byte sequence as input, returning a
|
||||
<span class="math">\(64\)</span>
|
||||
-byte sequence as output.</p>
|
||||
<section id="changes-to-sapling-and-orchard-note-plaintexts"><h3><span class="section-heading">Changes to Sapling and Orchard Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-and-orchard-note-plaintexts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-notept">15</a>. Before activation of this ZIP, the encoding of a Sapling note plaintext required that the first byte take the form
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
, indicating the version of the note plaintext. In addition, a
|
||||
<span class="math">\(256\)</span>
|
||||
-bit
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
field exists within the note plaintext and encoding.</p>
|
||||
<p>Following the activation of this ZIP, senders of Sapling or Orchard notes MUST use the following note plaintext format:</p>
|
||||
<ul>
|
||||
<li>The first byte of the encoding MUST take the form
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
(representing the new note plaintext version).</li>
|
||||
<li>The field
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
of the encoding is renamed to
|
||||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
. This field
|
||||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
of the Sapling or Orchard note plaintext no longer takes the type of
|
||||
<span class="math">\(\mathsf{NoteCommit.Trapdoor}\)</span>
|
||||
(as it did for Sapling) but instead is a
|
||||
<span class="math">\(32\)</span>
|
||||
-byte sequence.</li>
|
||||
</ul>
|
||||
<p>The requirement that the former
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
field be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from descriptions of note plaintexts in the Zcash Protocol Specification.</p>
|
||||
</section>
|
||||
<section id="changes-to-the-process-of-sending-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of sending Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling <a id="id12" class="footnote_reference" href="#protocol-saplingsend">7</a> and section 4.7.3 for Orchard <a id="id13" class="footnote_reference" href="#protocol-orchardsend">8</a>. In addition, the process of encrypting a note is described (currently) in section 4.19.1 of the Zcash Protocol Specification <a id="id14" class="footnote_reference" href="#protocol-saplingandorchardencrypt">9</a>. Prior to activation of this ZIP, the sender sampled
|
||||
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||
and the ephemeral private key
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
uniformly at random during this process.</p>
|
||||
<p>After the activation of this ZIP, the sender MUST instead sample a uniformly random
|
||||
<span class="math">\(32\)</span>
|
||||
-byte sequence
|
||||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
. The note plaintext takes
|
||||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
in place of
|
||||
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||
.</p>
|
||||
<p>For Sapling:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||
MUST be computed by the sender as the output of
|
||||
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\)</span>
|
||||
.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
MUST be computed by the sender as the output of
|
||||
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>For Orchard, an encoding of ρ is appended to these PRF inputs, as specified in section 4.7.3 of the Zcash Protocol Specification <a id="id15" class="footnote_reference" href="#protocol-orchardsend">8</a>.</p>
|
||||
</section>
|
||||
<section id="changes-to-the-process-of-receiving-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The process of receiving notes in Sapling is described in sections 4.19.2 and 4.19.3 of the Zcash Protocol Specification. <a id="id16" class="footnote_reference" href="#protocol-decryptivk">10</a> <a id="id17" class="footnote_reference" href="#protocol-decryptovk">11</a></p>
|
||||
<p>There is a "grace period" of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
MUST still be accepted.</p>
|
||||
<p>Let ActivationHeight be the activation height of this ZIP, and let GracePeriodEndHeight be ActivationHeight + 32256.</p>
|
||||
<p>The height of a transaction in a mined block is defined as the height of that block. An implementation MAY also decrypt mempool transactions, in which case the height used is the height of the next block at the time of the check. An implementation SHOULD NOT attempt to decrypt mempool transactions without having obtained a best-effort view of the current block chain height.</p>
|
||||
<p>When the recipient of a note (either using an incoming viewing key or a full viewing key) is able to decrypt a note plaintext, it performs the following check on the plaintext lead byte, based on the height of the containing transaction:</p>
|
||||
<ul>
|
||||
<li>If the height is less than ActivationHeight, then only
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
is accepted as the plaintext lead byte.</li>
|
||||
<li>If the height is at least ActivationHeight and less than GracePeriodEndHeight, then either
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
is accepted as the plaintext lead byte.</li>
|
||||
<li>If the height is at least GracePeriodEndHeight, then only
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
is accepted as the plaintext lead byte.</li>
|
||||
</ul>
|
||||
<p>If the plaintext lead byte is not accepted then the note MUST be discarded. However, if an implementation decrypted the note from a mempool transaction and it was accepted at that time, but it is later mined in a block after the end of the grace period, then it MAY be retained.</p>
|
||||
<p>A note plaintext with lead byte
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
contains a field
|
||||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
that is a
|
||||
<span class="math">\(32\)</span>
|
||||
-byte sequence rather than a scalar value
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
. The recipient, during decryption and in any later contexts, will interpret the value
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
as the output of
|
||||
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\)</span>
|
||||
in the case of Sapling. Further, the recipient MUST compute
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
as
|
||||
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
|
||||
in the case of Sapling, and check that
|
||||
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
|
||||
, failing decryption if this check is not satisfied. For Orchard, an encoding of ρ is appended to the PRF inputs, as for encryption.</p>
|
||||
</section>
|
||||
<section id="consensus-rule-change-for-coinbase-transactions"><h3><span class="section-heading">Consensus rule change for coinbase transactions</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rule-change-for-coinbase-transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <a id="id18" class="footnote_reference" href="#zip-0213">17</a>, MUST have note plaintext lead byte equal to
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
.</p>
|
||||
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="id19" class="footnote_reference" href="#zip-0207">16</a> sent to shielded payment addresses, if there are any.</p>
|
||||
<p>Since NU5 activates after the end of the grace period <a id="id20" class="footnote_reference" href="#zip-0252">19</a>, Orchard outputs will always require a note plaintext lead byte equal to
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The attack that this prevents is an interactive attack that requires an adversary to be able to break critical soundness properties of the zk-SNARKs underlying Sapling. It is potentially valid to assume that this cannot occur, due to other damaging effects on the system such as undetectable counterfeiting. However, we have attempted to avoid any instance in the protocol where privacy (even against interactive attacks) depended on strong cryptographic assumptions. Acting differently here would be confusing for users that have previously been told that "privacy does not depend on zk-SNARK soundness" or similar claims.</p>
|
||||
<p>It is possible for us to infringe on the length of the <code>memo</code> field and ask the sender to provide
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
within the existing note plaintext without modifying the transaction format, but this would harm users who have come to expect a
|
||||
<span class="math">\(512\)</span>
|
||||
-byte memo field to be available to them. Changes to the memo field length should be considered in a broader context than changes made for cryptographic purposes.</p>
|
||||
<p>It is possible to transmit a signature of knowledge of a correct
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
rather than
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
itself, but this appears to be an unnecessary complication and is likely slower than just supplying
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
.</p>
|
||||
<p>The grace period is intended to mitigate loss-of-funds risk due to non-conformant sending wallet implementations. The intention is that during the grace period (of about 4 weeks), it will be possible to identify wallets that are still sending plaintexts according to the old specification, and cajole their developers to make the required updates. For the avoidance of doubt, such wallets are non-conformant because it is a "MUST" requirement to <em>immediately</em> switch to sending note plaintexts with lead byte
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
(and the other changes in this specification) at the upgrade. Note that nodes will clear their mempools when the upgrade activates, which will clear all plaintexts with lead byte
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
that were sent conformantly and not mined before the upgrade.</p>
|
||||
<p>Historical note: in practice some note plaintexts with lead byte
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
were non-conformantly sent even after the end of the specified grace period. ZecWallet extended its implementation of the grace period by a further 161280 blocks (approximately 20 weeks) in order to allow for recovery of these funds <a id="id21" class="footnote_reference" href="#zecwallet-grace-extension">20</a>.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub (or Pallas) elliptic curve, for it could perform a linkability attack trivially in that case.</p>
|
||||
<p>In the naïve case where the protocol is modified so that
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
is supplied directly to the recipient (rather than derived through
|
||||
<span class="math">\(\mathsf{rseed}\)</span>
|
||||
) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id22" class="footnote_reference" href="#zip-0251">18</a></p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>In zcashd:</p>
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash/zcash/pull/4578">https://github.com/zcash/zcash/pull/4578</a></li>
|
||||
</ul>
|
||||
<p>In librustzcash:</p>
|
||||
<ul>
|
||||
<li><a href="https://github.com/zcash/librustzcash/pull/258">https://github.com/zcash/librustzcash/pull/258</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The discovery that diversified address unlinkability depended on the zk-SNARK knowledge assumption was made by Sean Bowe and Zooko Wilcox.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="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="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-abstractprfs" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf#abstractprfs">Zcash Protocol Specification, Version 2021.2.16. Section 4.1.2: Pseudo Random Functions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-abstractcommit" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#abstractcommit">Zcash Protocol Specification, Version 2021.2.16. Section 4.1.8: Commitment</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingkeycomponents" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2021.2.16. Section 4.2.2: Sapling Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardkeycomponents" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.2.16. Section 4.2.3: Orchard Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingsend" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2021.2.16. Section 4.7.2: Sending Notes (Sapling)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardsend" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2021.2.16. Section 4.7.3: Sending Notes (Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingandorchardencrypt" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingandorchardencrypt">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.1: Encryption (Sapling and Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-decryptivk" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/protocol.pdf#decryptivk">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-decryptovk" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/protocol.pdf#decryptovk">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretediversifyhash" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretesaplingkeyagreement" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="protocol/protocol.pdf#concretesaplingkeyagreement">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.3 Sapling Key Agreement</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concreteorchardkeyagreement" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<td><a href="protocol/protocol.pdf#concreteorchardkeyagreement">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.5 Orchard Key Agreement</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-notept" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<td><a href="protocol/protocol.pdf#notept">Zcash Protocol Specification, Version 2021.2.16. Section 5.5: Encodings of Note Plaintexts and Memo Fields</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0207" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<td><a href="zip-0207">ZIP 207: Split Founders' Reward</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0213" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>18</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0252" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>19</th>
|
||||
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zecwallet-grace-extension" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>20</th>
|
||||
<td><a href="https://github.com/adityapk00/librustzcash/commit/c31a04a4dbfa5a2ac013139db229f41cd421754d">Commit c31a04a in aditypk00/librustzcash: Move ZIP-212 grace period to end of April</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|