From 3de014d33ca06d432c61899371679e0d87c2bd92 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 8 Apr 2021 23:59:30 +0100 Subject: [PATCH] ZIP 316 Work in Progress. Signed-off-by: Daira Hopwood --- zip-0316-f3.png | Bin 0 -> 8447 bytes zip-0316-f4.png | Bin 0 -> 10217 bytes zip-0316.rst | 549 +++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 547 insertions(+), 2 deletions(-) create mode 100644 zip-0316-f3.png create mode 100644 zip-0316-f4.png diff --git a/zip-0316-f3.png b/zip-0316-f3.png new file mode 100644 index 0000000000000000000000000000000000000000..c4dd5abc114a2b6faeeb0a8361ae96eefeac68ca GIT binary patch literal 8447 zcmdUVXH-*L*KR^6Qlv_+h5*t*dPfZ%rAbk$V1h~q>0L#N6hV;Ck){--M4D11gd;={ z5g~+TkS1Nap?n+8d(JrT`0l;qz2(o%7#Z1XuQk`2bFDr1e4aTIZ+cDdEDaY82n0H7 zpbs|(fxw}_*Zd46aEB!?avS&|_q%Lx{S5F4J99e@Xj6OZ-|z#07!W64u=NK4Kmx>h zU&rRYg%|RE;4NPSC@?Tk>aM4opUW+8gp`-BYtE`V7YHN(GJs#Y9+bN>5g3$iIf>m^ z!@;7Teh!spdMa$GT`Ld=eO~_p`c5(3(#JkfQef@fn|BFrYYFe79yqa6fN3kuZ!?u7 zYzbSQVLT&*Ku&61yS$d=+J7sbbFE&BO>P^+V1+c0VTQ!joA~#q8{ic|_V|a(%MzLg>k5iqlln8**NbEI zu`BvSxtsVWm`ehTC6{9=T1cyM?i26u0X!S$Gg|d|N=h?I99prUx9-7Zv+_hevCvfI zEX5Ty!%QhXU0oJ}874Ltg&%NG&S7Z({nYdVyt*&6)^kR6O#ZHm+H-y5s|80I9%J`! zV-u;XZlH6~{qIm;O8fB1LYlW)m#M-P<2nVYHYcC0)rz~ayH4F#tgrlrJRrBDe|oGb=L;vb3KexlZIm`Ch}(q3G7Y2FrwAZ%c$s*-&ovPmqvTA^A46T3Xa;+7)C zNJ>j_tI`S46?ZIid@}_tGA%Dp=lH1FZ+kfKOQ}(yK<_KFwb5i@&0F=$1zZQ`GJ36x zEN84hw-K(gk@&DN1q-~9GhkroiGi{7?4YMP@1LCI{+5>2-0ypFgVqgEz~ApmOpMPR z{FOK{ay3gMMjuvGm-$G}?c42}ZZ(O#Tg&qtBQ@$mikYnmb&t@3%Q_MWmCd-3&kCNx5W zN9jB6_;(ahYZ1Sb&lfPfxN(RyE>Oy=V67NS5N7tPzc(zx91p6w)y1WGxFz{}C*0t@ z56rXb&GJ;x!dawr_9xzyiO%I1G$(1y=GU)Hj$iwXA@-AfNcmLMyX|ksE?-JyTlSnC zfA6$DjyQDq{(-i-k=G~;^YdHZy^IRkAGPO6cDtQJ{5FPy#5^vAiyW%=#j>)N7KY{> z$se94q+(pF*3j%5PqYQJDUw9Gne(JB{rh8=(Ha-W@M>8H9;S_uh7uuSp-fEt`eX~F zEl9AzM+38*OMq7TG(t>g$g2>j{iVbYg7!sjR?^Ztqgq~{>e+Oe`*&6dWZf1<@GGi? zhQx(k|8`bLQS`aX*1B=XQTlX~ADyrVkmw{uzY@maK&soqEG-%|-R{U#Oq$7$e8$cc zNX?f3wv80fa=m9++q3dDyq7Uo{GxXnuEc3I%cB`UR(b|dXnb!e;3-Tgr`mRu z){SuJ!7+kTCl&<3Pn8F*vC2>=pHDep&}o+y;9!3>PfhbKUsk{}F>S;d0TNI?vr}I* zLR8Bp$HnQ{oebHCJ9SOqI>`qPS0|bSLr%M11C##MJayb@bG%!kAe6|I2}r=zi%$I* zxOU+Iv}`&VLS#DKU*MW+2GA1orvX3{aOuCB|FJ#)BLe_a>rdAG-?ir-2E_l&K9p*t z{7Elqg;i`uU!sWgqzMB{)UxYg-tZLWt}sIR7Ufit6>*VF71iL6`Up(au}Nh0q*qdyq(QZ$p&}){rnXPYAAzEk|-&ud%?v+*Q*p z;yimFlYY1sP#nj2%j3Eg0ip@lOm3mCpYI;xm&rlH z9cndnqeX)`h1hV_wV8m|2BHq*0qS^b&guI&?t0cJY=?SfJSGr0YZaQoJL!X7?R}(y zw%%`7a~PUhZSIL3QnniRCA-?_i;&8x)#>fd!r1LbTBkRqwIiKMV(f@l#7Hdq@?5i} zp}#j*;!;F!G|*|RwmvE29W#e&=dd9$gS+6GLkSYYJdF*9=c*Q=slTFj2WxwPH%7YGPf6IG=Zcr_%P@r^Y)&AT&vs zCYLsm>L!Ta#qe0u3AE0)uH;0!j>;$@a)&(JA!q9EbH$*mLEgKxCVX!fx;dpGcRRXK zMN}8)zd~q^dpy8W5MjtMhzqMyyq9Q%D0n4KdaSL5%kk~;=-kS3cW94RP2%?bRW9lB z%sAQ7)k(mc@2PJbNuJ^z$jc?+z}q*95Y6aqop>>UC;dd6%_+I?fN8UA{6ZnsT+M!Q z!+|wg<9$S*g)@&ya%Uq-@Rk-C+pT~R^)p}bOPcmHnhYAfJ-KIbor$4v^_el;krv9? z7;Yq6Ny2I?IZ+{}w$;pvgi^M;3Frp0rw;G7z>OY+mYC|t;Y}ppa$m%v?@ERa4L5x( zH~3*Rvrb51F*})I_u?8En)jl2uH$y#-;;(2GgSS{ooqE&>e6i0^v!_ z>&c%CZ$>_RmSDFN4I(K2;vm}m08>5Q?T;pzyA(s$VROfeR>tMkfG_+<3nFz$UfgJD|lR-)QJ+g0;P5iaJt@^JGLW;d;Y$)Zy^rhSR6qKGD7kP zNn9(<9uD5AG>LoEH6D6t7vkxt>dMF8ejvQx-28SmOwm3hK!j2Gph%H}?)3-UOGFA6 z%G}XnJ@`V6dpqeITi8_rm+B>gi*9fMNNIIfA@b6EBYR4-)lU2c2zo5%64PXq=hp_- z#Zsf%pgErB1Gd_E*ic2Ul5^s^SkbFz=3^Q5-t7+|Wv1sex5B2SuUDBReK%>vj3LCE zzOU`_dY#h}2g?)Jt2KL^`lB~RoR-bhk=8ie@g3I#Xis;k(j69mrG6-`sZ9U4A>FyV zX=^7ZUbk5Nc%EvsA-K;heB!BI!Q2>Wt;}d(^{w)INci#QMVBeg&be*wX-DisyL@ysY)Sg9`|EBEBt3AA4kLVfsp z7ZF<}59H1x{@vzCW$6M6t$~u2{k#B2YryX-T)!d~?eem_uS9mYEdExU169CqUgf_Z zYs_Qro;Aj_d<>N%^>64nUvtT2(Z3*ynTl=eEQ~F$Ilj@Uz|5A|A z9IqdNGN0{T^(*+g^>*TYD263R)>c%H?3i-3!@Zd|7Vk?s>rIa=IP^yey6LFT-o%R# zIYi3REXe$YYZB0P@aTab=i!d2XV^jnNH|>fc{;JXe5&Y%y7O;)srAd9dOA4I+)&xdFpv85 zCg0L!+PesT7bT4YP>RDy4siNUv-7caj&no1uQSg)zT8l}|A`VeiaaY8QrnSHH_|&P z$Xa1Ji}xw0x!o`AJ}{_zqO?v$BAErMnd?7vAgq>QXJTfICY) zy0K9Lpk?BV;EwWB6c9lE+JR^Y9pccd@;Ma*0(G`HLYhbggi?h!8LjzefN&1Xc^ciH ziX$BL#X}8l17TMIQ0o*10M-Ji;0iGIA2aeQw!UtJ1%O%* zVDVE(a!<=ZVPNe#+$?j$+dICoPTdG-8;^JaYnp&TWbgTXZE&m6% z_oCYdy1A@R(aH})yjwQ_Ud|H`1@w09Q~s?{FxngNmNK2By)mBYHEnts&|dX~GBp1N zU1a0_SYTt{XvcuNT z(EiS!^exbRz6O3`bxd8s*($1DCo9dR6|4bIr&EpXGr6&PwV5xT4aK1KzLIidp8Z+2 z2A9g^Cy=wzj!|KSiZv{I6XtxWO+GJ{i#rT)&%B?{N>IN9Ud75Q#7&PLkkd#qFCbO= zy8Vc3`l0~K0$Es0utKnkH>->sJ?Gmxb~pDmtf+k5^rk?iD9p^V^W33_wpJmVDI1!z zP!ky=o%Y#Il*H6wH67XTQ2%lTy}H@@e1*1-(>WO?Wrn?RbE(s{jhuCruS6?qS4=1$ z)!pw`*FAQ<&@O2gHcAR79f>4{y25kKyT|W4-RLYB_^^DCea4-tO*o>MHOU9Vm4ldK z++!RC8I!Go%0S$*Gr8G2Mf*Kf)XzBgri%|$x97Viy+)(vgO^^2(1-HJmV!7bB3Ee+ z=x(#xY4Tn`3a0C;`;f-VKQ$$TL5~8W1N>LdjD%w)W=VQH>bqyr&9X7^`3_XdyAx;jL zjs%lc6}x5sXT<<|GFt?^9s?S&|f>Rv_ z>nWvSIK{pgip+U3m$=A5H-z*z3?R(vhanDnE^*MQTdn&S)4UO9uuJ4T{@S&iwMy@v zfG};}U*8|$2t`dO+A1QMX}Y%vLUEikhfH!6l{D!e++*yx``Y#4M8}Ze1(e z=KiC1JZzz-m!YR*xp?r7>YTtkDU`iTOtsXe%oMj5+rG3O z_v(o#wvM84)@jG=As)>?5NW}gd_48GJ^ew-6>8^*&%964^g??kP1G^LBliA(5WGBt z*$9g4;XeT~RTpg=rFF|{Lm|o#1s#9Dxe@c^fW3K94mb-VqWw;v?B=e|vYN{pm3p#D z>&E0u<5$U|+odSZCDel@6S6lDRq#BS7Dze>MS66Oj-1MA619a{YkxggPj%E;*W7OY z-t3BJM3Zzqw}NuE^h6xzfClBGs2!ACLBQ<+#c{Yqn8!s%H{v1X3I{GZmrpPFI7dc& zzLsR)&Jo0cj(HD;b%JW z8nyX#yg%Rm29#M4*qhxbOO(B$f3o+~97@s;J&G>ULh+*bDMKDACS&P1uRVPJ^7Ber zeo3b2C%m;Cu6*9#d8_c2PWZx%Hc@W^FtcH9G(W%^-a&YVO-;3Fz2zt z`qfJfPd=-x=B4M=XD|y5?KVrH(&5TlOnNJ_#Tl(OE=!r2VUJbBc9?Jhy+%NAO?E1e?*t%Fc zTI-<}o`1-0x%4wrllL)J**S?8h;t^7Sd26CCsZ1HSZ}|vHNhvaQVYG`T7f}BhtL)Y zFh)A_7dNX0Y=xnEMYrF9N;|B@sB7t@WuM$1+EX8;38xRu7g zST}PXo4j)pK(9p}{F7e8BDQ{7Rsqy?8_xJAbxm7%Tgc@0Hz^(d7psO1-n}IF?Qeoy z@h`%!Uo`YU_y1b{Z|-lI0#gl7d7=Pl{wGNv`S*qXG4M|-QsFNtl5C3q;`^0+|J(&E zkeN6M{U@1;KNbCN@<12|^fv|4dU_oJpbe#e<_sbVfvI2Av2R$>e0~<*qdXDK96*e7 z1o(Chdy)@~X_hRK@*cZg+u0_*z0WtHOnpd@>nQzsVsvbj1kM>Lw_Y-#Ow_xHSA)i+ zmzjNdN$9U_RR6#a&T*gD2VIF)i#FHh;BZz--b*z?thwDS9isepH^g^|Mxi3s!xe0! z?4f&SI}I`WE1s?ek`cCp0a!99Vqh02g214^m+_sw1+q9Ct zQP%ps7JcRpy+i{q{NQ8hgmN3-jQ$7io9n@khR+dgPj&)Iq8SAz)&cznF1h6Egb&>Z z4c-7fN1vcy%b#D1LUip3wYO8wO~Y{9X#Z#m?c`xNQ4J8qD)-#^^~#5idtJSfO8OZ1Jv#B>7gzM9EfTISDb)ll`XaCHrRpm?tCbb_lWS7;f~UYUQD?P-r`4y0r+ugI;o|f# z768HjTq2GA)#+Dl-r%dlcjzsnz@2+rEp54yRfcPn{yrrZ!VV6ER72*;T*=lTg3*3a zqE=}MUQJt+ud&K{=egq7S7!#uyhr>}Di+~!rz0LoYu`WC)Knyy)PMCBrNyTXC1Oq@W1fBxH;Qf0fZmURzE+YETHn_5#vj4G{=XBvek4nht%jZuV!vJFwOUBGRQ3% z!_U))%`#(`8z+6966nPgKIKwsxX$-OJp1e#^CPE1c31m=y~p&;Cu+96?Gffj=dF7y zV%OIQJY7AiX&$J^smXg_UYes8w7`HWE~k3LIbt*&^pp3;MlXBVIm50NX75GI2ADu* zuVxfJOJ+ELk>Old%Xw?EJ@6iL5Q9xCi4V-DmQ7W0vzi_x9$_EU;W1lzeeOufQ2;o_ z>uaI(O&WnCQdl~^ew{`;lMDOn$4iiCZFy}c9(aLrww>k|jv$ENn;fPN0bC{e@`|jQ zM}+f~HG3qPLsv^tsAu((k#j^4jJVsX3}gaLZhJ(NqT_j*4Aq6NjujYgFqa?v9vY}} zY)>5=fus?TbVWqceKE`|nkuxm+1r#5PWhc+`Q$kx zb*!l4YnlwV;X?m;bUES2ZG!CKGA*tF7YWXE?rk;Yo1^M@h+4^p=KGZ|&nnB`8P27A zolQtSPu0lbSA(}^2D6=adT-~F* zKlsOji6f8A(GWY;STdQmJXg}?bv?f^Hm20k8&UWQ;j~v)PW}GU%z;v^m&E@Jp#Vh& zIAGeJ+3NoX$=<)S)j$>ufZ%^O|9?$h0|pQf{2(d(+B=KrUbecppxMMjsS$96?H}iz zhwn^lP6tklIi&(TR(6-#Td;;~fkvX^=&})P)f3VHR*M?$=m8SX7&~bJ+EFqI2$ql} z=&VOEt%PgQq}qFUB4*9Eslg|@x8R|a9H(*Im3~N5_-IxF>VSH%&*w;Wy)IWL?2nA* z@3;p8Zn85xsc^aC>CH6?eyGo^A)WzS6;fu?f1a3e3B}Z}PPhbjry(OmmjP+(ppx~_ zmM13}Yp{S&*7SoM^IKnQcg%1T(=N}|wz3GD&gGN|J%{JcBVHs43>$eg6xyz{~B z?qE&KiasTYuq1~Gb7DL$*=za7}B?QoTcj-@wC?-}Q) zC9#P#nhqLW9<3G3QCn+?%2R8UbL#MxYTZI&6N61QL*msc#Yy{pb8=xgZ@%NrnG)Db z(E8V@{5nnpSQ#aK*dxoz=j&MRDUj*Q{*UBj;7?0Jt3Yk9=h#a3r*w_4`f93GR{O|3oB}pOX_`H+K zC{Wo{^iW-G^ZdQF_VJH9m$NRio{8ODiD8+ly}2{dzpN|3=(N$>4f+wg85}uIQs3&m z0*5l?48jv6RGK+JNnG`m0?hF;h~AO6_x#!VG6!6zJM=uTECscy=z&*Roi*UDpoQVs zSJ&S#2L}h=zc&&;a(tv39Tnm8Ja?2!;hs(s7pKHc`Pd3ew@sW}q>!AShGoT9;^siC z_eUY6(c}x7&f!al`GCB|@oRFS2I>X|A6xe4f+)|1q;bj#dw)_0^Z}~6zdEU^zZB_E z{rswe4}fnlEg_`S{;0TKuG1b-z3gWX)P8LZ1tXB*1t-|s1R))ojV}TIFyMXiUx2^r zk$*jJ|5mz;hD9CdM>zF0NH(CA&od`4Yu;B<5{Z3nt3&{ba^|r20iIL>PcIujb9&18 zU0)gRD=hNp@{8O%%8hqrRJMr+E#s~p^Gr;l73t39mB;+$JjV7aQp;C>wLu0t*Whn1 HJ3aU>`o#^M literal 0 HcmV?d00001 diff --git a/zip-0316-f4.png b/zip-0316-f4.png new file mode 100644 index 0000000000000000000000000000000000000000..933e5a781c2e552b3122fea17b6cb8c5f871550f GIT binary patch literal 10217 zcmch72Q*yW*Y}JXL=S=>Q6o{KL?<$OONeeTYV;N@+Kdn*qD3-B7lIJIccKQPBzhM_ z7ovCXB~Sa_^?%>>tZ#kmv({biIrp5oXYYIV{_Wr1C-jlJ0x=;SAqWH_R#Jp$f`ChR=0&N0kMSV9Ah}81p0_!&21ZIF}pULSx({i$U z<_UAP1bKRT^4K`qxtYV9EqR<=trLDq(1AcVK}wJZPrMS>Cq2>Ew8z@Mo9ypk_^#@^ z%0tL-9$b5TO%8|O+GsczJtUN$zuYg!x0s7=ga_IL54OU=skaW(NAI_|{<1ZZyAx;H#cN+Sj;igzM~9Ld3^%gZzgOh;M2k z4LJcgxDKg!<@TB!L{x$e@ygo|m>v1!(?(F(~V=tDZaSyBWv*YbApCU(iR9G{pxzNpHWewY- z)*G67dW{oR)2=_>odOD_lGgk1CO2|z`f!KgWvx(9+(yp_kMOY@L%V#;U$0Dxd6Yoo z6_wQzgd=jaKmF=^xbdyhMaBPk{gJWPcOEMYS|*k!WQ<1xtLNy;S$*u!bi;PXfdVZi zxW06EnzQ+>NpbfIqc}y|iy!DoBF%7_LxH#q%gNw_pL7j!m7AJuM|chDk+>=}ed#KZ zYF+HzXvpr`O6hb-U27*q)2Zz>!L#)-xBhiew@j?QG&w^onI}#-Idq zhLObH^q}i!-<_orPH2<%ezt_nNn1?U?Um^#D|SMd$>W9W>X!F*mQDDrd!9HpoO*|8 zE1~ryWfG#3KW`qtblV8q-|A@55Gia%y!JB1(TMblfAft3&qQ>@%A1+f{dAXf`(*n? zoUp?U0c&-OFHyZuhx5bMi&fDa zeN9BoqhGn4z-r~UueQ_C?l^Q#qZBtWvHRqcPQM2&1#@ew9LR?JX1w~&8=Qe+BP}a} zUkLuR3cdXF(x3yfRNL1}xG1}5(+;j%{?@OTy32{8okJ<~EoxqF;8HKv^3c#XyfEh?H$fcPB_hTZ! zqFsK=12pAYxIHTsc`q*ap(JEJt#v*sq3>*g!CBJRjHeXDRJhw(W(iSh9vL4{k6& zt{%YvNC)J$j$(n$X^w;(fgD&VLU%+90&?3s+Q)cs;qN^sbc-#fPLS(jSga&mczf~> zc&RG|=@nR)3#jOvqa zE~_NV3)K4f8-1ZL_l7*Pqs6(nldsmLW1dW79_#isPY}Y5&_*R0E7wt4nOmET&fNXVYmtR!ebom5#;_JCAq3gEDTzr@4dX7p*4ytbXEUig)K{Z*vL^zLIhf|3I+>GGD zAkVZgp)ZK}toxF2Z;+ngUN_H{Cm`5e^AzZv6pT7aH0r7Tey6AEM>TgKCCUsEi{R=JO$5aSdNVs;iF!f%oyk5+m4GPt)NwwRDZp$fsAC}C zB(}ex9^)Ze>=4(;XNv92%Ew(*3+|)(7+ZTv+(+O4jrNtH&lm+CPq1IqxJU?A7I^T^ zHfu?JGEU=}0;9S?wd?0MVTe^k=D7aiRZLm(&(vA}6C+cyK57wB+}+R|N z_uxH7=Q|H;j2)QCm7({+k6VnKMBBwGWN*!|m`M+~DMFuk zsU;fhs(tbt+{!CZLs5rCLrd`3T3b)Hnk825+Z7LreL@x7qzElkNPj7A=)=iAQ*OQ9 zBem@D_B7y^3OLiLKHZ?$yO#@JFOp!j9pQ-}($Y^^x^E4wP31I-d%;i;`fzY4R@P}U8#~f>ixJq6^JzRGPA(?E_SP`=yz9oU!6tAw zEZ%+9xt~bmQ5Njfp+S%J4U+8e8pVT?{g1EJ8_84){BCa&S{3Bg$~8Vfqo7HyT?MUc zRZ}1dLq~6D>aET998_Vc$#o{xSQQ{OzG=N3K0~}y5*trb8oG_qK)_hHcb6DaP^V*( zkx|HYZM>tD+ zu^~!a*uit~H=Pnng52R@KWl>(S({>pCp%k6@ASN!O=FhwcgIBfYbaD?}@-zTPUb|W>+QB(5oP|oHP=gn5!kwOX z(uH@Qv@%|YVXSE5*5pTM10!ygHzrBgJZx8&$3XSD6&`WCQ!*zy?w#DJm73n(b{cef zTBY?Bd>h^i=jAg|5FzLvPH9^xm|i1z-Li(8sKADg%{&e`C46s-6wP)MUmgcBPmB3x z4FR_kR_dNJmwrE?{g2I$t&`+81T=7OMk_`s+MhO*@$shECt0p$5TM=ePN|+r;vL}h zH`%?k+1+WqF(FB?{ezu38Swm;9Hr}HapF^6h^AU!f5Yn65Udp;8_3{_VRFS_p{3hw zh70Pv7TMNuc-X+LFF*B?Sa7N&<2*Q|D+HY#_X44X*qT<2i9EDz8b`35#j?ZF3#Yra zJMxvc%N@$S1LUpPIgFo6X&494>q-eCy(D^~67XG4;M?WZ`4L`bw-#g^v@xR8Ddtuy zzL9Z$?6X9d2p5^?*Dq9iJU}$z_W2#8|J#yxr%QEt#QD~!Z}^Qe`xZ~YwRy2pgu5OM z#&XWA_rv9LU2Ik|ESOwxi!&CQu+&nWYc+2dO zklj!%zwD0YxVt?{aX!Ddt~TgRuY)edO(Dc!rO+3OUr>CEkQ^j1hh5A?nd@=yA7RNE z!Kn*pQF}(=F#UtyXsXy}Bf~QEC&&(e`~zfvcLS#NoaJw121cEv*Xb6u{Xd-l8_j2# z*6Usg0ZN&=@&|$ks$ zCD|SkLIW-tQ^AC-UJi6w541)19b@U?<>Cp0`~VD|4W(|pGcKnn(rQl=B}nMSdbr=) z7`vxTfWqimHRy5WHLQzuvd*$9hiz?)K0Qm4YvITbI=wO@oXS&(bGz73-PuC7_pG5u zfpIAPP|9ZgyMcE?{1H1B%#J;Y@Mz?0bTteP_3D0Ch_8oJiZ@ki z6oR7#RqZo*O$%Mba>48g<1Gd5!+@|)Z?4Hc@m?>M9ikNoFJ)G)N?du1MU3E@ahUO$ zQ7%>B1TQL&C?J*_>1Bkv%7S{9ZZ%idZ)9WQBphm1C;K*@{jA$mPRUWODr#JtpAIoU z+M$GJGzuIHSI`tSd5ql0O~%tPmERdQ%`{fW#hcMd;4JhvsSiwPNKgYzbsXw+hS|{H zX_iRI*@BGj4d4q@-aaOEjF8^IEput1OMnI3+r-X{tOj{quf)DiC@vJ`sGKzTr8$`f5E*$d-&B@DWbDbH#X0+HZKS!{RQ zD~|CuDGzLQ3n{Ky8bZ!p2ib|?2n z)XAwxVg1CG-J6Ded|OZ~tOuSOOiPfDFOLO{krrp6xjogbydH=Wb=8Go~;TfJcu&dDm8bTbDnx&iV=uQH#SC>wu~94wN?R+sIRAF(#e z_bcIW9!Qx8m=R{wC31V|z^y9tc90R*w)l{uBl`)JRsqw!n1WbMIXSs9&u5e7JR)J( z$2(&Sr%ZKQi%F61!l<`bXERFI`Xb_e2C_HZnXPixJ<%KYo+1zL=OIMX-KqFo6zrzD z2ilE_AGCN1H~Di~JqzI3gjD^|z_x~YEM~nmoZ>n35wm(Vp^c6{4Qa8svk$XikDoekGb9 zgpBQe`XbJjYgU{db}s77X~im)HL(@mF)fPjVt>o262aTaZTKQijsL1Z@y1KhyRQCK zi{z2r*Y6{GmsH69a!6qy@Z8U(CUw0EU1Ydj7a%P z9yPr49`nWAkL6sF)BGYo5)disvT_BpQ?cfdJIrtZ>YpCYFL;6C)r0g48#3Op8OXuC zOT%6CBzjx0*EqLGNMOdp^olbbA596-IpM;Lz4?qbrb9=YPwUQL*#4uu=k7Mu!^sxf z<3o%2UrW{O=*n#Cmpz`#yqN`rhD_*&!o$HGc5%g;#+8kjgz1%CAN+9GtB0hi1wx`(skNKT-{}k%t+H zd}bjzAr;toPPj=;cr+>7Ox<1SIp9o}m!_B4)|e4p=VdWf8dt6|V$s@UVnlC>3y&Y4Y-3!>I<$5@Na6qF@c+izp+*E^4s-u^-N2iLR-#k;g?Wbl8#y0qefRIW z0|bj{>;UdpNB(za;F3wREtQ6cUBLTqwEm6h9xnf_dzR_9Zj3J!@Q(~ZK4XQp zX`1?oCxLGPnr3yv7R2`l?Ug@?#c7r|rP>tf165Lb_1el&hylsNx8^0`Zlas4>;nQL zC$~oM_3$yf>ByYEO7xDrf9+5Nl8p0C+EWz3q-U{bcre2CWCtUTq7=e_fNCb7euN#O z7f#&qLjgR8sAQ6Z8UZvhIz9>miSy) zI_6DhDxcmd-mV%bsgR`4!hghYz~^1V(0Bcy(?E_wPz6pgBQzeYcmOD@{9SithtgR+ zsJ|e^CWDS3?Y#^S-?Yaq3Mtz;dts6T94`Vr>_lYb=~1WN!6~Wg*^&T?*Qli}P
z2pq3F;akS=dqJo1HV^OOQE{337Xi+N(#J)Pv9e&9P!uQ&>%2@)BiMB~Z?R+5@kau` z`F-v%NIL6mM{gFwdE>a*X8IH)j!TFhni*_dmhr*Z7r61i2wQaVrH`2btiWM~L=}st zY0Y*T%!U6_Ki8&a>;Am+c4&ZQNA2O7kMsQ_6HnaZXX7b57}cTE`uHD2)c4FMAatcq zt!f7N#Bsc6o+6ir8$xX6N*h)2L^!L~PUc<7djZ*n74{m;7o-ZnKfxr}5qN~$gIe!n z&)j)c7P=Q_=8m>{7nxY%%MV$n$97jWYy6>N&!qdzg5M7_2!!8fIw0Dlwt6;Ab^Yo* zcpr=nuSUCxy~=%Z=Y1-6Xd)xFBgolX6`0d8C~ugM zkLflgq9(g#*8|0SfD1<*m#QhjinR#&wOkj?d#e2zmby{gU;E+HeAeAMtY8T|3vl~~ zQq5>rqm|KEQEE3~JF-dQi7OL?M!^K(Cj7%cysZ^dKJf7}!7(}dhLaUuKQ&%^EoG}! z7?zGF2%Nk8$RDB)r<4W>q_^voBE4+rer0N*vj-vOuR@ zl9_8aJE3S{^|%Ke)9W7ZNun8M%|=YF4irLz6qxNvidWE6j*>H09<$i_x$Y&f?yvf55|xh9ZNOqb~w z6D|rG2X7-b6%@|C?=f^tk7n~~wE$bIYfL0-l&6J-AG7xQc4p);ic3*_V z<5l%_@PSKb1t6qGMgG+k@nE650Y7q@Bd1r+n6iAkR`(@4p&RuE-&Y~b(P@I;9J$}m zrxWUu#F8}PU@XHpuvy>%*p?~v9A=ri#$i=smT`#2UyZ>sho3@G#Ev@8b&7(LRbWid ztjz;YnK5fA(4is)&z!;B&xsvc`h0dIJ|6ZB%k`ytbc41-rsn=c`(sVIhkP4(3j98~ z}?#GPy`7B)N+*_}qZx9l3W*M|G_^ zW!mqekJRY3(6QF<$NJ)MYLRgY=d77Y+t%%zW2QW@QQ(vC$r&-#;$znfst!qe?C7-z z8+-Qi%Xp-8J3en+8$Pdt_m2trJOk%V7e8+8>(2w)eR03PLznlaqd8Igu!a8VSR;;? zRYpzsJv!eO0$)<7cv>m?>D!osO5_}mRETIyR?*sGaFpVs0vmH6TzSx6w^s@^LsP*r zji=yow&FV)Lveuwz6I*@l%qh3ITrdhIr_7I2m=PV>}#%#YTnpZv+gy`FB>2b=-!eS z4xq}!6PYCfVEmUc&%#QqCx??XA}%~Vm1Y`nB(`%0sovwlwW3Zr>-U<}$Eyx{fV4G1 z^{Y(SE3ZHJDnlx9k10uc73GyZ|+53<1Ff4@GR@t?2%tMu@%f|&npv45%E%&Df_Rx&t8+X@FuVi=ZF?Kfxby zuVD+ojdku4qT;npNyp{hhRVXExGJC_Y{ZBZzVTXQfzkERMNk7s?M;Prk)Fzog|+r^ z1f&+mO5tJ#(KmXMh%$~BNkz}bmD`aMP|`Fpn%>I{E@AX)cI8IAxy_w-JaFIq-rm!R zFCLsAqv7o!;;=<-XDf|n>&wr4BNg}hOPlYxt*^J_AgsYg1jqU^w+dT4ZZR`{`(k`S z_bD5P8%@W9g9bSY8d_)Ec+3HsTv0Ox+|9+&Z)|4YAy=ZJX*vU$l0|`y0M5SC79J=2 zz6kK(stm_$tGanpKc8#0`*-9LOdmXXhy3uW8@sd{PJ^iL7-y5=Tv!{W=X2Y@2TdDf ztF!I`QMa9a_}V!3Id%k2GFS{73TJFIZcLIfRJF^B%%GElU^TaWsTbp;`$%x3eZhMd z;HYpx)0>+-oBW%?eN+dd8?rzus!4vtgtQco$KsgdQ8$))^Xs1*;GWzWZ*#P8lt;|n z_cwV{CfrvYV!z%H5V-sF9Ce`zfCbB9ZlAql(DS6&lyW9qa3x$la}E%g;hKS9j818^ zbSxDmy_U;_jmrr$p`IiQ^VN3nR$)SNf;$b(^#pxbUROp)KN|k5Uz^{UvS&QKhQ)-H zWoEVR8%pqEJ0{X8$Od0BEKrJVjG-^sV7J^aaP_`8TfI#=ZO1pY+L$PeDVsO70v)~w zZGZj|Vs^7)P2Q$f(7~E<;=KCq(%A8)!&HD~b9s%izGmV<5n8hNrM;xmOyIl*Sry-) zzHH}4A+H_YFxJ%PogZCS8;z2FfrTUehuDYNs?N00q)073e76MCOj{|iMB=Q$C-5?- ze~&{pmWB7Pmak8r)zb7DPAxi}CZq+*9wh|~F}|8S27&MmF3tjwFfI1^XhIGxC+4;l7U_`v=mn+4Jnp3LlPPT<)eDCwA!QwFP+Bb_aL z)fp3b+~79L=5s&0@MLM(PGJlLo?eai}HS>;4bS`Fe6++=(w&j2W#sf<7`(nU)<4nQTg?~Bw7v&~oH`+K62={pYAk!r8~wW3t7|r zE7kk>^3m_2bc-}lQvL1EAN^6MZjrt)uuB*JpSuneSbYA-!2UVvK;aUlE|RkUx$FGt zpOEzXBnB|*{6fTk9M1R`UB8LoC4T)mahB;XNc+!SC+UE7{zkSxC!VDL1$Mu&kZiB} z+*uq;u;ejNvNixiM~lPV;_F;lUmIOH?t=Hn1Sr6V;bVK9g8Ye1&ALC}=v(Uoi9^CH6tBnJYxPxV1DO&Bw~Nxbii&_4tqzev zY)J%gx<)_m`)c-F9KTar>h0)_)gdQ|+G+j(wF-kM9CaHT0vj8;hsXf=`a_G_54Rg0 zUY$XyII4B^be2P7+$*Gi1!M>;bc0frVo-9rP@j~{_Ruem4g)^CR6nSHhzkJ4dWgh_ z|9CnF*Z@RZTdwx8H*W#o>(|%QeG|1v#zE1Qk1wy$&|I9YfLMDX50)|$l5cWYb2psV zC+<9};kc(<32d&}lI8yP{<78Yz>$k67c&d##YNFt@ja+czJXGKW1UD{?=qFNqQ(7E z`%zh)+yglnZ+!{lULAceMLu!WomMJ{tDwNr!5a!PxA3uzf z@aBqE461ggkB*L3YLCDl4a#LmJ$3mW$#w1^ zT354Qt{sTXGWPxDI99q0IXzMX=~cP%ccHkSG#KX=Qt$opx&g0?-zaO{au;2_eVeQB z@f*d?Yt#$d+r1^CGjJAR?gX)26|AyvxzB%@K)OzgOS!j0@YXiz@FN7e9xBrCftWDZ}_ZS9Cwt3x=%qN|)doaN9k zcls`9!H3F9)?!$*LD(P?`NWtRmj94C8x>dgY_6?|9kuErkJF<>mP8-Er6$3sQF3{% i4UkI|mo3=mOnQUW*IClls|`4o2U3z#hvdte2L2at&_jO! literal 0 HcmV?d00001 diff --git a/zip-0316.rst b/zip-0316.rst index f8c1a4c5..413bed47 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -3,11 +3,556 @@ ZIP: 316 Title: Unified Addresses Owners: Daira Hopwood + Nathan Wilcox + Taylor Hornby Jack Grigg Sean Bowe Kris Nuttycombe Ying Tong Lai - Nathan Wilcox - Status: Reserved + Status: Proposed Category: Standards / RPC / Wallet + Created: 2021-04-07 + License: MIT Discussions-To: + + +Terminology +=========== + +The key words "MUST", "MUST NOT", and "SHOULD" in this document are to +be interpreted as described in RFC 2119. [#RFC2119]_ + +The terms below are to be interpreted as follows: + +Recipient + A wallet or other software that can receive transfers of assets (such + as ZEC) or in the future potentially other transaction-based state changes. +Sender + A wallet or other software that can send transfers of assets, or other + future consensus state side-effects. +Receiver + The necessary information to transfer an asset to a Recipient that generated + that Receiver using a specific Transfer Protocol. Each Receiver is associated + unambiguously with a specific Receiver Type. +Legacy Address (or LA) + A transparent, Sprout, or Sapling Address. +Unified Address (or UA) + A Unified Address combines multiple Receivers. +Address + Either a Legacy Address or a Unified Address. +Transfer Protocol + A specification of how a Sender can transfer assets to a Recipient. + For example, the Transfer Protocol for a Sapling Receiver is the subset + of the Zcash protocol required to successfully transfer ZEC using Sapling + Spend/Output Transfers as specified in the Zcash Protocol Specification. + (A single Zcash transaction can contain transfers of multiple + Transfer Protocols. For example a t→z transaction that shields to the + Sapling pool requires both Transparent and Sapling Transfer Protocols.) +Address Encoding + The externally visible encoding of an Address (e.g. as a string of + characters or a QR code). + + +Abstract +======== + +This proposal defines Unified Addresses, which bundle together Zcash addresses +(or other payment methods) of different types in a way that can be presented as +a single Address Encoding. It also defines Unified Viewing Keys, which perform +a similar function for Zcash viewing keys. + + +Motivation +========== + +Up to and including the Canopy network upgrade, Zcash supported the following +payment address types: + +* Transparent Addresses (P2PKH and P2SH) +* Sprout Addresses +* Sapling Addresses + +Each of these has its own Address Encodings, as a string and as a QR code. +(Since the QR code is derivable from the string encoding, for many purposes +it suffices to consider the string encoding.) + +The Orchard proposal [#zip-0224]_ adds a new address type, Orchard Addresses. + +The difficulty with defining new Address Encodings for each address type, is +that end-users are forced to be aware of the various types, and in particular +which types are supported by a given Sender or Recipient. In order to make +sure that transfers are completed successfully, users may be forced to +explicitly generate addresses of different types and re-distribute encodings +of them, which adds significant friction and cognitive overhead to +understanding and using Zcash. + +The goals for a Unified Address standard are as follows: + +- Simplify coordination between receivers and senders of Zcash wallets by + removing complexity from negotiating address types. +- Provide a “bridging mechanism” to allow shielded wallets to successfully + interact with conformant Transparent-Only wallets. +- Allow older conformant wallets to interact seamlessly with newer wallets. +- Enable users of newer wallets to upgrade to newer transaction technologies + and/or pools while maintaining seamless interactions with counterparties + using older wallets. +- Allow wallets to shoulder more sophisticated responsibilities for shielding + and/or migrating user funds. +- Allow wallets to potentially develop new transfer mechanisms without + underlying protocol changes. +- Provide forward compatibility that is standard for all wallets across a + range of potential future features. Some examples might include Layer 2 + features, cross-chain interoperability and bridging, and decentralized + exchange. +- The standard should work well for Zcash today and upcoming potential + upgrades, and also anticipate even broader use cases down the road such + as cross-chain functionality. + + +Requirements +============ + +Overview +-------- + +Unified Addresses specify multiple methods for payment to a Recipient's Wallet. +The Sender's Wallet can then non-interactively select the method of payment. + +Importantly, any wallet can support Unified Addresses, even when that wallet +only supports a subset of payment methods for receiving and/or sending. + +Despite having some similar characteristics, the Unified Address standard is +orthogonal to Payment Request URIs [#zip-0321]_ and similar schemes, and the +Unified Address format is likely to be incorporated into such schemes as a new +address type. + +Concepts +-------- + +Wallets follow a model *Interaction Flow* as follows: + +1. A Recipient *generates* an Address. +2. The Recipient wallet or human user encodes the address, and + *distributes* this Address Encoding through mechanisms which may be + “out-of-band” (example: they spray paint a QR Code on a sign) or + they may be more or less “in-band” (example: they include a string + encoding of a ``Reply-To`` address in an encrypted memo following a + common standard). +3. A Sender wallet or user *imports* the Address Encoding through any of + a variety of mechanisms (QR Code scanning, Payment URIs, cut-and-paste, + or “in-band” protocols like ``Reply-To`` memos). This includes decoding + and validity checks. +4. (Perhaps later in time) the Sender wallet executes a transfer of ZEC + (or other assets or future protocol state changes) to the Address. + +These steps are a funnel: encodings of the same Address may be distributed +zero or more times through different means. Zero or more Senders may import +addresses. Zero or more of those may execute a Transfer. A single Sender may +execute multiple Transfers over time from a single import. + +[TODO: examples] + +Addresses +--------- + +A Unified Address (or UA for short) combines one or more Receivers. + +When new Transport Protocols are introduced to the Zcash protocol after +Unified Addresses are standardized, those should introduce new Receiver Types +but *not* different address types outside of the UA standard. There needs +to be a compelling reason to deviate from the standard, since the benefits +of UA come precisely from their applicability across all new protocol +upgrades. + +Receivers +--------- + +Every Wallet must anticipate and properly parse a UA with any unknown +arbitrary Receiver Type. + +When Transferring to a valid UA, a Sender must behave as if any unknown +Receiver Type is simply not present for the purposes of the transfer. + +A Wallet may process unknown Receiver Types by indicating to the user +their presence or similar information for usability or diagnostic purposes. + +Transport Encoding +------------------ + +The string encoding is “opaque” to human readers: it does *not* allow +visual identification of which Receivers or Receiver Types are present. + +- Rationale: The general thinking behind UAs is to allow wallets to + streamline user experience (UX). If human users can parse a UA and + alter their behaviour based on that, then different users will end up + using the same wallet very differently; this complicates troubleshooting + and learning from other users or educational resources. Note that this + does not preclude a wallet from providing user-friendly displays or + indications about Receiver support, and the wallet's UX design can + decide when and how to do this and build a behavioural flow around that. + +The string encoding is resilient against typos, transcription errors, +cut-and-paste errors, unanticipated truncation, or other anticipated +UX hazards. + +There is a well-defined encoding of a Unified Address as a QR Code, +which produces QR codes that are reasonably compact and robust. + +There is a well-defined transformation between the QR Code and string +encodings in either direction. + +The string encoding fits into ZIP-321 Payment URIs [#zip-0321]_ and +general URIs without introducing parse ambiguities. + +The encoding must support sufficiently many Recipient Types to allow +for reasonable future expansion. + +The encoding must allow all wallets to safely and correctly parse out +unknown Receiver Types well enough to ignore them. + +Transfers +--------- + +When executing a Transfer the Sender selects a transfer method via a +Selection process. + +Given a valid UA, Selection must treat any unrecognized Receiver as +though it were absent. + +- This property is crucial for forward compatibility to ensure users + who upgrade to newer protocols / UAs don't lose the ability to smoothly + interact with older wallets. + +- This property is crucial for allowing Transparent-Only UA-Conformant + wallets to interact with newer shielded wallets, removing a + disincentive for adopting newer shielded wallets. + +- This property also allows Transparent-Only wallets to upgrade to + shielded support without re-acquiring counterparty UAs, or even when + they are re-acquired the user flow and usability will be minimally + disrupted. + +Open Issues and Known Concerns +------------------------------ + +FIXME: We have a few of these I [Nathan] will add in future edits. +This is especially true of privacy impacts of transparent or cross-pool +transactions and the associated UX issues. + + +Non-requirements +================ + +... + + +Specification +============= + +Definitions +----------- + + + +Encoding of Unified Payment Addresses +------------------------------------- + +Rather than defining a Bech32 string encoding of Orchard shielded +payment addresses, we instead define a unified payment address format +that is able to encode a set of payment addresses of different types. +This enables the consumer of an address to choose the best address +type it supports, providing a better user experience as new formats +are added in the future. + +Assume that we are given a set of one or more raw encodings of +payment addresses of distinct types. That is, the set may optionally +contain one of each of the payment address types in the following +list: + +* typecode :math:`\mathtt{0x03}` — an Orchard raw address as defined + in [#protocol-orchardpaymentaddrencoding]_; + +* typecode :math:`\mathtt{0x02}` — a Sapling raw address as defined + in [#protocol-saplingpaymentaddrencoding]_; + +* typecode :math:`\mathtt{0x01}` — a transparent P2SH address, *or* + typecode :math:`\mathtt{0x00}` — a transparent P2PKH address. + +A unified payment address MUST contain at least one shielded payment +address (typecodes :math:`\geq \mathtt{0x02}`). + +The intended semantics is that the consumer of a unified payment +address SHOULD take the “best” address type that it supports from +the set, i.e. the first in the above list. For example, if the +unified payment address includes an Orchard address, and the consumer +supports sending funds to Orchard addresses, and no more recent +address format has been defined at the time of use, then the Orchard +address SHOULD be used. + +The raw encoding of a unified payment address is a concatenation of +:math:`(\mathtt{typecode}, \mathtt{length}, \mathtt{addr})` encodings +of the consituent addresses: + +* :math:`\mathtt{typecode} : \mathtt{byte}` — the typecode from the + above list; + +* :math:`\mathtt{length} : \mathtt{byte}` — the length in bytes of + :math:`\mathtt{addr}`; + +* :math:`\mathtt{addr} : \mathtt{byte[length]}` — + the raw encoding of a shielded payment address, or the :math:`160`-bit + script hash of a P2SH address [#P2SH]_, or the :math:`160`-bit + validating key hash of a P2PKH address [#P2PKH]_. + +The result of the concatenation is then encoded with Bech32m +[#bip-0350]_, ignoring any length restrictions. This is chosen over +Bech32 in order to better handle variable-length inputs. + +For unified payment addresses on Mainnet, the Human-Readable Part (as +defined in [#bip-0350]_) is “``u``”. For unified payment addresses +on Testnet, the Human-Readable Part is “``utest``”. + +Notes: + +* The :math:`\mathtt{length}` field is always encoded as a single + byte, *not* as a :math:`\mathtt{compactSize}`. + +* For transparent addresses, the :math:`\mathtt{addr}` field does not + include the first two bytes of a raw encoding. + +* There is intentionally no typecode defined for a Sprout shielded + payment address. Since it is no longer possible (since activation + of ZIP 211 in the Canopy network upgrade [#zip-0211]_) to send + funds into the Sprout chain value pool, this would not be generally + useful. + +* Consumers MUST ignore constituent addresses with typecodes they do + not recognize. + +* Consumers MUST reject unified payment addresses in which the same + typecode appears more than once, or that include both P2SH and + P2PKH transparent addresses, or that contain only a transparent + address. + +* Producers SHOULD order the constituent addresses in the same order + as the list of address types above. However, consumers MUST NOT + assume this ordering, and it does not affect which address should + be used by a consumer. + +* There MUST NOT be additional bytes at the end of the encoding that + cannot be interpreted as specified above. + + +Address hardening +----------------- + +Security goal (**near second preimage resistance**): + +* An adversary is given :math:`q` Unified Addresses, generated honestly. +* The attack goal is to produce a “partially colliding” valid Unified + Address that: + + a) has a string encoding matching that of *one of* the input + addresses on some subset of characters (for concreteness, consider + the first :math:`n` and last :math:`m` characters, up to some bound + on :math:`n+m`); + b) is controlled by the adversary (for concreteness, the adversary + knows *at least one* of the private keys of the constituent + addresses). + +Security goal (**nonmalleability**): + +In this variant, part b) above is replaced by the meaning of the new +address being “usefully” different than the address it is based on, even +though the adversary does not know any of the private keys. For example, +if it were possible to delete a shielded constituent address from a UA +leaving only a transparent address, that would be a significant malleability +attack. + +Discussion +'''''''''' + +There is a generic brute force attack against near second preimage +resistance. The adversary generates UAs at random with known keys, until +one has an encoding that partially collides with one of the :math:`q` target +addresses. It may be possible to improve on this attack by making use of +properties of checksums, etc. + +The generic attack puts an upper bound on the achievable security: if it +takes work :math:`w` to produce and verify a UA, and the size of the character +set is :math:`c`, then the generic attack costs :math:`\sim \frac{w \cdot +c^{n+m}}{q}`. + +Proposed solution +''''''''''''''''' + +We use an unkeyed 4-round Feistel construction to approximate a random +permutation. (As explained below, 3 rounds would not be sufficient.) + +Let :math:`H_i` be a hash personalized by :math:`i`, with maximum output +length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with +extendable output length) based on :math:`H`, personalized by :math:`i`. + +Given input :math:`M` of length :math:`\ell_M` bytes such that +:math:`22 \leq \ell_M \leq 16448`, define :math:`\mathsf{F4Jumble}(M)` +by: + +* let :math:`\ell_L = \mathsf{min}(\ell_H, \mathsf{floor}(\ell_M/2))` +* let :math:`\ell_R = \ell_M - \ell_L` +* split :math:`M` into :math:`a` of length :math:`\ell_L` and :math:`b` of length :math:`\ell_R` +* let :math:`x = b \oplus G_0(a)` +* let :math:`y = a \oplus H_0(x)` +* let :math:`d = x \oplus G_1(y)` +* let :math:`c = y \oplus H_1(d)` +* return :math:`c \,||\, d`. + +The first argument to BLAKE2b below is the personalization. + +We instantiate :math:`H_i(u)` by +:math:`\mathsf{BLAKE2b‐}(8\ell_L)(“\mathtt{UA\_F4Jumble\_H\_}” \,||\,` +:math:`[i, 0], u)`. + +We instantiate :math:`G_i(u)` as the first :math:`\ell_R` bytes of the +concatenation of +:math:`[\mathsf{BLAKE2b‐}512(“\mathtt{UA\_F4Jumble\_G\_}” \,||\,` +:math:`[i, j], u) \text{ for } j \text{ from } 0 \text{ up to}` +:math:`\mathsf{ceiling}(\ell_R/\ell_H)-1]`. + +.. figure:: zip-0316-f4.png + :align: center + :figclass: align-center + + Diagram of 4-round unkeyed Feistel construction + +(In practice the lengths :math:`\ell_L` and :math:`\ell_R` will be roughly +the same until :math:`\ell_M` is larger than :math:`128` bytes.) + +Usage for Unified Addresses +''''''''''''''''''''''''''' + +The producer of a unified address applies :math:`\mathsf{F4Jumble}` to the +encoding of the sequence of (typecode, length, addr) before encoding it +with Bech32m. + +The consumer rejects any Bech32m-decoded byte sequence that is less than +22 bytes; otherwise it applies :math:`\mathsf{F4Jumble}^{-1}` before +parsing the result. (22 bytes is the minimum size of a valid encoded +address sequence, corresponding to just a transparent address.) + +Heuristic analysis +'''''''''''''''''' + +A 3-round unkeyed Feistel, as shown, is not sufficient: + +.. figure:: zip-0316-f3.png + :align: center + :figclass: align-center + + Diagram of 3-round unkeyed Feistel construction + +Suppose that an adversary has a target input/output pair +:math:`(a \,||\, b, c \,||\, d)`, and that the input to :math:`G_0` is +:math:`x`. By fixing :math:`x`, we can obtain another pair +:math:`((a \oplus t) \,||\, b', (c \oplus t) \,||\, d')` such that +:math:`a \oplus t` is close to :math:`a` and :math:`c \oplus t` is close +to :math:`c`. +(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d`, +but that isn't necessarily required for a valid attack.) + +A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and +:math:`y` as the intermediate values in the first diagram above: + +* if :math:`(x', y')` are fixed to the same values as :math:`(x, y)`, then + :math:`(a', b', c', d') = (a, b, c, d)`; + +* if :math:`x' = x` but :math:`y' \neq y`, then the adversary is able to + introduce a controlled :math:`\oplus`-difference + :math:`a \oplus a' = y \oplus y'`, but the other three pieces + :math:`(b, c, d)` are all randomized, which is sufficient; + +* if :math:`y' = y` but :math:`x' \neq x`, then the adversary is able to + introduce a controlled :math:`\oplus`-difference + :math:`d \oplus d' = x \oplus x'`, but the other three pieces + :math:`(a, b, c)` are all randomized, which is sufficient; + +* if :math:`x' \neq x` and :math:`y' \neq y`, all four pieces are + randomized. + +Note that the size of each piece is at least 11 bytes. TODO: analyze +whether this is sufficient when using 4 rounds. + +It would be possible to make an attack more expensive by making the work +done by an address producer more expensive. (This wouldn't necessarily +have to increase the work done by the consumer.) However, given that +addresses may need to be produced on constrained computing platforms, I +did not think that would be beneficial overall. + +Efficiency +'''''''''' + +The cost is dominated by 4 BLAKE2b compressions for :math:`\ell_M \leq 128` +bytes. A UA containing a transparent address, a Sapling address, and an +Orchard address, would have :math:`\ell_M = 112` bytes. The restriction +to a single address with a given typecode (and at most one transparent +address) means that this is also the maximum length as of NU5 activation. + +For longer UAs (when other typecodes are added), the cost increases to 6 +BLAKE2b compressions for :math:`128 < \ell_M \leq 192`, and 10 BLAKE2b +compressions for :math:`192 < \ell_M \leq 256`, for example. The maximum +cost for which the algorithm is defined would be 768 BLAKE2b compressions +at :math:`\ell_M = 16448` bytes. We will almost certainly never add enough +typecodes to reach that, and we might want to define a smaller limit. + +The memory usage, for a memory-optimized implementation, is roughly +:math:`\ell_M` bytes plus the size of a BLAKE2b hash state. + +Dependencies +'''''''''''' + +BLAKE2b, with personalization and variable output length, is the only +external dependency. TODO: would it be useful to remove the requirement +for variable output length? + +Related work +'''''''''''' + +[Eliminating Random Permutation Oracles in the Even–Mansour Cipher](https://www.iacr.org/cryptodb/data/paper.php?pubkey=218) + +* This paper argues that a 4-round unkeyed Feistel is sufficient to + replace a random permutation in the Even–Mansour cipher construction. + +[On the Round Security of Symmetric-Key Cryptographic Primitives](https://www.iacr.org/archive/crypto2000/18800377/18800377.pdf) + +LIONESS: https://www.cl.cam.ac.uk/~rja14/Papers/bear-lion.pdf + +* LIONESS is a similarly structured 4-round unbalanced Feistel cipher. + +Open questions +-------------- + + +Reference implementation +======================== + + +Acknowledgements +================ + +The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, +Marshall Gaucher, Jospeh Van Geffen, Brad Miller, Deirdre Connolly, and Teor for +discussions on the subject of Unified Addresses. + + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.1.22 or later [NU5 proposal] `_ +.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.22 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ +.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.22 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses `_ +.. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool `_ +.. [#zip-0224] `ZIP 224: Orchard Shielded Protocol `_ +.. [#zip-0321] `ZIP 321: Payment Request URIs `_ +.. [#bip-0350] `BIP 350: Bech32m format for v1+ witness addresses `_ +.. [#P2PKH] `Transactions: P2PKH Script Validation — Bitcoin Developer Guide `_ +.. [#P2SH] `Transactions: P2SH Scripts — Bitcoin Developer Guide `_