From b8e8f0af4f8c3451e3c05073d2e1034297313ddc Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Fri, 10 Jun 2016 19:45:17 -0700 Subject: [PATCH 01/12] initial segwit draft --- segwit.asciidoc | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 segwit.asciidoc diff --git a/segwit.asciidoc b/segwit.asciidoc new file mode 100644 index 00000000..1e5a28be --- /dev/null +++ b/segwit.asciidoc @@ -0,0 +1,33 @@ +//// + + +Will be merged later into chapter 6 or 7, as the book is reorganized + + +//// + +[[segwit]] +=== Segregated Witness + +Segregated Witness is an upgrade to the bitcoin consensus rules and network protocol, scheduled for implementation in the second half of 2016. + +In cryptography, the term "witness" is used to describe an input that satisfies a cryptographic condition. If the condition is a signature corresponding to public key, the witness is the signature. + +The unlocking script presented in each input in a bitcoin transaction is the witness that satisfies the condition imposed by the locking script on the UTXO. The term _segregated witness_ or _segwit_ for short, simply means separating the signature or unlocking script from the rest of the transaction. Think "separated signatures" in the simplest form. + +Segregated Witness therefore is a change to bitcoin that aims to move the signatures outside of the transaction data structure and into a _witness_ data structure that accompanies a transaction. Clients may request transaction data with or without the accompanying witness data. + +In this section we will look at some of the benefits of segregated witness, describe the mechanism used to deploy and implement this architecture change and demonstrate the use of segregated witness in transactions and addresses. + +==== Why Segregated Witness? + +Segregated witness is not really a feature. It is an architectural change that has several effects on the scalability, security, economic incentives and performance of bitcoin. + +Transaction malleability :: By moving the witness outside the transaction, the transaction hash used as an identifier no longer includes the witness data. Since the witness data is the only part of the transaction that can be modified by a third party (see <>), removing it also removes the opportunity for transaction malleability attacks. With segregated witness, transaction hashes become immutable, which greatly simplifies many applications using advanced bitcoin transaction construction, such as payment channels, chained transactions and lightning networks. + +Transaction size :: The witness data is often a big contributor to the total size of a transaction. In the case of multi-signature or other complex scripts, the majority of the data in the transaction is witness data. By moving the witness data outside the transaction, segregated witness improves bitcoin’s scalability. Nodes can prune the witness data after validating the signatures, or ignore it altogether when doing simplified payment verification. + +Economic Incentives :: Transaction fees are calculated based on the size of the transaction. But not all parts of the transaction are equally “expensive” to carry by the bitcoin network. UTXO data which must be kept until the UTXO are spent and are usually stored in memory for rapid validation of transactions are the minority of a transaction’s data. Witness data on the other hand, can be discarded entirely after a single validation, yet they make up the majority of a transaction’s data, especially for complex witness scripts. With segregated witness, the transaction fees are discounted on witness data and the influence of the size of UTXO in a transaction becomes greater, properly aligning incentives through fees with the actual economic costs to the network. + +Fraud Proofs :: Segregated witness will allow the construction of _fraud proofs_. When lightweight clients use simplified payment verification (SPV) to validate that a transaction has happened, they have to implicitly trust the miners, to a certain extent. They can validate the existence of a transaction but do not validate the full consensus rules. With the introduction of segregated witness, it becomes possible for nodes to construct and exchange cryptographic proofs that demonstrate the validity of transaction inputs. + From dd41311a85c8f27b402f0aa732e5ecde38cc6e79 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Mon, 1 Aug 2016 22:43:57 -0500 Subject: [PATCH 02/12] segwit diagram --- images/TransactionBeforeAndAfterSegwit.png | Bin 0 -> 38888 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 images/TransactionBeforeAndAfterSegwit.png diff --git a/images/TransactionBeforeAndAfterSegwit.png b/images/TransactionBeforeAndAfterSegwit.png new file mode 100644 index 0000000000000000000000000000000000000000..c3da4a1c4675e84afefce302954df01752c1a27c GIT binary patch literal 38888 zcmeFZXH-+&w?2wJfW8+o({JGW27P`6#nd zUA$r1XY$H;9ccW!8v=Af4_`T7jG}$pFk}^yo^<7Dp`wzDGatFIa7PsM^-bwZXO5oT zMYxn+YzVBZ7o5{7RQ`A&{~eXX8jn!o{@Zey)q9?Oh~qEbxt^xY*0tQFxu}&@q0NYz zg*3nZ(fFOwNl8N5t}GZB+yDRXe_eq`L7N)9XzR8Oqnh_-Os=k#{B+~>UV?PJ;&?K$ zFfJ-y?fP(VZWK^WXZZCpHJz|hxj$x-iceRhve)S{+KtT`oLLx@;FqE6SEJ)Hp3_AQwIpPso{$U zqZ2KdbOJoLvq&hMXVGW7t5hvobH*s73gMnO~hIssK%NczRZ+O9UBU>|+!!ts?_@acG z`7ku~em3@+1(Y}C>Arx7PHp!6cUye9U0xPkgUV^{20EE5UphwnGwI1X$oSKZtR_9` z_j^k_)KoV=mf}<#`&C@443l1{yINWd4LdjsH;=!Y7^b+iodM!j%M%&Sj5$sA!Af@T zwJuLx8gnvXa89DHN+WtrMZL;+UKl5MR@N&N;aA`q!5b}{ZQP%Ejf^XeM=c{Yp4Zj) ztqk5SZwn+fd)E`&pOSsVe^AFV){%Lh%=R&ihz>z(i}DFei%4`kdJD(jRtaac#!9m+ z>)f3`AJxUxbMq9~p34!Aj-qEvyEv4>s^PABL|$KNV$mabN`zy1g| zUVduZHJ|@UaCK_}i>y~%bs0*3B8JgazRmK*j*wZD?~imX2wsX(oip$l^Oh zICg0dcDjl15-1sXXMqxql=i!l;n^(K?U?uocIt!Gi--eL1)2LFLkLO_1TLxDx#3|o z8q|&oopyKc^_93qByftOM%fnXC_IxUxyB9Gxf16$AR8Ovp9}W zwXr8|eIp=a#>#pe^U04+7>7%5V(1>7$wAW5oO%WBXr9eu(tR*ngr?7I3EaN;WyGVl zapg32gcetJe&QCdNI-eqL_YCDqDV+vA z;wz7Imus?NP*()PA$WH;WwA6s%-H{PijKXzWr{bEXi6{TlzThA4~%ep z7^3D*UYxu%Oh_~!TBlrTsx_-2K7!rE+)-uMv!hts?W*%dvU__}19WLr)qMHhJ9k#! zEN@&7$hi7^wmyb>YP3(#u*rR)NgOxduh_RiH)u(^$?5G2RwNlMlBSPxu=VcRZR>GX zfg^GE=qeCGBp@8sw}CnZHi=!|g>p`>Gb7373fjGImT}%P4YoV#e>nOj4;G;!* zQcrt(1U&IKx!-0%_6j_IXCY`2@km8g>NA%}?*@9Y-T%Q-F@16NNZL9%!O7rUeXPHd zgF;ZTnCh(r1$+Hsevd?c^al0LD5Om?XUo}LcHdOL11WZnqtSTm^D>*jy%lQ6WH{M{Jyt)8CZd##Y+w7XK zXi7SYR^5T8#!pPb8?Sp!;GG?nq9+-T>)n_xHN7;8_`Y;_ytFMM`A!{sMx;)}k7(@f zqE%>XU*6cG=3wJ&(rVb0mX&nF*sil;SUaw|pO+)ES>lmo$V-c8bPA z)E`*OPi530(kHQJ;$MZE4BY9IR6oBXBEU6PZQUhR)A!spDo*&&3oTN%9`*j9Gk~3| z>^hcaZudi^=SriXYLNq~VL}9cv(IA37e*=3;=pk&IHQhd*DS>Dp2Bk{9_G`VW%bj)8SaEgcxjmmlo7-x&&e*U#Z2#$0&c8Jcsbw?%D5 z@C{1xodtIBR=+`|g?z`sQ3RV_24zpw)@NQTfPU%8v4nqKJ;*#xtF6x7Usm zx0?h-ETlAl5}ni@Ey?U}hH!jd*>vmJm-^nH+yu+Qcnfw*YO3MJ5<;)4CoB!h`nMH} zKe1sSF;T!r6`IgLg7Fo^{|X+Uctb!XTkwzCe2KZS$l5pQ9lP0qiI>b2OQU#)w@BU;zw631tP0rCMcSKHY=bT2 z{7Vd>67ek^9rF7N6yG*X)OV&DCH?Sj&u6b5e>teC={8!J<@e0IahhNR_F_s}_H)8} zxGb?RoN4R@{g~@=h}+#`bjgS_cU8{WWXM$NEKz1MHOd7cd^&%^mF>4SVzM5Z)buE&th)dDa zl5L6d)M#k4`jl(hTy@T2+=U$hP}L)c%}o@$eD@gD zvA=^2u$$`Mo#@#0&((ch)~QWO7Mz*Jyxy`=-ZH zMt}aQK%7^-bm`N~mJbC8quU3Kq3eCzPlyDpjhl*_JG9XG;z zaiicl#Pchx$fE+U-4R~zP=fYQYy2n9eEE?83+y!e%vWrG6sP!L`!l%_DaG#rUy61m zh3osEAPyr`uMNBU_n0ViPkjFW;DKz2Dx~87pwG@1&P0Qrvkx8TyYC=1Pl0*2{OdmLU#>*^wmNNEhwn%^%4z zcX2t>>ItrL!_9H^7(8b^{jMA8m7Y?|rb0uas{R>ZzZYL>Wk7a$4d}%kbPI zi~kx`xK{Jbp+`S_S2RQH6RwMBfF+7H-sc*-J{4Yp^$~D<^%6bTL{&$)SZh&Ns^R(| z*Xb7XT|q<%=US8d`&&q8pm+nuSF+3tCl>xSeeUv9`n6SdeI5({qp?)xI`>8RPU+f{ za*eYZwRIfbcQi+a*$125Z!;)A;EGYtqZr08QHCop+Na&@e`KfJF z*W8>O+LH6TU(v4t$+;t=(wI(l*4<`cogE!JU|$gXtl6WO|Lj(1;U1&evA2uVhdRYo z+f$m13b1}J#o8<2iB+~=x2@B(7M)j|juy&tk1y!c9Vf-L#28=vdg#UR*j0d+p0Y01 z`}R_5ytT_gE7W`T>5%7iG7rwhMOk@B2=#OP)Q_>$mK`haeFVuhk62g7^<&N;>jPf- zHLS8mM!D5v)hK3ZJ?FEDeVbaGh&qW{`Rta>>juqD!tX%p6oAon1P8w3q+><$r+1QK zbu2IU8skeuoD`i`fOX?B%_2Td)4wsYa=2@e45DoDev*=bLf3vN`!EB(!r5xw<;N@_ zKgux~&w@OIACw3*_aG;X;UX&s^{62s<`N4~I~M=Sv*3*D zK?NeNB2OQ^ua+GtO)zphTYUwbK|9y~xL&Gzb;`AW$0OR&`T*gyz*9?geJ6ebwMFkK zY;j;$Ei6=RNvOaO4!*dtal~-r3~4I#7m{SaHudfHKoGFQei+j4jb4uGK*hT@|nD;X`|~dmbiZY znSDr=dPo=bl*q&lx#3%~BOM~NUam&q!guMRNY^kyAEqH`j&JGV2LXPR8eJn>*7_V_ zygiq-0tgv}$LFH14=}9w%Loj5N4nGAK?dz4Z%h7Man%`Wm9OJnl9F4vqwbR^)*mA^ z>0=REpC?(-+N|kM+ei=gz(RH|p!;`no6A7pj4OL&_dm*lJ&q^N0Dv8h1Ud}cFqB_< za3r*i7{7AgRBY&S+yI54-GS={8CG2l0gXgzl|GdBbHyEGrwFvGY9l2%s9ZArrB+J{ zS7GJSLk0cHu8&$e3qmUeu6sEcVom*mh(z4r3|HqBOI6KDhVL`sBW3QdjuBmb$G77e zzv$)nb)72J^ji8^2|IXf-z#Cnc{a)Jci&3V zjO-mMiK?ZaS_53cBIQH7UlipWhP7uW{XEXK$e)T38B=fBWEjO5N|LoyBax=Av;Qy7^;yt7>L?jl@c*==VrqrWmm>Jr(I=!zmkmX|aAPW{VQejaPq zr(SU(o3C4OYG?86wuAHOD*Mj^&mbFa)Ap-e(dJ)Lf7&|eWXx=@80fbFp(4}1Q9Vet zzfwrQ!q5k^Y@$Dlc1NTvz^(1Ny zidQ3hprvY(hBxUuH*{r0J6P4C7??&TRjgBkDL}U2)y6tU;R6hq6$aDl-I0F^qK{)9 z>KaVgGyNRVk=@5%IkJE%AoMd^I8>)iFOhXKBXNV9ACavc|LhhQhHfq%0wqzEakSYg^y@T|M6FOZvKq^kj z!S~8axI^T@E(jsKE43hw=3N~b!g;VQ;k+AvMG!&94rC!~WGpXl6QB9_b=`Dzy)V+s zlc3v|E24q$^vN!Gdp!!N|um0l3KdW)O6nyLT zU5>4BFzW)vr!xlayG|)h*V74QJ8UktDVM2y2?8I-ad&+Mjp3M4dApRmjm@2{lJAVL z=|x}iwnkKHaA_7;TxbP(l|)qjmMT7sqnGRzC|GvSHpOru*SipiGCjqxYGDUlCH&2Y z?gHa*-pEUf8<*5f!UmmjY3ot>_1zn|e7DBA34gJs&ii**)iKU|YmCQ3k0u^6I=kT5 zIH<4|=`>y?J?Whd7;k$rGE4AOZJ_#*SdNqLn}G9M*Z3+AvPDs&E6?8_Z>Ps%stU`I z;$q{DuFqQO(un8+f_U0`(oO;4&J)h1%2K;PJFW;NCL)|IP@$wH=-WGX!ox0oGB*Q2shC>ydn0O1hFtCQ5UY?!j zUA^yiHfr^$wjsYW*{6HqYiXw~IDhmi(fmxf2$s};X0IHgF6&o%p@_3Tl0sJlmritu z*x+vNy{0IMTc@KoD}D((z$N735`@W#(t(|r?p6je7V%f0%Jc|eluzKzVv zZ5CG@L9e<4Dwi3KmxXzs#VC;if6iKky{TFANRj%WVHMBWI;>*4VC=Co)3dB0TZdI_ zl7!<8tg-wd_sA|jhRN(#F~@)DQJaYSy7N55i9p7}kQW5&D=Z%#p#W2Pp9?Nvuz?d9 z$!ELjV4a!lNFL3piYfNvp6%dD`(j(CK?aSad$JC}X@{4LFsrL5)>n{WK;xxs`~6KEikZ zQq|I4Z2tr&A+`Fc?1;+-&9z;rG)XF;VMGxql|hX{o98?$QmO4m_94yV2u2P?%&>E0 zpsc^ZxQ>b%!uP&KYf;g+yH8>G=P?PN^w51jB0y(8-3zTqPisOva<~J584e!KsVfSK zE!nA7ykuPZ?AM0vKRE5Z@tVKm5wL#q3mKn;X9nHnNi&3k;aq`Y!w%_Mw44waZs56h zhw?XSBR`0>gexKEh$9`9hYA~s(;#%0x6^D>_Id5>A+B7WN?sI}mslUJvrQIWWOpNN z)*Yna7nwwaQT^idExD1FUd$}if_7d$?e*(`f%UDz@*rq(^*7ASn5$Sq0am{;C|&*m zzYJ^~%GmXFll$`Tk+AtNmvV{6+|J0*zStkni8MD!QHUQgRhf})uy<(aWw1^y7$9b- z$oPFpZ0ej>liMuR#ZCOU@|#+okNg2)$c^FH*2%+u ze9@~o=ctq!uXz-DyInk*OhfG3jazij=X%ynczs!V6}#(2^>-Z#$S!xA?gWnA#O4=_ z;bsSEHIMJy)%7CON+XvzkFymVBx~0bt z_F_Eszj<`7h~1XmW_jGwQXly2{e$~vNZ3DBPu(|_Tep;tg^qD&HSezn#KhaCnG#W^ z%?xKA$*tM7?%3&mRYLU+ebm~QzfgGDg-M0)UHoM;z#zcq|NXdZ28h5XAOEj^`2+^o ztSmiXE{{k*0na5#*7PSIz%Tz?$)b?mixOK2k=pxAMJh2ARS z-D-^long873iyZs(S+P%xd@y<(g%ymEo8_&K*T3~gxm`Ru_Es+vwYj9m#ytM+}{KP z(;+_%OfShu`JLVWvv0S)){-7}HW27ccu<#@ z$1dsiOQXFhLoHMCW~Nj?#+dXiVRCwK+_CI9+GGOsJTsDA#mtjpJmC*K}Lx z`ua>~7Y}etEjQA!d0QtoY0_`k*yNDZ$SE>pEk(dCcIGjRT$bL}0LCMttMowJcgMcT zZE;|)EtH0h^)&cx3fQcc)6L!eQc^giM%ZiZ+0!;)rod3AxM<8``2#^Rr6Fs*LX&BC zbti5JIT%%$IO9qY^Py#P?Z%BB?D&iD@fw>!YHv9HAw0p(H{ckP=<|NN(H}!kQOeqS z`QOz9(k|I7;(&F{E}%;d?$m#W{Jm-0@Tx(QnUIyZ3 zYQ%n&lkP#O>4br_+-{Njq712UK-AW<$DfBVycgeYOi+F~PMC1|a%r6hF*ZP;%`BqF zs7)^i7}HT3@*rmK?$-*PkIcccu>ospd(~`CJ-{%uG&NDxK*sO0ZBEhyOA3;Oy#gg_ z!DtVP`Vtmr1-A3`k?yP9Htq}AHEd;J&UaW;Ty9@BD--~GY?|sY)?l-o@rDm&lSn4R zn*%DQUUsyTusre`j}x$;zp!1^o6LU!3^X8}iq}Trpf4lTQyMOC=s1>o;(J|IIqtF< z$zr|MSQu<0ov_>`)+2ON;dFer>r;%BPsXATtIi+)K~#+e|Gx7V%W|er)($_lktMUI@z@_zk{tswt8-ItgeI7P(vwK zCA5Gz>cI>~>w5dY<^ajkcNBpVH>G79&Ixl5(JlAQ%bZy57dE7*rVQj9PREv5N8?`?6;c4z@2VE!y=V1B=)#2qSqYX_w|xADm21FSZ(UeTaKr=N~si>6F@1 zKBR5XcU=!9bc2z#P8C}BwQclw507|JeCK51PBn1;y*B52Nu~q9=kFcm<`W4n>NMEB}S3Sp^ zFZ_Wv0Ao*(6+pRHpj{UN9-$?|R`lR1uTjVeAd)O+bnNA3Z&OHUQN&d2HDK;f{($WN zZDwX9%lHesCyVrVCO{*SH~4on6Jhj}j=H+K4~_torgSK<81fL6jAdj| z(UB${O~9m|$a?jr2sp3Y3!~^VujFI6;faMq20o4N5nN^LL+KCD`f2p zl~kJ0N=M|488{sNeEgEo*gNfzp7rT*grn($`E0rH2MF)oanG4h8jcRcm`hIuJJ|2l zS|%j`S(qzkb7FJIKxu6JMoNV%GmrfT%ShZU$K zOP9%#Ag~-%JnTU{*be=EKtvv3OnV?^j3prM`ESWu+NrOp(>rc(hGHc%z2}p^5hHI1 z@k;s~xV0Wl6INTL9H7uhIzE%MvB^~d^oVFwi3LA7n&^JfmI#vYBpno1B!^m>!bU=n zBn%tu>{$=z4hAWM#+_-q9nsW+P)tqL9NU~qKKFo%_uJ`~Bxg0ArL8R?#vr z;M0}P<2w^6M4jBUjW+bz<1+LmyTR|o zA;BzcZ*Q-+DPq6>O@O`599p=c)Hd|!c3#V8aL7Gv$LNZ=rYwJp_w2}^i3^NgKLelN zXw5UP$l5(k_-^`37|05xw?zQE@Cu}BZwG@ww?j?3R8E)doY|E{d=9JNqSb%B`1SxB zhBrj7D|r!%%8Rfuo)6L)vJEb`R z_T38}u{9X}WxsC;znue(89QUK14h@(pPH!zWOzIR&=IAkH6&$MQjt|-4`gvWlQnMs z-Lqnr5_cV1l94=u1vj$T@3(Cv&T8!I*DIVBc^_7RRMX}iva<57PuhLon<~VCwarf} z>6~6s4gyJBZ7xvocb5{&_uib}_RTolr8<_7k)!nGt-=hG4)qjs=G}r>>O2l3SkYNv zXCOX3JV>7zjoA3F4YVM9XZh8_2eATgU`6x|(dp30lQpG6fN*aR>08B06@GDZ3uT|f zobE%dy0hAMcyL}2z(tp)s}yv8Fn`l%gffLV5i51ejFLV5`3v~T1ZF*=HfE0 z;QK?VFXOC6wt7!%cP>GyWa1~KqsOKEPw>Z!%?GwUWw@`zzx1mB!_xhO)u?;_Y91_d zvAYze(=)b+D!G;QlEEiBG;Ngq1iq%isLi&&b1@hD6saE{jkN-^At;rMxf(6)sZ>By zGQX3%`Sd*uc6o78EVQpBYOA%O`g`gXAlL;=wJ&aN`NkdEThgV5K(o1f(1qQJf7q8( zB@iF7nhKk68NOyNY13 zYBg3uOmno=1@jCb-Gfd>W5@|QZ5tg+y;i~`1LjC(5OF870eVZH#eQ;!`DD(lE{`wa zG+p_;rg#x-5CvGyXrTJaUjoIQEw15N>9;StLQ=kY~ClZaebfnU+k|k93R4-%IPt6Z(ka9s>vR8#z{Qp zx!IkQ#r+n;z5<-Fz)vmSHF2j)Bc=C6*v3{i&3HU!l}Oh6n8T`flwQeRANO9nwr_qG zLi-3Ye)Wvud~gT%_Jhp4Z>-C2qso&Ai(cCGI<&f|h!XDc#q~R2J27^LX3f!=i_ikj z?IaQl(1ockjZqQNNcKBGdWSuQOIlBX9-8u%bLRQN_x9k2Et3?28UVDc2Qg;${wT9} z$}C&2TV=O-1N*Ygpv(e&E^Lb@n}Qm7q~g^XMzX$M7DWeD6uZ|+|6XcgeUzeCAJ{oGSbv2rJC#zjtV z!*23uG4+Yd?LQF&0D>PtG=5O(gL&2XRq0JyoS~2(Yax`fs}>%ouz88$?|pw+7C_`k zkobpl{qNsMMtTyQoRF-)4Dh7wUvhYI1Mt9;6QptyfB`p(lMP^@{&~y_s({RM&s|^WLY= z&Ff;v8y>AAJ6}qH``!(E9u4b~!u%5gT302zcgW{|^$PuKPV2+vfFu6D@z#GI=5G@F zFNIVHuSnYU7vwlrcfVzEzQYSgB}n%^>CA=Q4#e?J=XC9)(M_Y)<VgR##d3QB&rR=yf^Z4OWmwG_Ny$2^Kd_wM>fXaYlVts3PXXFjK{0vPkZ#s_zGX!U3wDXeXNmD%$HR?8GN6zj@ zxUVh_s~;XJ_p`@ZyvFVy^bm`>430WY4bZ-Zw9*Iz1>f_uCksLnC8ok?&1xkS^o&Dm z;UGx3sSnh%YQiz|JCrB!p0(n@BbE|4Ik{U_+<~@t0*qTbuMe}*N*v63ULsve-*C(w zyh9~?^>H*1Bm<(f%%zaEj6UPg3dzITc<&w*dQB|TUeQ1E<(JusNgm1VWcAzG_R@>+ zCnLJ^4uufurzMk!Rc}$7&Iw)-11Y!8*6qe#Z-Q;oM&KS6 z%h(fV11YOz^2}VaLyN*l;l18NAt8?A#Iu^vN~bAl(qu~BJ!{D3wu!%6c63lQyK~sz z-xD|S-OmWDW2rO!5$ieLcnkat;-?C8pX}#t;s;Oj^xG@tV$Y6tR1^A%W7e@t8>a3} z?-+s;B=+Lxya_0;>xQTasMJ_WM1cp@I9f1Ta>u$E%0L|u6gd|_2E^)x#^Cwa*U!=o z0r4}1Y~7GI414r*uq)KjgJ5Xb5;II!vQ)%fgl1ZXEAMgi1R1cZz}P=$6>T;5tSr(x zhc0tS5`8~gphWEgL6HSBgMN4~_T^a1);VbizU12de`9^H8T}g;qa|_VrXhHUlq>q7Q$sZ4 z@UEvsSJ0E+T%2V1fW%NY;tk_rtD%;wy*yI$!q&zKp{ZVO@XuBwhSo@v7Xl;FY?f5n zvDibwK}er4)PpQWE5oCf-B!Mjmm3N1zV;vd3f??;gVHVO7Lq`IyMF3ljcUj#xYOD$(CWv91HS5n>IQhgF-h&o6ntp_C|?+@Hwb8>zJTix=V^a(V-I?r2lC$*=Ay%*W5NCF)!Q zoFB?xqX>lUa-oK_xtd#@sQu#{&7M#?RqOTb*2 zWb=6;Ym0*gGc%phovSSb-fTG%iHvp!CtNg8evE!^o)Y>P$6lDlJyg$PAIn9Kdf8m` z=_)spLN&&UFi=7(>a13JLsK*_1zLc9%PA3~jtAQ=R(J=gBJs15H*-1$?5VGtR;m6D z)Sk(D0f?+T3QwPwYo3m`CT22&=0cJt;04)un~$W`Ls5<)NI& zOX7}kh;$4?jq!^xX}ldk<+@f6L_AlP#&>$Eu7*n|QMj9NWS_mS|s)$#3I5;>wAwB&U_z5~>DuOopP;vE~(s@_SOS1Guny}jCzzd8DMa>5J zIzc4rM{Wu$P)$wnbV)7hjNupZJPD*p-U0B%tPHK0YL*2Wb3GG#z{r5wQcH9I&s{(R z9NhtwOz(ju#Jv|>aDZ`c>A3wCvjB~N>*2%6YCpV~@6K{;0aO~6bzM%c{9FJQDD$3I zEK)4?2_-_=Kl>On1MdAq0@n7j-|KN?YmUy-c>{Da&o~umR1ct$$=?D&c8532J?o;expywx65z_aP!s3HdQ<1G{?kid z(j$jka%mt7o}hR0wlq%BPqf@wxQRZJp#xpxWb|9^k5v{XB)e08}aog}0 zP^hW{lbFXc1|`YlUpG0IUd!-XCF*$??X-a7<49!q$N0#rPMR>_Tz0thhJ8|3w_p%8 zbvT1UEk2x|y>Xjkqqs*fV2M9-8E+Z?sX?MF#?xlOT;_BM_sFIB5rCEh()2j`y$#y1 zoM!G}WJ&_|JwS%IJ#CDzYE|~wdcwe5e62lD;qb;5!b0L9MNeQC_@gU$%MU}U6DYo05vrmN(ys znUwaimQaF7C!0zQhB}``7z6axt|~~e&fK^zBF8NSY3NX&=cyBlb!g;qH1)apWbrO9 z+Tbw|g?(o=dhQPC+9Wh)T&8}R zJfktIm9!sk5Qwqul}Hm{+6_E&Ay(w=YU66lb6?2ITBZO~jG6@?i12>A$NK8zsDiW5 zWVP4!Tn-{tqi^?=c7M=VEuBo{uGHp!4b8b44mieY1eYC>?FU+vShiF>dEKm(Vri84 z>n2mz4fQIU&Vm{DXvKIFo5j22UAqfxvbyDd-R zTGP(FX=ib33s=n3t_tWb9vZz3XH~F=v=e9ec$5>y-B(|WgLSsG2R=%gbh##ga9(Uk zOnC=CIf_{F)SjS6=tU{YVT*>Bu&51vCZdx|({PguK$%a=5PkK4hf**3AVeU&;AIZg;yp_Oa*w8&my^VTupeu4%_? zb7vRrDZOAX5KJ)r*h_5&NhGebVU}X5cOo?GV6`R+6XRiJp)HdSfSNi9x+CYJ(?FGs zDQx@H;~pRmJOx&hp*7#;#B5HYP{0clBfnqcbpJ_(E?P~E zQt<)NW?259Lqo99xA}aJMx?V;IKZmmt-uReq!@b_c_t(Mz>HFj+mbQpOM` z(;6Tz(64N4Z0xc@qAE^D4{c(fS$Up_mh#?=W;ES+-;5Q6TD++pxrR#WdR8ury#(@h z)yn(lL25-Cc>>BX_6mKi(vRa=^xz$tQbyav3V854km0Jcf(QOS4E=GsBus#1jEmm?Uog5NeVKi9n_x}ks#Fuzir2&9 z*hFyAmwE?2_~F|4(?@iQK*9N})$nsSSlN&bTp0%;GPa#RZt+48q*&5R2BtRay_IE&@qE!|5ohCD(gMOs7SSsgj>D<(tafM+E>5Qh zvm6#@qV*myR!nR$y4!DziqfKY1Wci-`fM zNfnl4s-cD5z?*0VA#wJ_Pffz9NrDfFuCiRTFoBhF=t0ld-bL~?!^MQ7D-FoD9)Ff% zR*SdqsuZ(+z#{Hs4`j?T?pr*0IjAbc{4cj%`_;?33@2Audb0WSa}E!3W%=^K#~F=q zSW$~@fKvfP%kFJLqzA2EN$A=@p0Y0%vV_C^RolI`=D{8^TG@(Z^2L)7zm{0_04_w# zMG24e+yWgC1FIf<^k!0NIO`5#doOFq2|#oG-O3^;jDi9g)>IlF9Kwk#=2Gt5h|j%AAGJDhIa z4No+g5Xv78*zM|!+xDES4%yCWIx;;PKITjX*^Oo%c4fAyOA#Obc?RI+S_GsYqzROw zfV6E~xI+YLJNTcQO6XNgZTL2Ao&P@&I6O2j(?*$U@Ua05mDkyLfrTM=z=pAXY_ z2qPpJh08IDH#3gcCKv&E=y|~+St_<3naG3$;0-~*a!AWF)ye2vvdca7_U+qK3)g}8 zY)XlGiiSh2?dHv!>xPcaD97|!2(G000|00Y!cMnFt@_eL&PA^SSsc|J6bc1#Y6KFQ z9JIf#@mrl8&Xn{Mwdn=nR{{PMs!(p)D*5rcUFOPx=Y%(h$lGe`{`1kj8LT&FfaFq& zcv;Cp)Jc9XB;~SMt<1L+0d7+6X~uP-PZRw1K07kDl@vT@2s@jzw8IaRtuqu?s(}Rm zV_g_eJ`hf82l=hL$)K?2ganjN78K&#S42r8c^w_@Cr>ZwxP;>k zb>wtrB-TEi`OIh@+RQz^I~fpAK4e&{TU89dH#l4mhmOYkk>xhtClX5drWY)G?*^#q)xFh2bhaD2a1*( zxpkty{Z_kVXaO8dMrm8-i>WMHfaB6kpVS!;jWpW2>?%)0i`y zj{dhHP}UF`R?(PlKq-3zFF@>KF$!g|$5Yy}e^+!Zf*(i=(}U6CSd0~rB(zNAz^y|} ztGT}1ZeI~Z3zabb`tD|HP!P92wxHM_*qEMi;kR9qDamRTFS6Wd*kAy{9Ni)yg+7!{ z`#9c=yiBaXp^~LU@SO2KqgHlno!7d>kw^a8HVJjgug5=59451A$9ohg4f?rD>AqAg z8FwDT8-d};_b61!KQ8Ybm&w|EiJ9pxkP{=)Wyo`4HRcQBhTY5_F%$& z=3zqyNkcER8#!ga_lAvYVh(!! zm#2hO83-Hd?Xv;^HR)`TiMu&R9vmD@2rU+5`dY zuj%83l(d+c9=KttYMFmgf6cnzb3eL*?|b{0`V4Me!Ir&|+Pw7~55Yu|~}fw=O>bmhq2t zd{HBgr0bq|(7!c7C#Z6Uv_Ss~t^Zpc5sD3|<+^_P8pR*?^!EN;B#<4K|D7kNyn2_O z7o0$58dYX&pA&yK=+861(9;4{H;-L-^jfQIy>Hoo-;cBVU8r=+R+FSZ4^y9z+mpcqm;P2By&~QCfBg10&0k~yqnphR zTn_p#w-1GZgyziy-0;#je7j6S?$syU8fGCy4YH*nPIg0{?IP_)59nD`%Gm!@KxuN9 zg8TES4`q38$9%qQ=EC#1Ob(W%B)dn-p93XL(?GU6kxnWQ6dZHtGHOY}TvAKzR1lv@ zlkk4`?%w(g?fNu8-!|EVSN#A9ely0c`!(aRqr0L4FHj5 z$9Lb}a8Q6J3qlQC0GBn|ABYCzdk z$w-5{-Rgt%CPC-vHm~mYcZe(8HW0{20`9pGk8XP%DT(_UP%%rcu^V*R0tf??mC3P` zP?Wdgfe<3j{m8Geq2ZwS@Sek1ofqJkLhfnyvXq3|rS-I1)?ZD&bW%uHBnvYZ*+#fK zDtpPyO!(kRn^6`(pdbw{>yc9jwzOXD!HwTKeG;g+KJuVFJm=JNq4z1_5Rl4pfeChJiP<=elzL4kUk49YJ;cmSYv}^_k!q56jp){ z0XgQ+83lYpioBk5vA@~&Iqt)7+h4D5V9@aJf%>=XK(P++e#WqvU+O&Pi7NHGa&XEF zJk{6Nm+Lv4enAhxo~w^NU@6fF!DA5|C?jJh*5cS=8}txk7T*3Paceh^_=3Tc(c+}w z=46<>#ULtnY1H%Izd0#Id|e0yXWTSSb)+xShMD?pqxSX}GMU`cMBTZBSEjxMUrTi6 zHaCL4`4a#+-5FXiS9XI&P1QbcTDmed-sriT(SL7bZ$+!Wo$hGzc${y=#D!_*frDH` z@up8V&lliaM1t(zf)v+)YLl3Ur@<>0^_x$!D^tJvpg54G#|Oi4t?L|^m5Afno&dqZ zk@0<>vCU(n6*|KVti-STK>s}gE6dTxY8z5z-6sW*05-H|dxWrRPUa;R#BLYq!j8>1 z2OoFc3aMm_{WrmL;mbFpyUbWXEBiP7RsDqQ55@Q&c{IS&MLY)k1M%rhs_Sv|r2m1u z0?ogzPKqt2>3|m;W9OzI z==#TT5*%uD?ypnTLeb=>kXhqKx-~U`XD^7I4)0Wjp?#ynk z@0uMVFNw09Dk0l@vJsTkaLC3R87Lb!+f~ zkA?yczWDFzy6fRuw#OF$G$C=rlRB`eDX`i0kAqT>epcLKO{tGp4?B|i6oP;i{as!8 z`=+Y!3N@?h7L57)FBE)f4hV46SH`0Mm3>L}t1-$_@;!*RrrFAblkMBmLi3TX)OWF* zH=z~iAg)f}-B<+!A{t~o0%#*C&Lpn+m!ElkXKBL4XR>h=D7rvx9}2k*U`mc?*%)GiB29>&ZH*Opo(e1C7>0M`c0K}-kP;3yF5~Z^3bA&9Kg@<$%&~hk*d1sd|xfXAa zCNG{yIW!2;wBfl@1}Y!l8=t_3iJW@(x1f)=4O6%p=DGm<$&RcyTvyDF zT{^?edArT9*rwJX3n z2Bf3(A|Q&?kWdW0jFBQBMIiJd0#ZVeUITXro%z1+-aq#rH90wFpS{+4*R$S(Bn}j> zVJvE28k3u-I+wO+Mw{+8 z=yXul9S)c|Cn_Yd|HI(^^{qncXdNJJ*H9ER-+?%8GnAvja_eyJKLix4IqniA zUS2us#D}b}4NO2;zJcTB1DWwK3RDpCMgYod3_RGj&WdvdsTR4M%?>Ncy?RNdspCZq zXPnf~?ngDOAm4P%VpW>xS-^P5*O{|01x(oVJvE%~l`lWF)es?6de8tO=<0BxEHDjz+#;QM(D_kHP z{_N9&*KWFOI3GJ5mctLt8h5+myJ^RtU5}_;**kp_0S^|7u&j9PQQ9eubTJqa=3SxA zS*yYU*!KZTlbe7pLxi5K=n+gaztUeB008-%W8-2v6C!)f$~tKJa6CB?BEad0s|cUb zz*OH~&5=3w{TZv#Sk#Ml^*GokVzrJqM)-vyA#z(`C2cN-ICNefX8{A1SpSdaswl~k z>6MB4+9fO_Acn0GsI85{i|C{?6eS~6V>ILEx$%W(Z7Fi$rMwl+Cav64TSX0pPD&GP z9)9YE^`4`5AF`Z^fP($&>Xa3T1?6R+{sC=nC^RX+)KhQy%@eO5F!(%>?)W7IAHzkbt@bqU-|(nqT>p4otKKPLC81~H231}KW`$l^9S=c$bjZG z7yb{~Rq2!xAQQqyzUWOZ*zJy$rODdeYut{Mtvj%6u^H20F*^5Vikus?fJ5$l^w5v# zpeO3mFV1Zei*wG8V=6qn?zePACcJ*$`H9*%kNcbal8(ZP^JqT}LD3X)V)E0G#M`~h zyqOZ!Q8jzR$X!e6lYkkhSAb?okmG)(zopOFzJRKB3oF@TF(cs2v#Y~JF)BC7W%e@&0>X2m;>vROq~c?uVa&L|LS_8?=7WEbl_g@7|Ke;X ziI27oD>{C-pE|p+fMP22GNWH})eWd2cgRf7LpofKO$;oFVU!Cqo1%2D-z)o)m$D(r z_wQmQlU6~H@=w@zeHcGOCDpSk=x`H>c#NIp#oi-GJ0)PjmkWl3+H#z*f^tSc$6Meq)7U2uWO&a>cUi{;0ha(ri)iq^)wI5lTJ$ z{p$a(EU@2Ns&>x#J3rPk+59O;{>g~gl zDA3gBB*gvS>-`NGjDU2vHxu+xp7cK!tc`v%-mf@LLota1VbRq?uOd~f4S)Zbyj}mW zzJJ3IdYv=q2n+dNIVX4reKkj4C+~nkX?PeFi_E|JIJwOKDD`ic`(IN*Cj~RO9{=-) zC)Zyd6;J{C0i5h z=cPQ|;Jf%(sEf!s$-6H|8kdE0-Aj7d$W}uBoS?}2`v0cLW+R7Ljx%O_&U4qpN&E00 zyy?9@C(9`zp3Ro9}EE@J!@YpIOT4~iE2>{ zm2XBpjSdSH2w@<1+U|jD=~dYDqZR+YetXgif|cjC+w>7X$v%LnBm=_b5wTIH?5`v_ zlm*4Ww4ymV{Q@T<0^IzY5GpSAdJ|v^mo@1?if!9>mL3OBKVHh3EYTMO)9iKvvSlr+{bsQs9Bc~Zrc>O)4;R|_m@c_lzPygS&{ zSLjD}@I4mUYWLuY(!+1>2dPyEGUP1ud&mx7WU|a|;_izJSAM9xUlCp)4Yrc29c6MF zy!KY!c+|9cXq(QDPb5$jJKYs_ZUrPu#k|N&K_E~@SphcW?7STji6FlC{FyGYQ5;a!_ME9TCqni7?v*# z9xq;qTW0sDh#nvC8Yt(^-tYWgbZFyVgiN+p|BY8pM4{j=> z2AvL_%7U7WSeD1(cK$R^{WH~3208;lux}T656I~x>(*_k7i?Dzeh~R(y7vWSr@CTJ zn}y4faqAi)mANr^J!2(r4m|*>2)#+)_3B+PHTb)$VMOb#6v!!K(ba4%@8hFjtXmLd z>YaPmfXnlE>v*Jd#^YZ|NY%%r0AyKPr8cx)dR9>Kk(RLDQL zKQsX8yqVqlZp#n}G})~i`l(x$dayCNsd@|NZPgN)Th`Lug{q?$C}|v|pBluD&zTb3 zjlPeomL8Z7`W-IO9gCT#J%h;2hW`YK;xwBywpH48g3L))?JtC3ES^<|NBsO5Sz_Qb zzKG2+#@oa>z!hqrIrQ$;x(78HG2lA+kK3ERh@FO`V1Yrz5O#fouaD)8r>k6*Iyn7` zzPir=P~-^EfIAJ>8O*v910R*NTGKv}dO%VeR{$wQPnc`s5sNgbN{fbk5aN*8Lr*5+ZUnf>+zv} z82(6*bt#lxuLFh#^Iok0F_RN2x>#&xQ_*TocoJyW^Ws!^RbkT+X)9&(CITKbFNokd z5O}+N6~SFfb#sJ@^V@B__B+-(*Xfqs+;qn2V%Z^c?Z;PcjxkOijj}`z2Dy8>kjgGJ zrl8?lbMPw|XZTTwbv;-2c5UquOYl+OE~hL>5dZlEkNE(RJ=&dKixv+o$v2^4hZpXe z#$wtsMy{d#?k>d7Toy@MVNB!TEmEpVx&PvVFapK$9@r^Tzo{)QE}!<$vMk>|XW&kX zw3DabV6L^|oLF9!Ng9+y`zBZjg82SM>E4at;FZ4^mYk>Ug=ORo(#Y-Ge4k&z0oD<6R=w9o8te5qNkb`#5HEQH zn&b$8>i4Wt=BzibdV1ibG#s2C+)Y2X)v z3|6(aX1lGmBOotY%CGY0g)~Y$j7LKx+twOeK z%WaJFr9Z`J$dZbP1h@QP62`ybDvL}2c{dxP!b#t;ucAgEp@r8QH%C^iNsCx)yBXH& z;(zFAVQCA$hi(>EANJ-*7AmOw7klcXHHWeO^6-hu&;^FbH=vg~g|2|$q~=llmHftu zR_Wh6oYcPSzo+cvv!d+>R2)-xhA1AXQDVY7mN^L;?0RVm6Y7+U(*}uRfDXvQGQ$%D z5%TlY9Slm{$(d$mSbC8U_4~!+b3Ld**#}yq%5?^`1IA9X8NMh0+g_de@=|K?+*@q* z_^bm$ThzEwtHH_*)B&TfE06TD_N-akITD-@s6d;Q(6a{rBCZ7hac!M!H05VsXcSsY z_OI0AZutZ^ORXFy9`|J2Os~a;-en1EtY0pzD^*__51go7%Cu&B7zvUhb1*g||K&$T z;@DmGM{!ja*u$L3n^kd2$R~OU1+ zadx}K)B}9ks+hvk3RxUQ)if;)0EkPUBySd8#MpRIr{x${Zt2mQFYApGKRuKE6e7(L z9D3Q?RD`Lr!nLR)P0P4k*3LW{TS}rKrhr=tRL{yAkV?|Wym*JA@uQYprH%b(1{R(Q zg#G8^!yJe4vk!}*9QZ5?AKMZxfJcN^$#2tS9o2s;b;#&cgfeKg=0)I`u&D9C07KY- zn2GS?t6@KHOgn%&kARK&EB*Kh!Vn3H2*RrhYME6b51Afyy(sft#Ov zNgo%vj|P&Qd)U69p@c7E=H{Kv`{q$VT%2;C#Jwc}6?U|)*yfyOlx%PV_S_D!2ib0bn3&jTw`aI-e{3(hbPz?Th zc;UMNd1G3wt@)>0Edy@z_rHdRFEVv4%Kj3rE>NoETN}HvsYv-PMt}3LllYsje?nUm zS}_0#W)V|EX;kO-tR5xUo8}g-M&&NFA#pBM-&2>~k^FMMDKV?Z8FSFD%&M=g|CzBq(h8Xg7{s#+g{y$i7Vt(OiGc=^O_{K=` zN?!bo`ZEIFYIHbp^#c|1UDB0wqapS&&GQN05a%gzI`d~G+A1W^-6WSwQTISo0aT24 z@EnN_vD%0ScJ(NIqMTlgispDK$F;>_16mX0#lml@x;PCxuM51%ulLJMlyfwC2+espYd!88j%L_g^ z>1O;YHO?!Lsdv!L!`x?hi|8vP4=A0;kQOJz`dPsgZLMvK9iAwbz)c-_AIGnmk!tqo z+LEAV0p%Gv=cQ@7H3u~u1LVvaXcj=HNt&x$Dd`K*B z+FQW@(6mdrr5c$<`aT(|rbqsm;Uh98PJOu=Yd{xU_*MP=%EnFD{+ng-QSSrnGZg*QnYI6gGrnllzWVGyg)~SQ4lG8h6ON26J~|1s#*l?y6ILG0 z!$UX}6rO;c2k^GQ286iYp0&HV8l5k{z~vnG6>#`>_8Q^>RM6aba#ZEf6CJ{a9?#^- zYVwux3=ghyl#d)g!iwZQdHDztWtyo3*zNLf$L}=XUOMRpsbBrX0$MZ~9fW@iRB5~k z!GK~0%oflm5RxrNGa$CNtrGML307~G*|SIBg1qMnbrE$h@4S#7O0o$&1wtmV5jV@I zfU~e$dKg#K`lfvYOhXg^fT|KXYWOpF4G`B5O>8K{hzD7n0+{l%<#rpZ%G`?*r38FC8$cY;PaxlK^9QB5e6leHjHXJuN+6# z3KBn#Cv(-C^8GQe>_0+xjwLUqwfN5$rfeUgW5$`_ps`sn87MfgPUJ8*a+CEEMak?2 z%=xF2i)Wi776(O&o$4_FEU}tbt9LbbZ903h(|Mlg0ie%?gQ)Sr+!o(?CLbHLUK;%I zg7jRA6TdN%9-N`C4}0$*{j;cq+In2cU`+O?x6FFjVu$ZD%@jE@hI;`TC(*&VttYIXeH#IdQg#X@AFm{9I zU$h`f<0V|ntE=}$Hl%`OXs6m0-7mpiWvY0T$Tufg4}}WGW%TDXjfH&^Dfc_Z4gUfu zhcZ`LoVK^5K|ryt!;`(l5gw?a=PWl##ARhuWBs#cZY<2HBn zCg5;)Xd$lk@z__Eomsio7a}WEmVU+GTS)Sw8Q?IIAjv|pB^2*XPaS#|MwzPp^>`$T zs+lUt#up4ThodE7p#M@BU=Off3daF`1i+9B??A6)T+J^m!%3s$hx}sY$`G-)KWNh0 zMw6#-$zlrtL%I&G7bK*R)+Q+~wwL=KJ?(iSv@##f?RvAlDytr$(j4n+&94lZ*B z4YKnn;G#im6>nt_suqpr8ch|pJuk{U9kWs;EiEm_u=CH~XK3%Qtc=%!bk#u#1r)g< z(_4pko7n?`5{)@C3RKa{^%?M z{Yxr!BhtX(z7k%QofPpBQY3ELL5jbes#GNcZSdQ2INTlu#F~J^Ny}Y79FpA2<|stm z*)vW5>;H1JAcF#xr9tNSnn>u==P#Q^D6fLg`tf z-uSS>GW5SZ?d>&!54Cf8!x!n{F3t5miS%5JILE%Mg&~9YiJK1f8butg-4Z66+0%nU z(oP1sqM_SJ&aq*Gg^LzL&wWv9G**&2Dmq3+$pM5HAm*OHG*YarJSGWCdz^#zmX8dK zV2N?p4AeyZpYcEUVol31=3MYF;}sdi$`5BnKd8i+6D3XV2+B3BOz%1ORc6Lp?UF6Fi>BgCnVz$of$1oPCa#$ycTSywqsVGqW@)?? zRK|DRdaS=cL8_5T_D}%a<2C_&KUhy@?+pGwz^$J0vlHO9nCkS=HP<*Kg%_`?%YCh+ zS}-g}#zu0CfX%70skZgfbCqq{!V}xa3yq8SjmgVXcodX5oiykee7c)i%@GVGf zUtxigX@_EM1UX2t&1P0ty^d6?w#)mqY|tmSBV!u1#_4;eVBlaQF<@V>I@)@^l*lf< zb-rlTr2EBFR0*@Scj(2&hvdG3fu@=M?PLo8$&zDqhY%Px(#K2Tn_c$SXRWCN$?3wc zW7-C(gEZZ>nu;7z6Aeo5L)zPjxH^V_$J z{wN^AzJ`>Xj6soejioauMo~}>hdJx}IC)C;kK`2Qw;dChxeiSdMV-1{aaMzTffT)5V<|ymZ1Q zk9-2A=#J~*b(`xAg7rtWS~8jF#)C`+G|TMP@p|LY1y=J>JEy6kaKm5IpFaI&Z0w&* z`b?Q*gQTkGTZ}D&=XM25i@5gjH~9=BUMpk&%(& zS^i%s_gue^<~)$E`VMj=F6njvAbkU#8N2nXfvd-_xL>6zQc4eY_%fUVrw;suq6&(R z&wM^eAy}wppppE19kO^`2|1oul8pdljXH{jRT!9hfthC=8de@l-&tAzM+uj177On4Y=e`oO5quzKF7(9?OVSTX4TZehVPFzq^Cq zs_vOt_3xXs+U>dKB^KElDaG{fFFEmPM!O|!w&T`VD;v#yDa7^I%m4FRGw8&8*iY)R z!IE+bI^q954A(oQ-R!VSPT)Ae@q)_;zW6oC0KPa0^S^!|UmPx=R|Gy)R0U+xXF7WA zg6!@CfOOe8IbrmnPGOkNziUI5#LzCUE`v`5p4q0>9#tBz9yT6iM|L}gg>GLC$9%7P9qfDZ zYG8mQw_bd)_G*)q&{&CbN%+95xyY4`BhB}{O#40V&Efn196yU$Rrd4OhmV*$2fEit5et2a7xo>XQv*?riPEzE7w#Wjk-u?tyxn!-bK!d3v2AEZ z%^&I_rHNb@RaE3?7PX(#E;|UcJc=-QccbLa&~09Nk)z0@8;ep(>SoHgU)whui-5x@X6C8s?5hYioD9=Y%&X z{k!k)NC&Uf1a-M*?c4|4*`K5^0ZQqn6%)Evr#6ZJs6vD zFw4n@td7%Od86v<1JPPo#DGkm5@);GQy+0@-i2y@mB|B~NXHehG{_ViOw$!bP#B&^ zE_8zjwb)SUaJkgSq|~HpRMvfZ{I=X&*A_+>_%+;bRPXf~tkWO38y-xDm1mfR_9QVY z!Tq9I-_m$?@^;-%Lo;iB3d$5whF*_+z2P=Fn4CGCy?FzfMU#P8vV1q*RqZV~x8hX! z3~oYR4xlN^oOWt>x-K(8HCf}kDZ^~Cmh!!E6|WAqM3vXH!suCN6JU_7&JTl4MddeBeo$E{AU66SvnHwKV z*QTn~Im8#CnP8pLzqqr9vwPHrYB8I?*~pYGyY`byD~6kPDtuzC=5IWeZ7ba%~Q{w_Qyq|pX!9l3g3U8>%U`e`B)dTHK@qRF+fW* z^||A0w=#B*cw(h@3df7z{wEsvlBT0Zazs1P7`LG9@=~tbC28My|IoqYLg*I9iG%Gi z8nHNWh9R$&1-nNbl?n@j2cp%@9B+U)W2CSLqZ0Q&&@1>fL9O5uz_q(_pUJ&NjvSOu zg~6E)8gOrao~#!er~@XUN!j|PEDoC1}^-m{O7%4r3H58 z9q@k&-AuVO$91ZrhaMTnwGT$zIXo5Z`Zc`9qB8379r+<^DSb{!Y1$_H1wm=*%dhpH z>hh#Y%~(HAKHp+$@XYvneD~djEs5^|92a^Woe+QGNt}CogPj~BA?d*T&*ew~ z{j4OrM~uZV1LjGNCZ_N*mI9uSl4%z=hFDo0dn@0bhE}*Is%vgJl~`)+$igJnHfzsJ ztVO9!)`|z#-wlj~pD*RLkZAx`tNy zpMNlo_MvwxHiwXpzeyeGkqsM9L7iIACDwKWSEFV5X&b}oiFr9h+w%h!w6n6BzKUtX z0b-p?ni`dK7~dCes0)dU!wqI-URe$S>sW}oazU&+xz5WCEQ-)|pXlr}iiZd6YW zTFGi)wxu+esPJS;tp>L_#%kPD)MPHJju1nVkb^Hs)%53)UVW67eW%60X1 zz=wOZ0?Udri_NX#^T6Oms@xm`)(z)P|)A>-DpMO)`oWfGGO3knyeyfyx7Wd%l z7IWMbFrWB}hkss#YyHYw$PM=qI_xz5<#4eQ&MW zu5~q7-7XtCtD~`~jIxz)^`}gS!~@T$lXUe08{U7yk3Vx)Dfl&H^-!Vm^3{oP=Oh0( z+5rjVyTL@|$cf-t&y7&?m{5f5SyriM>Z`Gto8Vz7|Nb|;F6aU4%l46{NcWBL9oVRy z8ChUdy6JZrJO_!KLq4aS3cPU4c2pm48ZQ*~c&mOyan#h%_&eI|V(=(|Sjpb8)h`f| zXdW=Lqooxz;K$wE)6Fo44rhr}ilwJH9`>bU?-*N4c$MipyHrQY=T^)nSxe)h{zNf? zgZKqLUvULqa8(D(-qdZp95j9j#WOl(CXQy@uS%S*wbw0rDr@7+Y0@f|g4ilEtc_%` z<8{J8drHo8?Yx?MKb5HIE%!gaTg%Z35HdOX`3~VWt>Pf})+ysm+4eh|-*_jev*c*P zUG4{>R)fBowN=FRJRY4mjxCBu8gS?oLTnRxQXt%)>J}17XN3BxO>8`i59EL~rTtk8 zAlw1F;Di1BxXCR3;JuC;6rir@<~8 zpOSnM2=2lkda|`#!zp55>px){-12INtLQ>&aqfs16u=7rb^ZW@hK-s1_P9 zEB@mAm;>T4+BVPvvwC2`0?s`f-U%UMV`&g~t6D#wd59UeRB2rPWjREcPfbGh&Zf15 z3YtHE@pQIhS&lz3GiyfPIGg#SA8+=+^ed8jsq_~)*5V|)kyvY^z!xM^l!LvB(AY?9 zi#!8#isQOf{#(fEM7^Z*@FlasR(QR?>lhB9cersZ^^#6YYUc*g1nx~7bT(m}^q;IZ zAhth;$XSGy*o12MjrRyuVzCD=FSixc7Vn=w0u z+o6Sq)FYRuGybDbT7n*lU9BJ};||Gfb2MYq-2<$F7=rMJHd= zB=ynq++K1}N*!NCmb7#IixaSw(iA0H?F4SOkB#LWEbve%=w(`KRQ7^`&pkY?RTF>` zmCkD9`5+K{atB62hV+JdbVIU)=pU^{LvXBZ*fnXj05^NZ`?^ckr6~FPR#waH_;V^S6!T ziB~00Lz%sp!!`TIh}n$Oz}tN<&;cneGi)T}IB&~adotbf-vn#bAI7~b`&l}AQob0# zjV|K`-QtmErl#MYU!daXXpLpb;z1w~awp!Hp?**+PutIFV;m|NkpZWPHh?m|oi@cf z$ourX?&aY$b+B&&vnteD>0-R%I?6P&>MLnVS=n>dywaOpU18C#|4x;krIGF)^{bH3(< zz1jzFu99y{^A@HxR~$2xS?v0Dt6Zlx8`{fWFIWApY1xyL|I%iQBGVQn4SdY%7P${a zQ?f_Y364U5fZeQ0>x3ie6;aRU|7ILO?6&21vDE3bTi+*8a?_a4?{sGf7^z18tm#C= zVbi=>JL(rX!K+QHS1i~G{}K-^D4(YOB96akM>itjG~{jzx3$NnL_l$cS$$3mY0oCTNY!VUN;ig&Q9kc3uC{Ukv9?`FC7B7<^ka-VcDy-w_4c_$wQH* zdM?6(#YSO^Sys4+@r-xlbk{xUS2o^_NuGml#e-fF=b0i2nrhmf%N`k?8Xn^Yk?1Yc zm89bNkp-MkvlrjK(XcP07SY4~$>75$cjA$(Xu-0@@Gbh3GY~7b4>j+ee=h_6(YAg zMUpjv_Kr$1$(k@(!s7PHl@0SiQ^2JFW*$lPPti~fYW-Y;gA}1H zy)*2_tsGO8#7A@QH@wO#8M>YLJi4+Otcn&0KJEPoDT;ctqT;np<^w5@0I`p&Pgsua zoF>!mm^cch!`Tk|H;Urj``uJ9m})aybYSi3;AJht%MyVgJyU!Qyo{is47+JX< zKI=QJ!c&}Uw7S;#HW{M&?Qmy5dt;k3YT+I!{Xz#ujdJ<*a^0bXS$y!gb_zsop2V2^ z5`svbRC!p2nKg_}H(*1POe&1CiEkOtBk2lfw-k&A^;;JPREf47UI(n`lBi&uys^og z?Et3D(Um-9PtNRLf2%l3=>zWG-U(G}EsPzDY&^rSW~ywcoX!t54ayr3%>}^?LBh7f zmM~Rj1O5EMF7LHWG!w<`57MPJ*b_iCz&s z8KRYc-rC35$TI1vwUy{OGQn1Ah?qD8%HowPLS;PdQ6g0pbq?hl zIKngr@}h>Viq+9XEqd;SjeHkVqj#3zJvpGK6I6e~%F+zlB@g>&a_ZK2TFc z=l%dsJU6tak}^)@6vQPtcm+`FW+bC5AHy-=Zf)rsV$d2iIdHKVN12O@F$^{t49|RC zut9e#WE(nC8%9qjMeJIz>9aT<40c~6p*JYPOKke(#BXnsvq<|BgRM|`a8cQoY;|Cw zCM28U3E|Bl3ph$NQ`+(2lO#4ghkJ$WrSP<-5nh#-H->|F5{5m>+a#`2q{}A7sgDaO54u&$3U4IFu}~QEG7Fzc23uhloHoLH36Tf3g3r_?3KBeSJMz z1}{IQecjY#yyx;iE{b>LB+adsza3__n>yiUF?Y;-Lyvz_Igt1ElQbE_HXfcxP)|B47(B@*5aCjEIz36e$X&%J4fbdddZD@7o=nhGYPDeu~mvV({#?v-EYQ-P_^{Rm~o3tpf9sYCqq?L2h*il5KQ-km3 z!Kc54|DXjbbNL&gmMHE8HubApSIO(>*Mz`}9MHn+_v`uXi(|EGLd}$AY(&SZ&SLe9 z;TQh{{52UscDwJmCEI$p|F^F#Ic~V<>GR6BvQ$_F>Sf9QcAvd1?*p`{X4@#)+P6C^ zlDjNxdi+j|CF)P^AAkB1l61UKJ=g3l`?Gkrb(NXhAFkzm7}PeXF_(jsBYs%zCe0Gs z{77bPV0_Po=4~rK3o(|L^!3@V_jKut{7Ejt1As`gF7LCMBG~38&Yr=tN9v1r&+_aX zgF?x;e&~bj{cpF4qF^5+&j`3!gmi&9V_B)*ez^@MT4J3-9cw?H?n-Lc*pIr-&9mbToy7Im~CbELh4t$f_?5)2G>tc zYEIi%Z_h@S3@qIAbWFD#hURy$jK*x@x^(u0wU31a2p4E!~^d@T@=j8e`D5 ze}AK)X`jRFc(L*DmgT{c={`hmIlr7Ic+*%>mtIdp zJ^mll^LndaiDdE65|``#R~Q&VL&Cl!A;(LPZQFL^v}|% z%ouR9nYkM~A02yGwvR)Ab@WEXW5>u;N$T2rXxtPUJq)ZK;u>4GY8q;5B~5^zT=PDM zxokgZOVO}8(rbICp4G59$59aMPn_f&-5Y0Q{|C%grA2$TzmSbHy8aS|Z|Ijk?xor& zD>M)Ig z$L|6rTtqYFP3gxUv)(*6l4p_{(lpM?d&dZs*tuPqXpP9Q=|ZY^TqD*~TP#mv4-Do5 zy3=+`ttDkWgm1s9KpF_WEk!>yT}KaY(2a+lWy5!Vp)`z6l=hdJy`SLE3qd>8r%a;LO(W@;K6mq+(1kI_31*&Vhhy>IRZ8|TR|Ova>)^s z&gsjc%3J!p+Fu%u$Q0j%8qS64Dx9cv>4!%7foTNJ+IYya)Fv~0V%(+m>y}Q^1g4SW z>+OHS1lZMMxdOhOC-+?B02NJ^w11e;ocCb++UBQTXFg~@RQ2aJ-<%*NPFwy#! zm9Q0`5=w5`{&Xh%o!MomVIY#601+cg(r33iK z;>zlA^DZ;L&$<+w=lCJ(RdlZm9{7(It$K3KEsPa+rt{+&MweeXzP~8Zpvzq9n8DH? z{i$7a$+RG7c-+v$hj*|uwAMUB_`{fl{jT`sO=#|kZ8SMPJ-=!t&RvL|+$zt}0V9QF zNtT$pMWSEZYa0`baFFvSdJg!s2aV)NH&S5}8RjQ-46 z^Rfqzn5#yIIX&RpFKRG&U|(Qf)wgz;;F=iBOgxXL*e@cJ4cy593Fsw|O;@ONQOMqu zCXF)ADg7V9B7$nEaAe-fg*b`8_p49iV1b3TTa$U2bxy5kXsm3cVQCCn)BE-A#R};a zUypb;(53CmZ{AcqrB+>5v$?{cW-X?p03LCN*_8X&tQqfrDU|iE@&q$glJ=MYD@u^-ZS{PB%C^QtoUeeHpM0bqYgY0@T72e?vYu`e6i|p- zwr3J_n=tKRamB`C^hg!geQy(+TxcqjQg!6j$OZi zfCUrg{@`*)z6xwAdlpLz3ltcmblHLO2Ft;JP314+wZncg!DT0WZJQTo*J>MgeJ#H< z95H}D;v3u{tyKO_JkGGb?)?8D&9;d%|Mw3!U&of_`5TP|+68M1LEc)*xk+6Mw*9ws zho0znKH#BS1_x%fhif*UX})SdP$VH^p$d!TZ#Z0^)(WZvTI8i8&71e#a=z_v zZ*Th?4%@cG7L&x*p?VFU?;7# zo~x{AC+haUEWCzo&ahW$8&)MSOc_jCK;gnWg;j{b+&WL$z~j!{8b*x909iCM$9nD; znqs#$EOsUYAEgIN9!|3}JZP{SDTg)8mm^Qq!HU4eG?}`^blS#acyI-$^Ke6@S8L_u z24Tkh2q=VVkEgz;KWjW=x)PlG9@SDavynw#)_YU_#-brA@%_CG^zU}vSC>);4O=PO zi9;VCe(cpkq`DN1LExegp>id?GmAuaOIuISB)zm<>-j!zr8-F z7K2*>;vXj#>>cd`&SOUb$CC%b-+_$zW(8*4D{Hfu_r0;!bE;&;Xi#6sJp7cJ$1+DV zNgcGhGNOvQ6|)9gIknmYyVR0-=}YR7dTph|z?xSNLAJf^b3lUM);JpourEkhi7JaB z#++U&Ljw0^Hz|&mPXU!U-tQ07$W~E#XR6p7EM(($SQ;BF;#{AjvKqL!M`%M3*ku2e z1b>PfjnM@I4U!5WHiRjd!Np0KTKF5GU>nqC;U%&^x=8$-S)~)xPeVQ5%>?Bp-juu3 zN4~C6A}5IdIW@NaSkqVwK7$An+NEH*FE?oawfy?S4%xt?>ePn^)%*cs&{;ILkr5b^ zjku1myiV!}80HNu#VY-~UgdZ&*w(PJ zBkaBJFs{m>|NTu?BCY2nr>|F|m{Eo60A1tDLv%3Ca+T4$WubbOtMsKgLOqdT$Q6+a ze}Sg_K^7ya3z6*Obe2-m{GX}p7b(sy&)!e8~{N5tYhDKeSjD+n@!NJ~9k zCfvldtq!u0Gs8pIsZscNal`jJcF=Ui$(!_yf7a<18Z{F>$J}8-Ly=?SGG2C#soav^ z_Zw!npDHWOu_$Tje%4ilfsPEnv?Ww8{#@AGLo_&1e6z(j=jRC462ak(Ke4qQH2o zjI11Iyi&L30I>?z&7h@g|3u}-2X*3D=?8R5j>=6^RCSDAYf&JAC))nNvqPEvM$(j+;XG3pM!=pLd5B$TT85w9geLXhHCuRk#9lzn zXT%PZyiZ|=UMZ&yuMPIXb?BgI^Z(^V<6ERr!9RrzatncXr@rsE>< zP@QkQEhx@#xu|E$b!ScsEFp>cmOlXqBc`%d-p28X+K>-tHY7J~t<*db-R$LctCHdf}a?IqThl5M0I6`m&=tX{F#kcFC z59XLu4nC+p-rDDV@Q3eKv^N)XysMJa7$}2;@?8g=CQS6EErm8Nf+`Y>jp|B)2j=a5 zyuiX!6k8&Milg`ErAVS2MNnjMOHlJ0C3JxK#NuSsIIXt|!cH>YqgYR@PpFRz_VVUa zoP%D40V|d=*Gx!<=R!L2+Hg{FceBqZ81DVAHBv-Z>v z(;Fsdo4K(okH;i#dUpzUUvU`Q+o0>8sRB;vz)xgIVQ5v-+#$MzTc{8wTHsdR7H7g+ zzHLP{SkEJDgE+QsO&BL$`| zQ@n2?jAP3(+Y^9<*lIcl&qMbnXg7X)NgmitbE=ej`w~(MVCbz^*ND<9;%6|BgREDK zNvTxfC5fNO>5!xl8oLboHR_|FrucQ{&9_vUzElAR8BuX3TU$=5{=cAfQ*Im`)uN4D zGy;Eb3Fqx!w15|xjpy;p0}(Hf#5YB_VKNm{G@U$DL$7Ib8@BD_W%QOyry|V|X?6$U zGze3>18X;(TQL%+kPt&?7@?_3R1nGnazHi1UV|F8)M*!ER9QCZiBdeDP9B1KitP#z z6RB_zGu}Lo3KjFQ@Tb>J^SwF`rbO)<6m^(N|SPn$_meflg&ZdlW$*jHjro zKGdSvL_`;}!}J-THFxjmGh|P~#&7=X&?m}`kGrLkJ|nPsR+K1QgnYPetN|UcuDK&n zpn1B;u{1{KaXRtVH{1hv{~xBla>`E=MF)IBFp<^+t09QiIW5z2$Li${Ki&h_4UQOz z6*mRr={?>N$MuZFNT6oTQf=>r)F{jkc?!=2RUBF0Cpu1PCH09$T~trH)Fw#|~@|aks_4RMeE@qsWyvUT5iSW{emy=CbR9q)syFN_c0_O6(pz@yj+}Y8S$#*}w)jb}sGF>RV_;h1pLWL# zMmnI%VNxnZ0O{rgsZvB0DFTWk(Ee3_)%)`e*FuF#zzmB|(%t?PpiQ^s3KhN*h8hej zGbjn`tr~Ra=#&tKk zglOm4wQ@${Q0T>HU&@Lu1MxF8GOxtj2AMr{^J7aaoGB`{i@N0wDlXXWvO03UKdVbaBu-uK&{ki??!`g1V&jW21ge+1ApM`?P1dY`LTRFgR0U8TjZ07X~ zcy_Ys;I+=541p&wb^8$m3A>cVUus~`- zA%&L)cDumx6wxO7z;m$Ne?2yE6i}95?ACkhe7q{q)KP#D0u6#s|1)PMdAFBe$oc@1 N^>p=fS?83{1OTqbIF|qb literal 0 HcmV?d00001 From 206fbbf67cc0dc366a063e1cd69c18488f1d484d Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Tue, 2 Aug 2016 11:15:50 -0500 Subject: [PATCH 03/12] intro to segwit second draft --- segwit.asciidoc | 71 ++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 62 insertions(+), 9 deletions(-) diff --git a/segwit.asciidoc b/segwit.asciidoc index 1e5a28be..59eacfdf 100644 --- a/segwit.asciidoc +++ b/segwit.asciidoc @@ -11,23 +11,76 @@ Will be merged later into chapter 6 or 7, as the book is reorganized Segregated Witness is an upgrade to the bitcoin consensus rules and network protocol, scheduled for implementation in the second half of 2016. -In cryptography, the term "witness" is used to describe an input that satisfies a cryptographic condition. If the condition is a signature corresponding to public key, the witness is the signature. +In cryptography, the term "witness" is used to describe a solution to a cryptographic puzzle. In bitcoin terms, the witness is the unlocking script that satisfies a cryptographic condition placed on a UTXO via the locking script. -The unlocking script presented in each input in a bitcoin transaction is the witness that satisfies the condition imposed by the locking script on the UTXO. The term _segregated witness_ or _segwit_ for short, simply means separating the signature or unlocking script from the rest of the transaction. Think "separated signatures" in the simplest form. +In the context of bitcoin, a digital signature is _one type of witness_, but a witness is more broadly any script that can satisfy the conditions of a locking script and unlock a UTXO for spending. The terms “witness”, “unlocking script” and “scriptSig” all mean the same thing. -Segregated Witness therefore is a change to bitcoin that aims to move the signatures outside of the transaction data structure and into a _witness_ data structure that accompanies a transaction. Clients may request transaction data with or without the accompanying witness data. +Before segwit’s introduction, every input in a transaction was followed by the witness data that unlocked it. The witness data was embedded in the transaction as part of each input, The term _segregated witness_ or _segwit_ for short, simply means separating the signature or unlocking script of a specific output. Think "separate scriptSig", or “separate signature” in the simplest form. + +Segregated Witness therefore is an architectural change to bitcoin that aims to move the scriptSig (unlocking script) outside of the transaction data structure and into separate a _witness_ data structure that accompanies a transaction. Clients may request transaction data with or without the accompanying witness data. + + + +In this section we will look at some of the benefits of segregated witness, describe the mechanism used to deploy and implement this architecture change and demonstrate the use of segregated witness in transactions and addresses. -In this section we will look at some of the benefits of segregated witness, describe the mechanism used to deploy and implement this architecture change and demonstrate the use of segregated witness in transactions and addresses. ==== Why Segregated Witness? -Segregated witness is not really a feature. It is an architectural change that has several effects on the scalability, security, economic incentives and performance of bitcoin. +Segregated witness is an architectural change that has several effects on the scalability, security, economic incentives and performance of bitcoin. -Transaction malleability :: By moving the witness outside the transaction, the transaction hash used as an identifier no longer includes the witness data. Since the witness data is the only part of the transaction that can be modified by a third party (see <>), removing it also removes the opportunity for transaction malleability attacks. With segregated witness, transaction hashes become immutable, which greatly simplifies many applications using advanced bitcoin transaction construction, such as payment channels, chained transactions and lightning networks. +Transaction malleability :: By moving the witness outside the transaction, the transaction hash used as an identifier no longer includes the witness data. Since the witness data is the only part of the transaction that can be modified by a third party (see <>), removing it also removes the opportunity for transaction malleability attacks. With segregated witness, transaction hashes become immutable, which greatly improves the implementation of many other protocols that rely on advanced bitcoin transaction construction, such as payment channels, chained transactions and lightning networks. + +Script Versioning :: With the introduction of segregated witness scripts, every locking script is preceded by a _script version_ number, similar to how transactions and blocks have version numbers. The addition of a script version number allows the scripting language to be upgraded in a backwards compatible way (ie. using soft-fork upgrades), to introduce new script operands, syntax or semantics. The ability to upgrade the scripting language in a non-disruptive way will greatly accelerate the rate of innovation in bitcoin. + +Network and Storage Scaling :: The witness data is often a big contributor to the total size of a transaction. More complex witness scripts such as multi-sig or payment channels scripts are very large and represent the majority (more than 75%) of the data in a transaction. By moving the witness data outside the transaction, segregated witness improves bitcoin’s scalability. Nodes can prune the witness data after validating the signatures, or ignore it altogether when doing simplified payment verification. The witness data doesn’t need to be transmitted to all nodes and does not need to be stored on disk by all nodes. + +==== How Segregated Witness Works + +At first glance, segregated witness appears to be a change to how transactions are constructed and therefore a transaction-level feature, but it is not. In fact, segregated witness is a change to how UTXO are constructed and therefore is a per-output feature. + +A transaction can spend segregated witness outputs or traditional inline-witness outputs or both. Therefore, it does not make much sense to refer to a transaction as a “segregated witness transaction”. Rather we should refer to specific outputs (UTXO) as “segregated witness outputs”. + +When a transaction spends a UTXO, it must provide a witness. In a traditional UTXO, the locking script requires that witness data be provided _inline_ in the input part of the transaction that spends the UTXO. A segregated witness UTXO, however, specifies a locking script that can be satisfied with witness data outside of the input (segregated). + +Segregated witness outputs are constructed in a backwards compatible way so that older systems that are not segregated-witness-aware can still validate them. To an old wallet or node, a segregated witness output looks like a ANYONE_CAN_SPEND output. Such outputs can be spent with an empty signature, therefore the fact that there is no signature inside the transaction (it is segregated), does not invalidate the transaction. Newer wallets & nodes however see the same output as a segwit output and expect to find a valid witness for it in the transaction’s witness data. + +==== Economic Incentives for Segregated Witness + +Bitcoin mining nodes and full nodes incur costs for the resources used to support the bitcoin network and the blockchain. As the scale of bitcoin increases, so does the cost of resources (CPU, network bandwidth, disk space, memory). Miners are compensated for these costs through fees that are proportional to the size (in bytes) of each transaction. Non-mining full nodes are not compensated, so they incur these costs because they have a need to run an authoritative fully-validating full-index node, perhaps because they use the node to operate a bitcoin business. + +Without transaction fees, the growth in bitcoin data would arguably increase dramatically. Fees are intended to align the needs of bitcoin users with the burden their transactions impose on the network, through a market-based price discovery mechanism. + +The calculation of fees based on transaction size treats all the data in the transaction as equal in cost. But from the perspective of full nodes and miners, some parts of a transaction carry much higher costs. Every transaction added to the bitcoin network affects the consumption of of four resources on nodes: + +Disk Space :: Every transaction is stored in the blockchain, adding to the total size of the blockchain. The blockchain is stored on disk, but the storage can be optimized by “pruning” older transactions. + +CPU :: Every transaction must be validated, which requires CPU time. + +Bandwidth :: Every transaction is transmitted (through flood propagation) across the network at least once. Without optimization, transactions are transmitted again as part of a block, doubling the impact on network capacity + +Memory :: Nodes that validate transactions keep the “UTXO set”, the list of all unspent transaction outputs, in memory. Because memory is at least one order of magnitude more expensive than disk, growth of the UTXO set contributes disproportionately to the cost of running a node. + +As you can see from the list above, not every part of a transaction has an equal impact on the cost of running a node or on the ability of bitcoin to scale to support more transactions. The most expensive part of a transaction are the newly created outputs, as they are added to the in-memory UTXO set. By comparison, signatures (aka witness data) add the least burden to the network and the cost of running a node, because witness data are only validated once and then never used again. Furthermore, immediately after receiving a new transaction and validating witness data, nodes can discard that witness data. If fees are calculated on transaction size, without discriminating between these two types of data, this does not align the market incentives of fees with the actual costs imposed by a transaction. In fact, the current fee structure actually encourages the opposite behavior, because witness data is the largest part of a transaction. + +The incentives created by fees matter because they affect the behavior of wallets. All wallets must implement some strategy for assembling transactions that takes into considerations a number of factors, such as privacy (reducing address re-use), fragmentation (making lots of lose change) and fees. If the fees are overwhelmingly motivating wallets to use as few inputs as possible in transactions, this can lead to UTXO picking and change address strategies that inadvertently bloat the UTXO set. + +Transactions consume UTXO in their inputs and create new UTXO with their outputs. A transaction, therefore, that has more inputs than outputs will result in a decrease in the UTXO set, whereas a transaction that has more outputs than inputs will result in an increase in the UTXO set. Let’s consider the _difference_ between inputs and output and call that the “Net new UTXO”. That’s an important metric, as it tells us what impact a transaction will have on the most expensive network-wide resource, the in-memory UTXO set. A transaction with positive Net-new-UTXO, adds to that burden. A transaction with a negative Net-new-UTXO reduces the burden. We would therefore want to encourage transactions that are either negative Net-new-UTXO or neutral with zero Net-new-UTXO. + +Let’s look at an example of what incentives are created by the transaction fee calculation, with and without segregated witness. We will look at two different transactions. Transaction A is a 3-input, 2-output transaction, which has a Net-new-UTXO metric of -1, meaning it consumes one more UTXO than it creates, reducing the UTXO set by one. Transaction B is a 2-input, 3-output transaction, which has a Net-new-UTXO metric of 1, meaning it adds one UTXO to the UTXO set, imposing additional cost on the entire bitcoin network. Both transactions use multi-signature (2-of-3) scripts, to demonstrate how complex scripts increase the impact of segregated witness on fees. Let’s assume a transaction fee of 30 satoshi per byte and a 75% fee discount on witness data: + + +Without Segregated Witness +Transaction A fee: 25,710 satoshi +Transaction B fee: 18,990 satoshi + +With Segregated Witness +Transaction A fee: 8,130 satoshi +Transaction B fee: 12,045 satoshi + + + +Both transactions are less expensive when segregated witness is implemented. But comparing the costs between the two transactions, we see that before segregated witness, the fee is higher for the transaction that has a negative Net-new-UTXO. After segregated witness, the transaction fees align with the incentive to minimize new UTXO creation, by not inadvertently penalizing transactions with many inputs. -Transaction size :: The witness data is often a big contributor to the total size of a transaction. In the case of multi-signature or other complex scripts, the majority of the data in the transaction is witness data. By moving the witness data outside the transaction, segregated witness improves bitcoin’s scalability. Nodes can prune the witness data after validating the signatures, or ignore it altogether when doing simplified payment verification. -Economic Incentives :: Transaction fees are calculated based on the size of the transaction. But not all parts of the transaction are equally “expensive” to carry by the bitcoin network. UTXO data which must be kept until the UTXO are spent and are usually stored in memory for rapid validation of transactions are the minority of a transaction’s data. Witness data on the other hand, can be discarded entirely after a single validation, yet they make up the majority of a transaction’s data, especially for complex witness scripts. With segregated witness, the transaction fees are discounted on witness data and the influence of the size of UTXO in a transaction becomes greater, properly aligning incentives through fees with the actual economic costs to the network. -Fraud Proofs :: Segregated witness will allow the construction of _fraud proofs_. When lightweight clients use simplified payment verification (SPV) to validate that a transaction has happened, they have to implicitly trust the miners, to a certain extent. They can validate the existence of a transaction but do not validate the full consensus rules. With the introduction of segregated witness, it becomes possible for nodes to construct and exchange cryptographic proofs that demonstrate the validity of transaction inputs. From 9f58016b95cd1cbfcd505400108dd5522b5150c2 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Mon, 8 Aug 2016 17:01:44 -0500 Subject: [PATCH 04/12] P2WPKH and P2WSH --- segwit.asciidoc | 103 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 95 insertions(+), 8 deletions(-) diff --git a/segwit.asciidoc b/segwit.asciidoc index 59eacfdf..fc5a71d8 100644 --- a/segwit.asciidoc +++ b/segwit.asciidoc @@ -42,11 +42,100 @@ A transaction can spend segregated witness outputs or traditional inline-witness When a transaction spends a UTXO, it must provide a witness. In a traditional UTXO, the locking script requires that witness data be provided _inline_ in the input part of the transaction that spends the UTXO. A segregated witness UTXO, however, specifies a locking script that can be satisfied with witness data outside of the input (segregated). -Segregated witness outputs are constructed in a backwards compatible way so that older systems that are not segregated-witness-aware can still validate them. To an old wallet or node, a segregated witness output looks like a ANYONE_CAN_SPEND output. Such outputs can be spent with an empty signature, therefore the fact that there is no signature inside the transaction (it is segregated), does not invalidate the transaction. Newer wallets & nodes however see the same output as a segwit output and expect to find a valid witness for it in the transaction’s witness data. +==== Soft-fork (backwards compatibility) + +Segregated witness is a significant change to the way outputs and transactions are architected. Such a change would normally require a simultaneous change in every bitcoin node and wallet, to change the consensus rules with what is known as a hard fork. Instead, segregated witness is introduced with a much less disruptive change that is backwards compatible, known as a soft fork. This type of upgrade allows non-upgraded software to ignore the changes and continue to operate without any disruption, without changes to the consensus rules. + +Segregated witness outputs are constructed so that older systems that are not segregated-witness-aware can still validate them. To an old wallet or node, a segregated witness output looks like an output that _anyone can spend_ . Such outputs can be spent with an empty signature, therefore the fact that there is no signature inside the transaction (it is segregated), does not invalidate the transaction. Newer wallets & mining nodes however see the segregated witness output and expect to find a valid witness for it in the transaction’s witness data. + +==== Segregated Witness Output and Transaction Examples + +Let’s look at some of our example transactions and see how they would change with segregated witness. We’ll first look at how a Pay-to-Public-Key-Hash (P2PKH) payment is transformed with segregated witness program. Then, we’ll look at the segregated witness equivalent for Pay-to-Script-Hash (P2SH) scripts. Finally, we’ll look at how both of the above segregated witness programs can be embedded inside a P2SH script. + +===== Pay-to-Witness-Public-Key-Hash (P2WPKH) + +In <>, Alice created a transaction to pay Bob for a cup of coffee. That transaction created a Pay-to-Public-Key-Hash (P2PKH) output with a value of 0.015 BTC that was spendable by Bob. The output’s script looks like this: + +.Example P2PKH output script +---- +OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG +---- + +With segregated witness, a Pay-to-Public-Key-Hash output, is created instead a Pay-to-Witness-Public-Key-Hash (P2WPKH), which looks like this: + +.Example P2WPKH output script +---- +0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 +---- + +As you can see, a segregated witness output’s locking script is much simpler than a traditional output. It consists of two values that are pushed on to the script evaluation stack. To an old (non-segwit-aware) bitcoin client, the two pushes would look like an output that anyone can spend and does not require a signature (or rather, can be spent with an empty signature). To a newer, segwit-aware client, the first number (0) is interpreted as a version number (the _witness version_) and the second part is the equivalent of a locking script known as a _witness program_. + +Now, let’s look at the corresponding transaction that Bob uses to spend this output. For the original script (non-segwit), Bob’s transaction would have to include a signature within the transaction input: + +.Decoded transaction showing a P2PKH output being spent with a signature +---- +[...] +“Vin” : [ +"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", +"vout": 0, + "scriptSig": “”, +] +[...] +---- + +However, to spend the segregated witness output, Bob’s transaction has an empty scriptSig and includes a segregated (separate) witness: + +.Decoded transaction showing a P2WPKH output being spent with separate witness data +---- +[...] +“Vin” : [ +"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", +"vout": 0, + "scriptSig": “”, +] +[....] +“witness”: “” +[...] +---- + +===== Pay-to-Witness-Script-Hash (P2WSH) + +In <> we saw our first example of a Pay-to-Script-Hash (P2SH) address used by Mohammed's company to express a multi-signature control script. Payments to Mohammed's company were encoded with a locking script like this: + +.Example P2SH output script +---- +OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL +---- + +The P2SH script above references the hash of a _redeem script_ that defines a 2-of-3 multi-signature requirement to spend funds. If Mohammed's customers were using a Segregated Witness compatible wallet, the equivalent payment would be to a Pay-to-Witness-Script-Hash (P2WSH) output script that would look like this: + +.Example P2WSH output script +---- +0 54c557e07dde5bb6cb791c7a540e0a4796f5e97e +---- + +Again, as with the example of P2WPKH, you can see that the segregated witness equivalent script is a lot simpler and omits the various script operands that you see in P2SH scripts. Instead, the segregated witness program consists only of a witness version (0) and the script hash. + +Mohammed can spend the Pay-to-Witness-Script-Hash output by presenting the correct redeem script (whose hash matches the script hash in the witness program) and sufficient signatures to satisfy the redeem script. Both the redeem script and the signatures would be segregated _outside_ the spending transaction as part of the witness data. Within the spending transaction, Mohammed's wallet would put an empty scriptSig: + +.Decoded transaction showing a P2WSH output being spent with separate witness data +---- +[...] +“Vin” : [ +"txid": "abcdef12345...", +"vout": 0, + "scriptSig": “”, +] +[....] +“witness”: “SigA SigB 2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG” +[...] +---- + + ==== Economic Incentives for Segregated Witness -Bitcoin mining nodes and full nodes incur costs for the resources used to support the bitcoin network and the blockchain. As the scale of bitcoin increases, so does the cost of resources (CPU, network bandwidth, disk space, memory). Miners are compensated for these costs through fees that are proportional to the size (in bytes) of each transaction. Non-mining full nodes are not compensated, so they incur these costs because they have a need to run an authoritative fully-validating full-index node, perhaps because they use the node to operate a bitcoin business. +Bitcoin mining nodes and full nodes incur costs for the resources used to support the bitcoin network and the blockchain. As the volume of bitcoin transactions increases, so does the cost of resources (CPU, network bandwidth, disk space, memory). Miners are compensated for these costs through fees that are proportional to the size (in bytes) of each transaction. Non-mining full nodes are not compensated, so they incur these costs because they have a need to run an authoritative fully-validating full-index node, perhaps because they use the node to operate a bitcoin business. Without transaction fees, the growth in bitcoin data would arguably increase dramatically. Fees are intended to align the needs of bitcoin users with the burden their transactions impose on the network, through a market-based price discovery mechanism. @@ -56,13 +145,13 @@ Disk Space :: Every transaction is stored in the blockchain, adding to the total CPU :: Every transaction must be validated, which requires CPU time. -Bandwidth :: Every transaction is transmitted (through flood propagation) across the network at least once. Without optimization, transactions are transmitted again as part of a block, doubling the impact on network capacity +Bandwidth :: Every transaction is transmitted (through flood propagation) across the network at least once. Without any optimization in the block propagation protocol, transactions are transmitted again as part of a block, doubling the impact on network capacity Memory :: Nodes that validate transactions keep the “UTXO set”, the list of all unspent transaction outputs, in memory. Because memory is at least one order of magnitude more expensive than disk, growth of the UTXO set contributes disproportionately to the cost of running a node. -As you can see from the list above, not every part of a transaction has an equal impact on the cost of running a node or on the ability of bitcoin to scale to support more transactions. The most expensive part of a transaction are the newly created outputs, as they are added to the in-memory UTXO set. By comparison, signatures (aka witness data) add the least burden to the network and the cost of running a node, because witness data are only validated once and then never used again. Furthermore, immediately after receiving a new transaction and validating witness data, nodes can discard that witness data. If fees are calculated on transaction size, without discriminating between these two types of data, this does not align the market incentives of fees with the actual costs imposed by a transaction. In fact, the current fee structure actually encourages the opposite behavior, because witness data is the largest part of a transaction. +As you can see from the list above, not every part of a transaction has an equal impact on the cost of running a node or on the ability of bitcoin to scale to support more transactions. The most expensive part of a transaction are the newly created outputs, as they are added to the in-memory UTXO set. By comparison, signatures (aka witness data) add the least burden to the network and the cost of running a node, because witness data are only validated once and then never used again. Furthermore, immediately after receiving a new transaction and validating witness data, nodes can discard that witness data. If fees are calculated on transaction size, without discriminating between these two types of data, then the market incentives of fees are not aligned with the actual costs imposed by a transaction. In fact, the current fee structure actually encourages the opposite behavior, because witness data is the largest part of a transaction. -The incentives created by fees matter because they affect the behavior of wallets. All wallets must implement some strategy for assembling transactions that takes into considerations a number of factors, such as privacy (reducing address re-use), fragmentation (making lots of lose change) and fees. If the fees are overwhelmingly motivating wallets to use as few inputs as possible in transactions, this can lead to UTXO picking and change address strategies that inadvertently bloat the UTXO set. +The incentives created by fees matter because they affect the behavior of wallets. All wallets must implement some strategy for assembling transactions that takes into considerations a number of factors, such as privacy (reducing address re-use), fragmentation (making lots of loose change) and fees. If the fees are overwhelmingly motivating wallets to use as few inputs as possible in transactions, this can lead to UTXO picking and change address strategies that inadvertently bloat the UTXO set. Transactions consume UTXO in their inputs and create new UTXO with their outputs. A transaction, therefore, that has more inputs than outputs will result in a decrease in the UTXO set, whereas a transaction that has more outputs than inputs will result in an increase in the UTXO set. Let’s consider the _difference_ between inputs and output and call that the “Net new UTXO”. That’s an important metric, as it tells us what impact a transaction will have on the most expensive network-wide resource, the in-memory UTXO set. A transaction with positive Net-new-UTXO, adds to that burden. A transaction with a negative Net-new-UTXO reduces the burden. We would therefore want to encourage transactions that are either negative Net-new-UTXO or neutral with zero Net-new-UTXO. @@ -81,6 +170,4 @@ Transaction B fee: 12,045 satoshi Both transactions are less expensive when segregated witness is implemented. But comparing the costs between the two transactions, we see that before segregated witness, the fee is higher for the transaction that has a negative Net-new-UTXO. After segregated witness, the transaction fees align with the incentive to minimize new UTXO creation, by not inadvertently penalizing transactions with many inputs. - - - +Segregated witness therefore has two main effects on the fees paid by bitcoin users. Firstly, segwit reduces the overall cost of transactions by discounting witness data and increasing the capacity of the bitcoin blockchain. Secondly, segwit’s discount on witness data correcting a misalignment of incentives that may have inadvertently created more bloat in the UTXO set. From a963eca951fe0b14b207f93d2219f274faae0fba Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Mon, 8 Aug 2016 17:04:13 -0500 Subject: [PATCH 05/12] correct to empty scriptSig in P2WPKH --- segwit.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/segwit.asciidoc b/segwit.asciidoc index fc5a71d8..970bc200 100644 --- a/segwit.asciidoc +++ b/segwit.asciidoc @@ -91,7 +91,7 @@ However, to spend the segregated witness output, Bob’s transaction has an empt “Vin” : [ "txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2", "vout": 0, - "scriptSig": “”, + "scriptSig": “”, ] [....] “witness”: “” From d6dbaf758d9228f9bfd2a8f6f340934cdd191363 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Thu, 1 Sep 2016 14:50:59 -0400 Subject: [PATCH 06/12] segwit first draft done --- segwit.asciidoc | 145 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 127 insertions(+), 18 deletions(-) diff --git a/segwit.asciidoc b/segwit.asciidoc index 970bc200..b8d323a3 100644 --- a/segwit.asciidoc +++ b/segwit.asciidoc @@ -5,22 +5,19 @@ Will be merged later into chapter 6 or 7, as the book is reorganized //// - [[segwit]] === Segregated Witness -Segregated Witness is an upgrade to the bitcoin consensus rules and network protocol, scheduled for implementation in the second half of 2016. +Segregated Witness (segwit) is an upgrade to the bitcoin consensus rules and network protocol, scheduled for implementation in the second half of 2016. In cryptography, the term "witness" is used to describe a solution to a cryptographic puzzle. In bitcoin terms, the witness is the unlocking script that satisfies a cryptographic condition placed on a UTXO via the locking script. -In the context of bitcoin, a digital signature is _one type of witness_, but a witness is more broadly any script that can satisfy the conditions of a locking script and unlock a UTXO for spending. The terms “witness”, “unlocking script” and “scriptSig” all mean the same thing. +In the context of bitcoin, a digital signature is _one type of witness_, but a witness is more broadly any script that can satisfy the conditions of a locking script and unlock a UTXO for spending. The terms “witness”, “unlocking script” and “scriptSig” all mean the same thing. Before segwit’s introduction, every input in a transaction was followed by the witness data that unlocked it. The witness data was embedded in the transaction as part of each input, The term _segregated witness_ or _segwit_ for short, simply means separating the signature or unlocking script of a specific output. Think "separate scriptSig", or “separate signature” in the simplest form. Segregated Witness therefore is an architectural change to bitcoin that aims to move the scriptSig (unlocking script) outside of the transaction data structure and into separate a _witness_ data structure that accompanies a transaction. Clients may request transaction data with or without the accompanying witness data. - - In this section we will look at some of the benefits of segregated witness, describe the mechanism used to deploy and implement this architecture change and demonstrate the use of segregated witness in transactions and addresses. @@ -36,17 +33,17 @@ Network and Storage Scaling :: The witness data is often a big contributor to th ==== How Segregated Witness Works -At first glance, segregated witness appears to be a change to how transactions are constructed and therefore a transaction-level feature, but it is not. In fact, segregated witness is a change to how UTXO are constructed and therefore is a per-output feature. +At first glance, segregated witness appears to be a change to how transactions are constructed and therefore a transaction-level feature, but it is not. In fact, segregated witness is also a change to how UTXO are constructed and therefore is a per-output feature. -A transaction can spend segregated witness outputs or traditional inline-witness outputs or both. Therefore, it does not make much sense to refer to a transaction as a “segregated witness transaction”. Rather we should refer to specific outputs (UTXO) as “segregated witness outputs”. +A transaction can spend segregated witness outputs or traditional (inline-witness) outputs or both. Therefore, it does not make much sense to refer to a transaction as a “segregated witness transaction”. Rather we should refer to specific transaction inputs as “segregated witness inputs. -When a transaction spends a UTXO, it must provide a witness. In a traditional UTXO, the locking script requires that witness data be provided _inline_ in the input part of the transaction that spends the UTXO. A segregated witness UTXO, however, specifies a locking script that can be satisfied with witness data outside of the input (segregated). +When a transaction spends a UTXO, it must provide a witness. In a traditional UTXO, the locking script requires that witness data be provided _inline_ in the input part of the transaction that spends the UTXO. A segregated witness UTXO, however, specifies a locking script that can be satisfied with witness data outside of the input (segregated). ==== Soft-fork (backwards compatibility) -Segregated witness is a significant change to the way outputs and transactions are architected. Such a change would normally require a simultaneous change in every bitcoin node and wallet, to change the consensus rules with what is known as a hard fork. Instead, segregated witness is introduced with a much less disruptive change that is backwards compatible, known as a soft fork. This type of upgrade allows non-upgraded software to ignore the changes and continue to operate without any disruption, without changes to the consensus rules. +Segregated witness is a significant change to the way outputs and transactions are architected. Such a change would normally require a simultaneous change in every bitcoin node and wallet, to change the consensus rules -- what is known as a hard fork. Instead, segregated witness is introduced with a much less disruptive change, which is backwards compatible, known as a soft fork. This type of upgrade allows non-upgraded software to ignore the changes and continue to operate without any disruption. -Segregated witness outputs are constructed so that older systems that are not segregated-witness-aware can still validate them. To an old wallet or node, a segregated witness output looks like an output that _anyone can spend_ . Such outputs can be spent with an empty signature, therefore the fact that there is no signature inside the transaction (it is segregated), does not invalidate the transaction. Newer wallets & mining nodes however see the segregated witness output and expect to find a valid witness for it in the transaction’s witness data. +Segregated witness outputs are constructed so that older systems that are not segwit-aware can still validate them. To an old wallet or node, a segregated witness output looks like an output that _anyone can spend_. Such outputs can be spent with an empty signature, therefore the fact that there is no signature inside the transaction (it is segregated), does not invalidate the transaction. Newer wallets & mining nodes however see the segregated witness output and expect to find a valid witness for it in the transaction’s witness data. ==== Segregated Witness Output and Transaction Examples @@ -68,7 +65,7 @@ With segregated witness, a Pay-to-Public-Key-Hash output, is created instead a P 0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 ---- -As you can see, a segregated witness output’s locking script is much simpler than a traditional output. It consists of two values that are pushed on to the script evaluation stack. To an old (non-segwit-aware) bitcoin client, the two pushes would look like an output that anyone can spend and does not require a signature (or rather, can be spent with an empty signature). To a newer, segwit-aware client, the first number (0) is interpreted as a version number (the _witness version_) and the second part is the equivalent of a locking script known as a _witness program_. +As you can see, a segregated witness output’s locking script is much simpler than a traditional output. It consists of two values that are pushed on to the script evaluation stack. To an old (non-segwit-aware) bitcoin client, the two pushes would look like an output that anyone can spend and does not require a signature (or rather, can be spent with an empty signature). To a newer, segwit-aware client, the first number (0) is interpreted as a version number (the _witness version_) and the second part (20 bytes) is the equivalent of a locking script known as a _witness program_. The 20-byte witness program is simply the hash of the public key, as in a P2PKH script Now, let’s look at the corresponding transaction that Bob uses to spend this output. For the original script (non-segwit), Bob’s transaction would have to include a signature within the transaction input: @@ -83,7 +80,7 @@ Now, let’s look at the corresponding transaction that Bob uses to spend this o [...] ---- -However, to spend the segregated witness output, Bob’s transaction has an empty scriptSig and includes a segregated (separate) witness: +However, to spend the segregated witness output, the transaction has no signature on that input. Instead, Bob’s transaction has an empty scriptSig and includes a segregated witness, outside the transaction itself: .Decoded transaction showing a P2WPKH output being spent with separate witness data ---- @@ -93,30 +90,43 @@ However, to spend the segregated witness output, Bob’s transaction has an empt "vout": 0, "scriptSig": “”, ] -[....] +[...] “witness”: “” [...] ---- +[[p2wsh]] ===== Pay-to-Witness-Script-Hash (P2WSH) -In <> we saw our first example of a Pay-to-Script-Hash (P2SH) address used by Mohammed's company to express a multi-signature control script. Payments to Mohammed's company were encoded with a locking script like this: +The second type of witness program corresponds to a Pay-to-Script-Hash (P2SH) script. We saw this type of script in <>. In that example, P2SH was used by Mohammed's company to express a multi-signature script. Payments to Mohammed's company were encoded with a locking script like this: .Example P2SH output script ---- OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL ---- -The P2SH script above references the hash of a _redeem script_ that defines a 2-of-3 multi-signature requirement to spend funds. If Mohammed's customers were using a Segregated Witness compatible wallet, the equivalent payment would be to a Pay-to-Witness-Script-Hash (P2WSH) output script that would look like this: +The P2SH script above references the hash of a _redeem script_ that defines a 2-of-3 multi-signature requirement to spend funds. To spend this output, Mohammed's company would present the redeem script (whose hash matches the script hash in the P2SH output) and the signatures necessary to satisfy that redeem script, all inside the transaction input: + +.Decoded transaction showing a P2SH output being spent +---- +[...] +“Vin” : [ +"txid": "abcdef12345...", +"vout": 0, + "scriptSig": “SigA SigB 2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG”, +] +---- + +Now, let's look at how this entire example would be upgraded to segwit. If Mohammed's customers were using a segwit compatible wallet, they would make a payment, creating a Pay-to-Witness-Script-Hash (P2WSH) output that would look like this: .Example P2WSH output script ---- 0 54c557e07dde5bb6cb791c7a540e0a4796f5e97e ---- -Again, as with the example of P2WPKH, you can see that the segregated witness equivalent script is a lot simpler and omits the various script operands that you see in P2SH scripts. Instead, the segregated witness program consists only of a witness version (0) and the script hash. +Again, as with the example of P2WPKH, you can see that the segregated witness equivalent script is a lot simpler and omits the various script operands that you see in P2SH scripts. Instead, the segregated witness program consists of two values pushed to the stack: a witness version (0) and the 32-byte script hash. -Mohammed can spend the Pay-to-Witness-Script-Hash output by presenting the correct redeem script (whose hash matches the script hash in the witness program) and sufficient signatures to satisfy the redeem script. Both the redeem script and the signatures would be segregated _outside_ the spending transaction as part of the witness data. Within the spending transaction, Mohammed's wallet would put an empty scriptSig: +Mohammed's company can spend outputs the Pay-to-Witness-Script-Hash output by presenting the correct redeem script and sufficient signatures to satisfy the redeem script. Both the redeem script and the signatures would be segregated _outside_ the spending transaction as part of the witness data. Within the transaction input, Mohammed's wallet would put an empty scriptSig: .Decoded transaction showing a P2WSH output being spent with separate witness data ---- @@ -126,12 +136,111 @@ Mohammed can spend the Pay-to-Witness-Script-Hash output by presenting the corre "vout": 0, "scriptSig": “”, ] -[....] +[...] “witness”: “SigA SigB 2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG” [...] ---- +==== Upgrading to Segregated Witness +As we can see from the examples above, upgrading to segregated witness is a two-step process. First, wallets must create special segwit type outputs. Then, these outputs can be spent by wallets that know how to construct segregated witness transactions. In the examples above, Alice's wallet was segwit-aware and able to create special outputs with segregated witness scripts. Bob's wallet is also segwit-aware and able to spend those outputs. What may not be obvious from the example is that in practice, Alice's wallet needs to _know_ that Bob uses a segwit-aware wallet and can spend these outputs. Otherwise, if Bob's wallet is not upgraded and Alice tries to make segwit payments to Bob, Bob's wallet will not be able to detect these payments. + +[TIP] +==== +For P2WPKH and P2WSH payment types, both the sender and the recipient wallets need to be upgraded to be able to use segwit. Furthermore, the sender's wallet needs to know that the recipient's wallet is segwit-aware. +==== + +Segregated witness will not be implemented simultaneously across the entire network. Rather, segregated witness is implemented as a backwards compatible upgrade, where _old and new clients can coexist_. Wallet developers will independently upgrade wallet software to add segwit capabilities. The P2WPKH and P2WSH payment types are intended for when both sender and recipient are segwit-aware. The traditional P2PKH and P2SH will continue to work for non-upgraded wallets. That leaves two important scenarios which are addressed in the next section: + +* Ability of a sender's wallet that is not segwit-aware to make a payment to a recipient's wallet that can process segwit transactions. + +* Ability of a sender's wallet that is segwit-aware to recognize and distinguish between recipients that are segwit-aware and ones that are not, by their _addresses_. + +===== Embedding Segregated Witness Inside P2SH + +Let's assume, for example, that Alice's wallet is not upgraded to segwit, but Bob's wallet is upgraded and can handle segwit transactions. Alice and Bob can use "old" non-segwit transactions. But Bob would likely want to use segwit to reduce transaction fees, taking advantage of the discount that applies to witness data. + + In this case Bob's wallet can construct a P2SH address that contains a segwit script inside it. Alice's wallet sees this as a "normal" P2SH address and can make payments to it without any knowledge of segwit. Bob's wallet can then spend this payment with a segwit transaction, taking full advantage of segwit and reducing transaction fees. + +Both forms of witness scripts, P2WPKH and P2WSH, can be embedded in a P2SH address. The first is noted as P2SH(P2WPKH) and the second is noted as P2SH(P2WSH). + +===== Pay-to-Witness-Public-Key-Hash inside Pay-to-Script-Hash + +The first form of witness script we will examine is P2SH(P2WPKH). This is a Pay-to-Witness-Public-Key-Hash witness program, embedded inside a Pay-to-Script-Hash script, so that it can be used by a wallet that is not aware of segwit. + +Bob's wallet constructs a Pay-to-Witness-Public-Key-Hash (P2WPKH) witness program with Bob's public key. This witness program is then hashed and the resulting hash is encoded as a Pay-to-Script-Hash (P2SH) script. The P2SH script is converted to a bitcoin address, one which starts with a "3", as we saw in the <> section. + +Bob's wallet starts with the P2WPKH witness program we saw earlier: + +.Bob's P2WPKH witness program +---- +0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 +---- + +The P2WPKH witness program consists of the witness version and Bob's 20-byte public key hash. + +Bob's wallet then hashes the above witness program, first with SHA256, then with RIPEMD160, producing another 20-byte hash: + +.Hash of the P2WPKH witness program +---- +deadbeef +---- + +The hash of the witness program is then embedded in a P2SH script: +.P2SH script containing the hash of a P2WPKH witness program +---- +OP_HASH160 deadbeef OP_EQUAL +---- + +Finally, the P2SH script is converted to a P2SH bitcoin address: + +.P2SH address +---- +3deadbeef +---- + +Now, Bob can display this address for customers to pay for their coffee. Alice's wallet can make a payment to +3deadbeef+, just as it would to any other bitcoin address. Even though Alice's wallet has no support for segwit, the payment it creates can be spent by Bob with a segwit transaction. + +===== Pay-to-Witness-Script-Hash inside Pay-to-Script-Hash + +Similarly, a P2WSH witness program for a multisig script or other complicated script can be embedded inside a Pay-to-Script-Hash script and address, making it possible for any wallet to make payments that are segwit compatible. + +As we saw in <>, Mohammed's company is using segregated witness payments to multi-signature scripts. To make it possible for any client to pay his company, regardless of whether their wallets are upgraded for segwit, Mohammed's wallet can embed the P2WSH witness program inside a P2SH script. + +First, Mohammed's wallet creates the P2WSH witness program that corresponds to the multi-signature script: + +.Mohammed's wallet creates a P2WSH witness program +---- +0 54c557e07dde5bb6cb791c7a540e0a4796f5e97e +---- + +Then, the witness program is hashed with SHA256 and RIPEMD160, producing a new 20-byte hash: + +.The hash of the P2WSH witness program +---- +deadbeef +---- + +Next, Mohammed's wallet puts the hash into a P2SH script +.P2SH script containing the hash of a P2WSH witness program +---- +OP_HASH160 deadbeef OP_EQUAL +---- + +Finally, the wallet constructs a bitcoin address from this script: + +.P2SH bitcoin address +---- +3deadbeef +---- + +Now, Mohammed's clients can make payments to this address without any need to support segwit. Mohammed's company can then construct segwit transactions to spend these payments, taking advantage of segwit features including lower transaction fees. + +===== Segregated Witness addresses + +After segwit is deployed on the bitcoin network, it will take some time until wallets are upgraded. It is quite likely therefore that segwit will mostly be used embedded in P2SH, as we saw in the previous section, at least for several months. + +Eventually however, almost all wallets will be able to support segwit payments. At that time it will no longer be necessary to embed segwit in P2SH. It is therefore likely that a new form of bitcoin address will be created, one that indicates the recipient is segwit-aware and which directly encodes a witness program. There have been a number of proposals for a segregated witness address scheme, but none have been actively pursued at this time. ==== Economic Incentives for Segregated Witness From 436ec1af723cb9f02b5e34bf7be5504756770a61 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Sun, 11 Sep 2016 15:54:59 -0700 Subject: [PATCH 07/12] segwit P2SH encapsulation, TxID and WTxID, differentiating Misc corrections --- segwit.asciidoc | 67 ++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 52 insertions(+), 15 deletions(-) diff --git a/segwit.asciidoc b/segwit.asciidoc index b8d323a3..b83a7f53 100644 --- a/segwit.asciidoc +++ b/segwit.asciidoc @@ -25,7 +25,7 @@ In this section we will look at some of the benefits of segregated witness, desc Segregated witness is an architectural change that has several effects on the scalability, security, economic incentives and performance of bitcoin. -Transaction malleability :: By moving the witness outside the transaction, the transaction hash used as an identifier no longer includes the witness data. Since the witness data is the only part of the transaction that can be modified by a third party (see <>), removing it also removes the opportunity for transaction malleability attacks. With segregated witness, transaction hashes become immutable, which greatly improves the implementation of many other protocols that rely on advanced bitcoin transaction construction, such as payment channels, chained transactions and lightning networks. +Transaction malleability :: By moving the witness outside the transaction, the transaction hash used as an identifier no longer includes the witness data. Since the witness data is the only part of the transaction that can be modified by a third party (see <> and <>), removing it also removes the opportunity for transaction malleability attacks. With segregated witness, transaction hashes become immutable, which greatly improves the implementation of many other protocols that rely on advanced bitcoin transaction construction, such as payment channels, chained transactions and lightning networks. Script Versioning :: With the introduction of segregated witness scripts, every locking script is preceded by a _script version_ number, similar to how transactions and blocks have version numbers. The addition of a script version number allows the scripting language to be upgraded in a backwards compatible way (ie. using soft-fork upgrades), to introduce new script operands, syntax or semantics. The ability to upgrade the scripting language in a non-disruptive way will greatly accelerate the rate of innovation in bitcoin. @@ -49,6 +49,7 @@ Segregated witness outputs are constructed so that older systems that are not se Let’s look at some of our example transactions and see how they would change with segregated witness. We’ll first look at how a Pay-to-Public-Key-Hash (P2PKH) payment is transformed with segregated witness program. Then, we’ll look at the segregated witness equivalent for Pay-to-Script-Hash (P2SH) scripts. Finally, we’ll look at how both of the above segregated witness programs can be embedded inside a P2SH script. +[[p2wpkh]] ===== Pay-to-Witness-Public-Key-Hash (P2WPKH) In <>, Alice created a transaction to pay Bob for a cup of coffee. That transaction created a Pay-to-Public-Key-Hash (P2PKH) output with a value of 0.015 BTC that was spendable by Bob. The output’s script looks like this: @@ -121,10 +122,15 @@ Now, let's look at how this entire example would be upgraded to segwit. If Moham .Example P2WSH output script ---- -0 54c557e07dde5bb6cb791c7a540e0a4796f5e97e +0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73 ---- -Again, as with the example of P2WPKH, you can see that the segregated witness equivalent script is a lot simpler and omits the various script operands that you see in P2SH scripts. Instead, the segregated witness program consists of two values pushed to the stack: a witness version (0) and the 32-byte script hash. +Again, as with the example of P2WPKH, you can see that the segregated witness equivalent script is a lot simpler and omits the various script operands that you see in P2SH scripts. Instead, the segregated witness program consists of two values pushed to the stack: a witness version (0) and the 32-byte SHA256 hash of the redeem script. + +[TIP] +==== +While P2SH uses the 20-byte +RIPEMD160(SHA256(script))+ hash, the P2WSH witness program uses a 32-byte +SHA256(script)+ hash. This difference in the selection of the hashing algorithm is deliberate and used to differentiate between the two types of witness programs (P2WPKH and P2WSH) by the length of the hash. +==== Mohammed's company can spend outputs the Pay-to-Witness-Script-Hash output by presenting the correct redeem script and sufficient signatures to satisfy the redeem script. Both the redeem script and the signatures would be segregated _outside_ the spending transaction as part of the witness data. Within the transaction input, Mohammed's wallet would put an empty scriptSig: @@ -141,6 +147,15 @@ Mohammed's company can spend outputs the Pay-to-Witness-Script-Hash output by pr [...] ---- +===== Differentiating between P2WPKH and P2WSH + +In the previous two sections, we demonstrated two types of witness programs: <> and <>. Both types of witness programs consist of single byte version number followed by a longer hash. They look very similar, but are interpreted very differently: one is interpreted as a public key hash, which is satisfied by a signature and the other as a script hash, which is satisfied by a redeem script. The critical difference between them is the length of the hash: + +* The public key hash in P2WPKH is 20 bytes +* The script hash in P2WSH is 32 bytes + +This is the one difference that allows a wallet to differentiate between the two types of witness programs. By looking at the length of the hash, a wallet can determine what type of witness program this is, P2WPKH or P2WSH. + ==== Upgrading to Segregated Witness As we can see from the examples above, upgrading to segregated witness is a two-step process. First, wallets must create special segwit type outputs. Then, these outputs can be spent by wallets that know how to construct segregated witness transactions. In the examples above, Alice's wallet was segwit-aware and able to create special outputs with segregated witness scripts. Bob's wallet is also segwit-aware and able to spend those outputs. What may not be obvious from the example is that in practice, Alice's wallet needs to _know_ that Bob uses a segwit-aware wallet and can spend these outputs. Otherwise, if Bob's wallet is not upgraded and Alice tries to make segwit payments to Bob, Bob's wallet will not be able to detect these payments. @@ -181,22 +196,22 @@ The P2WPKH witness program consists of the witness version and Bob's 20-byte pub Bob's wallet then hashes the above witness program, first with SHA256, then with RIPEMD160, producing another 20-byte hash: -.Hash of the P2WPKH witness program +.HASH160 of the P2WPKH witness program ---- -deadbeef +660a5ab01c8468ac2e3cd58e9b17f8ba637867a4 ---- The hash of the witness program is then embedded in a P2SH script: .P2SH script containing the hash of a P2WPKH witness program ---- -OP_HASH160 deadbeef OP_EQUAL +OP_HASH160 660a5ab01c8468ac2e3cd58e9b17f8ba637867a4 OP_EQUAL ---- Finally, the P2SH script is converted to a P2SH bitcoin address: .P2SH address ---- -3deadbeef +3AzZFY4WJJZbVr2A6qBTbdkYRpMLbdg6gD ---- Now, Bob can display this address for customers to pay for their coffee. Alice's wallet can make a payment to +3deadbeef+, just as it would to any other bitcoin address. Even though Alice's wallet has no support for segwit, the payment it creates can be spent by Bob with a segwit transaction. @@ -207,41 +222,63 @@ Similarly, a P2WSH witness program for a multisig script or other complicated sc As we saw in <>, Mohammed's company is using segregated witness payments to multi-signature scripts. To make it possible for any client to pay his company, regardless of whether their wallets are upgraded for segwit, Mohammed's wallet can embed the P2WSH witness program inside a P2SH script. -First, Mohammed's wallet creates the P2WSH witness program that corresponds to the multi-signature script: +First, Mohammed's wallet creates the P2WSH witness program that corresponds to the multi-signature script, hashed with SHA256: .Mohammed's wallet creates a P2WSH witness program ---- -0 54c557e07dde5bb6cb791c7a540e0a4796f5e97e +0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73 ---- -Then, the witness program is hashed with SHA256 and RIPEMD160, producing a new 20-byte hash: +Then, the witness program itself is hashed with SHA256 and RIPEMD160, producing a new 20-byte hash, as used in traditional P2SH: -.The hash of the P2WSH witness program +.The HASH160 of the P2WSH witness program ---- -deadbeef +e3cca368764d7b32ed27a15b2e8d7d45d4edd2c6 ---- Next, Mohammed's wallet puts the hash into a P2SH script .P2SH script containing the hash of a P2WSH witness program ---- -OP_HASH160 deadbeef OP_EQUAL +OP_HASH160 e3cca368764d7b32ed27a15b2e8d7d45d4edd2c6 OP_EQUAL ---- Finally, the wallet constructs a bitcoin address from this script: .P2SH bitcoin address ---- -3deadbeef +3NTWTcFE88p26GTPoxcWef9Q5ncKt6CY2E ---- Now, Mohammed's clients can make payments to this address without any need to support segwit. Mohammed's company can then construct segwit transactions to spend these payments, taking advantage of segwit features including lower transaction fees. -===== Segregated Witness addresses +===== Segregated Witness Addresses After segwit is deployed on the bitcoin network, it will take some time until wallets are upgraded. It is quite likely therefore that segwit will mostly be used embedded in P2SH, as we saw in the previous section, at least for several months. Eventually however, almost all wallets will be able to support segwit payments. At that time it will no longer be necessary to embed segwit in P2SH. It is therefore likely that a new form of bitcoin address will be created, one that indicates the recipient is segwit-aware and which directly encodes a witness program. There have been a number of proposals for a segregated witness address scheme, but none have been actively pursued at this time. +[[segwit_txid]] +===== Transaction Identifiers + +One of the greatest benefits of Segregated Witness is that it eliminates third-party transaction malleability. + +Before segwit, transactions could have their signatures subtly modified by third parties, changing their transaction ID (hash) without changing any fundamental properties (inputs, outputs, amounts). This created opportunities for Denial-of-Service attacks as well as attacks against poorly written wallet software that assumed unconfirmed transaction-hashes were immutable. + +With the introduction of Segregated Witness, transactions have two identifiers, +txid+ and +wtxid+. The traditional transaction ID +txid+ is the double-SHA256 hash of the serialized transaction, without the witness data. A transaction +wtxid+ is the double-SHA256 hash of the new serialization format of the transaction with witness data. + +The traditional +txid+ is calculated in exactly the same way as with a non-segwit transaction. However, since the segwit transaction has empty scriptSig's in every input, there is no part of the transaction that can be modified by a third party. Therefore, in a segwit transaction, the +txid+ is immutable even when the transaction is unconfirmed. + +The +wtxid+ is like an "extended" ID, in that the hash also incorporates the witness data. If a transaction is transmitted without witness data, then the +wtxid+ and +txid+ are identical. Note than since the +wtxid+ includes witness data (signatures) and since witness data may be malleable, the +wtxid+ should be considered malleable until the transaction is confirmed. Only the +txid+ of a segwit transaction can be considered immutable and only if _all_ the inputs of the transaction are segwit inputs with empty scriptSig. + +[TIP] +==== +Segregated Witness transactions have two IDs: +txid+ and +wtxid+. The +txid+ is the hash of the transaction without the witness data and the +wtxid+ is the hash inclusive of witness data. The +txid+ of a transaction where all inputs are segwit inputs, is not susceptible to third-party transaction malleability +==== + +==== Segregated Witness' New Signing Algorithm + + + ==== Economic Incentives for Segregated Witness Bitcoin mining nodes and full nodes incur costs for the resources used to support the bitcoin network and the blockchain. As the volume of bitcoin transactions increases, so does the cost of resources (CPU, network bandwidth, disk space, memory). Miners are compensated for these costs through fees that are proportional to the size (in bytes) of each transaction. Non-mining full nodes are not compensated, so they incur these costs because they have a need to run an authoritative fully-validating full-index node, perhaps because they use the node to operate a bitcoin business. From 9b5f9d5e200bb056de199e26cd5d1696ce237862 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Sun, 11 Sep 2016 15:55:27 -0700 Subject: [PATCH 08/12] skeleton for timelocks and state channels --- state_channels.asciidoc | 18 ++++++++++++++++++ timelocks.asciidoc | 18 ++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 state_channels.asciidoc create mode 100644 timelocks.asciidoc diff --git a/state_channels.asciidoc b/state_channels.asciidoc new file mode 100644 index 00000000..a81661cf --- /dev/null +++ b/state_channels.asciidoc @@ -0,0 +1,18 @@ +//// + + +Will be merged later into chapter 6 or 7, as the book is reorganized + + +//// +[[state_channels]] +=== State Channels + +_State channels_, or _payment channels_ are a system of smart-contract based virtual channels that enable payments to be exchanged between two parties that do not need to trust each other, with settlement via transactions on the blockchain. + +In the simplest form, a state channel is made by constructing a sequence of time-locked transactions with incrementing value. This is a one-way state channel between two parties. A one-way channel like this is useful for making off-chain micro-payments in return for delivery of a metered service, such as streamed video or Wifi service. + +More complex state channels can be used to build bi-directional off-chain payments between two parties. These are useful for maintaining a running balance between two parties without having to commit transactions to the bitcoin blockchain. + +Finally, state channels can be linked together to form a routed multi-hop network of payments between multiple parties. Such a network can support a much higher volume of transactions, each of very small value (micro-payments), for much lower cost than the equivalent transactions on the bitcoin blockchain. Yet, the trust is entirely + diff --git a/timelocks.asciidoc b/timelocks.asciidoc new file mode 100644 index 00000000..8d1d9cdd --- /dev/null +++ b/timelocks.asciidoc @@ -0,0 +1,18 @@ +//// + + +Will be merged later into chapter 6 or 7, as the book is reorganized + + +//// +[[state_channels]] +=== Time Locks + +==== nLockTime + +==== CLTV + +==== CSV + +==== Smart Contracts Using Time Locks + From eb40a2afc1d607c1518a74c47a03fb7531f969ef Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Sun, 11 Sep 2016 20:37:45 -0700 Subject: [PATCH 09/12] added BIPs and links --- segwit.asciidoc | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/segwit.asciidoc b/segwit.asciidoc index b83a7f53..8ed0ff9c 100644 --- a/segwit.asciidoc +++ b/segwit.asciidoc @@ -20,6 +20,22 @@ Segregated Witness therefore is an architectural change to bitcoin that aims to In this section we will look at some of the benefits of segregated witness, describe the mechanism used to deploy and implement this architecture change and demonstrate the use of segregated witness in transactions and addresses. +Segregated Witness is defined by the following Bitcoin Improvement Proposals (BIPs): + +BIP141 :: The mail definition of Segregated Witness. https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki + +BIP143 :: Transaction Signature Verification for Version 0 Witness Program +https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki + +BIP144 :: Peer Services - New network messages and serialization formats +https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki + +BIP145 :: getblocktemplate Updates for Segregated Witness (for mining) +https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki + + + + ==== Why Segregated Witness? @@ -31,6 +47,10 @@ Script Versioning :: With the introduction of segregated witness scripts, every Network and Storage Scaling :: The witness data is often a big contributor to the total size of a transaction. More complex witness scripts such as multi-sig or payment channels scripts are very large and represent the majority (more than 75%) of the data in a transaction. By moving the witness data outside the transaction, segregated witness improves bitcoin’s scalability. Nodes can prune the witness data after validating the signatures, or ignore it altogether when doing simplified payment verification. The witness data doesn’t need to be transmitted to all nodes and does not need to be stored on disk by all nodes. +Signature Verification Optimization :: Segregated Witness upgrades the signature functions (OP_CHECKSIG, OP_CHECKMULTISIG etc), to reduce the algorithm's computational complexity. Before segwit, the algorithm used to produce a signature required a number of hash operations that was proportional to the size of the transaction. Data-hasing computations increased in O(n^2^) with respect to the number of signature operations, introducing a substantial computational burden on all nodes verifying the signature. With segwit, the algorithm is changed to reduce the complexity to O(n). + +Offline Signing Improvement :: Segregated Witness signatures incorporate the value (amount) referenced by each input in the hash that is signed. Previously, an offline signing device, such as a hardware wallet, would have to verify the amount of each input before signing a transaction. This was usually accomplished by streaming a large amount of data about the previous transactions referenced as inputs. Since the amount is now part of the commitment hash that is signed, an offline device does not need the previous transactions. If the amounts do not match (are misrepresented by a compromised online system), the signature will be invalid. + ==== How Segregated Witness Works At first glance, segregated witness appears to be a change to how transactions are constructed and therefore a transaction-level feature, but it is not. In fact, segregated witness is also a change to how UTXO are constructed and therefore is a per-output feature. @@ -277,7 +297,15 @@ Segregated Witness transactions have two IDs: +txid+ and +wtxid+. The +txid+ is ==== Segregated Witness' New Signing Algorithm +Segregated Witness modifies the semantics of the four signature verification functions (OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY), changing the way a transaction commitment hash is calculated. +Signatures in bitcoin transactions are applied on a _commitment hash_ which is calculated from the transaction data, locking specific parts of the data indicating the signer's commitment to those values. For example, in a simple SIGHASH_ALL type signature, the commitment hash includes all inputs and outputs. + +Unfortunately, the way the commitment hash was calculated introduced the possibility that a node verifying the signature can be forced to perform a significant number of hash computations. Specifically, the hash operations increase in O(n^2^) with respect to the number of signature operations in the transaction. An attacker could therefore create a transaction with a very large number of signature operations, causing the entire bitcoin network to have to perform hundreds or thousands of hash operations to verify the transaction. + +Segwit represented an opportunity to address this problem by changing the way the commitment hash is calculated. For segwit version 0 witness programs, signature verification occurs using an improved commitment hash algorithm as specified in Bitcoin Improvement Proposal 143 (BIP143). + +The new algorithm achieves two important goals. Firstly, the number of hash operations increases by a much more gradual O(n) to the number of signature operations, reducing the opportunity to create Denial-of-Service attacks with overly complex transactions. Secondly, the commitment hash now also includes the value (amounts) of each input as part of the commitment. This means that a signer can commit to a specific input value without needing to "fetch" and check the previous transaction referenced by the input. In the case of offline devices, such as hardware wallets, this greatly simplifies the communication between the host and the hardware wallet, removing the need to stream previous transactions for validation. A hardware wallet can accept the input value "as stated" by an untrusted host. Since the signature is invalid if that input value is not correct, the hardware wallet doesn't need to validate the value before signing the input. ==== Economic Incentives for Segregated Witness From c2f995ad1bb093a824caa4a7260572776fac2474 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Tue, 4 Oct 2016 15:32:27 +0200 Subject: [PATCH 10/12] chapter 5 "wallets" rewrite --- ch05.asciidoc | 159 ++++++++++++++++++++++++++++++-------------------- 1 file changed, 95 insertions(+), 64 deletions(-) diff --git a/ch05.asciidoc b/ch05.asciidoc index 8d1d1e4b..b2863913 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -1,22 +1,36 @@ [[ch05_wallets]] == Introduction -We will see how bitcoin wallets store collections of keys controlling many bitcoin addresses. +The word "wallet" is used to describe a few different things in bitcoin. At a high-level, a wallet is an application that severs as the primary user interface. The wallet controls access to a user's money, managing keys and addresses, tracking the balance, and creating and signing transactions. + +More narrowly, from a programmer's perspective, the word "wallet" refers to the data structure used to store and manage a user's keys. + +In this chapter we will look at the second meaning, where ((("wallets", id="ix_ch04-asciidoc23", range="startofrange")))wallets are containers for private keys, usually implemented as structured files or simple databases. === Wallets -((("wallets", id="ix_ch04-asciidoc23", range="startofrange")))Wallets are containers for private keys, usually implemented as structured files or simple databases. -Another method for making keys is((("deterministic key generation"))) _deterministic key generation_. Here you derive each new private key, using a one-way hash function from a previous private key, linking them in a sequence. As long as you can re-create that sequence, you only need the first key (known as a _seed_ or _master_ key) to generate them all. In this section we will examine the different methods of key generation and the wallet structures that are built around them. +A common misconception about bitcoin is that bitcoin wallets contain bitcoin. In fact, the wallet contains only keys. The "coins" are recorded in the blockchain on the bitcoin network. Users control the coins on the network by signing transactions with the keys in their wallets. In a sense, a bitcoin wallet is a _keychain_. [TIP] ==== -Bitcoin wallets contain keys, not coins. Each user has a wallet containing keys. Wallets are really keychains containing pairs of private/public keys (see <>). Users sign transactions with the keys, thereby proving they own the transaction outputs (their coins). The coins are stored on the blockchain in the form of transaction-ouputs (often noted as vout or txout).((("txout notation")))((("vout notation"))) +Bitcoin wallets contain keys, not coins. Wallets are really keychains containing pairs of private/public keys (see <>). ==== +There are two primary types of wallets, distinguished by whether the keys they contain are related to each other or not. + +The first type is _non-deterministic wallets_, where each key is independently generated from a random number. The keys are not related to each other. ((("Just a Bunch Of Keys (JBOK) wallets")))This type of wallet is also known as a JBOK wallet from the phrase "Just a Bunch Of Keys." + +((("deterministic key generation")))The second type of wallet is a _deterministic wallet_, where all the keys are derived from a single master key, known as the _seed_. All the keys in this type of wallet are related to each other and can be generated again if one has the original seed. There are a number of different _key derivation_ methods used in deterministic wallets. The most commonly used derivation method uses a tree-like structure and is known as a _hierarchical deterministic_ or _HD_ wallet. + [[random_wallet]] ==== Nondeterministic (Random) Wallets -((("nondeterministic wallets")))((("random wallets")))((("Type-0 nondeterministic wallet")))((("wallets","nondeterministic")))((("wallets","random")))In the first bitcoin clients, wallets were simply collections of randomly generated private keys. This type of wallet is called a _Type-0 nondeterministic wallet_. For example, the((("Just a Bunch Of Keys (JBOK) wallets"))) Bitcoin Core client pregenerates 100 random private keys when first started and generates more keys as needed, using each key only once. This type of wallet is nicknamed "Just a Bunch Of Keys," or JBOK, and such wallets are being replaced with deterministic wallets because they are cumbersome to manage, back up, and import. ((("backups","of random wallets")))((("random wallets","backing up")))The disadvantage of random keys is that if you generate many of them you must keep copies of all of them, meaning that the wallet must be backed up frequently. Each key must be backed up, or the funds it controls are irrevocably lost if the wallet becomes inaccessible. This conflicts directly with the principle of avoiding address re-use, by using each bitcoin address for only one transaction. Address re-use reduces privacy by associating multiple transactions and addresses with each other. A Type-0 nondeterministic wallet is a poor choice of wallet, especially if you want to avoid address re-use because that means managing many keys, which creates the need for frequent backups. Although the Bitcoin Core client includes a Type-0 wallet, using this wallet is discouraged by developers of Bitcoin Core. <> shows a nondeterministic wallet, containing a loose collection of random keys. +In the first bitcoin clients, wallets were collections of randomly generated private keys. For example, the original Bitcoin Core client pregenerates 100 random private keys when first started and generates more keys as needed, using each key only once. Such wallets are being replaced with deterministic wallets because they are cumbersome to manage, back up, and import. ((("backups","of random wallets")))((("random wallets","backing up")))The disadvantage of random keys is that if you generate many of them you must keep copies of all of them, meaning that the wallet must be backed up frequently. Each key must be backed up, or the funds it controls are irrevocably lost if the wallet becomes inaccessible. This conflicts directly with the principle of avoiding address re-use, by using each bitcoin address for only one transaction. Address re-use reduces privacy by associating multiple transactions and addresses with each other. A Type-0 nondeterministic wallet is a poor choice of wallet, especially if you want to avoid address re-use because that means managing many keys, which creates the need for frequent backups. Although the Bitcoin Core client includes a Type-0 wallet, using this wallet is discouraged by developers of Bitcoin Core. <> shows a nondeterministic wallet, containing a loose collection of random keys. + +[TIP] +==== +The use of non-deterministic wallets is discouraged for anything other than simple tests. They are simply to cumbersome to backup and use. Instead, use an industry standard based _hierarchical deterministic wallet_ with a _mnemonic_ backup. +==== [[Type0_wallet]] .Type-0 nondeterministic (random) wallet: a collection of randomly generated keys @@ -26,58 +40,6 @@ image::images/msbt_0408.png["non-deterministic wallet"] ((("deterministic wallets")))((("seeded wallets")))((("wallets","deterministic")))((("wallets","seeded")))Deterministic, or "seeded" wallets are wallets that contain private keys that are all derived from a common seed, through the use of a one-way hash function. The seed is a randomly generated number that is combined with other data, such as an index number or "chain code" (see <>) to derive the private keys. In a deterministic wallet, the seed is sufficient to recover all the derived keys, and therefore a single backup at creation time is sufficient. The seed is also sufficient for a wallet export or import, allowing for easy migration of all the user's keys between different wallet implementations. -[[mnemonic_code_words]] -==== Mnemonic Code Words - -((("deterministic wallets","mnemonic code words")))((("mnemonic code words")))((("seeded wallets","mnemonic code words")))Mnemonic codes are English word sequences that represent (encode) a random number used as a seed to derive a deterministic wallet. The sequence of words is sufficient to re-create the seed and from there re-create the wallet and all the derived keys. A wallet application that implements deterministic wallets with mnemonic code will show the user a sequence of 12 to 24 words when first creating a wallet. That sequence of words is the wallet backup and can be used to recover and re-create all the keys in the same or any compatible wallet application. Mnemonic code words make it easier for users to back up wallets because they are easy to read and correctly transcribe, as compared to a random sequence of numbers. - -Mnemonic codes are defined in((("BIP0039"))) Bitcoin Improvement Proposal 39 (see <>), currently in Draft status. Note that BIP0039 is one implementation of a mnemonic code standard. Specifically, there is a different standard, with a different set of words, used by the((("Electrum wallet")))((("mnemonic code words","Electrum wallet and"))) Electrum wallet and predating BIP0039. BIP0039 was introduced by the((("mnemonic code words","Trezor wallet and")))((("Trezor wallet"))) Trezor wallet and is incompatible with Electrum's implementation. However, BIP0039 has now achieved broad industry support across dozens of interoperable implementations and should be considered the de-facto industry standard. - -BIP0039 defines the creation of a mnemonic code and seed as a follows: - -1. Create a random sequence (entropy) of 128 to 256 bits. -2. Create a checksum of the random sequence by taking the first few bits of its SHA256 hash. -3. Add the checksum to the end of the random sequence. -4. Divide the sequence into sections of 11 bits, using those to index a dictionary of 2048 predefined words. -5. Produce 12 to 24 words representing the mnemonic code. - -<> shows the relationship between the size of entropy data and the length of mnemonic codes in words. - -[[table_4-5]] -.Mnemonic codes: entropy and word length -[options="header"] -|======= -|Entropy (bits) | Checksum (bits) | Entropy+checksum | Word length -| 128 | 4 | 132 | 12 -| 160 | 5 | 165 | 15 -| 192 | 6 | 198 | 18 -| 224 | 7 | 231 | 21 -| 256 | 8 | 264 | 24 -|======= - -The mnemonic code represents 128 to 256 bits, which are used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The resulting seed is used to create a deterministic wallet and all of its derived keys. - -Tables pass:[#table_4-6] and pass:[#table_4-7] show some examples of mnemonic codes and the seeds they produce. - -[[table_4-6]] -.128-bit entropy mnemonic code and resulting seed -|======= -| *Entropy input (128 bits)*| 0c1e24e5917779d297e14d45f14e1a1a -| *Mnemonic (12 words)* | army van defense carry jealous true garbage claim echo media make crunch -| *Seed (512 bits)* | 3338a6d2ee71c7f28eb5b882159634cd46a898463e9d2d0980f8e80dfbba5b0fa0291e5fb88 -8a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7 -|======= - -[[table_4-7]] -.256-bit entropy mnemonic code and resulting seed -|======= -| *Entropy input (256 bits)* | 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c -| *Mnemonic (24 words)* | cake apple borrow silk endorse fitness top denial coil riot stay wolf -luggage oxygen faint major edit measure invite love trap field dilemma oblige -| *Seed (512 bits)* | 3972e432e99040f75ebe13a660110c3e29d131a2c808c7ee5f1631d0a977fcf473bee22 -fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343 -|======= - [[hd_wallets]] ==== Hierarchical Deterministic Wallets (BIP0032/BIP0044) @@ -98,7 +60,7 @@ The second advantage of HD wallets is that users can create a sequence of public ===== HD wallet creation from a seed -((("hierarchical deterministic wallets (HD wallets)","creation from seeds")))((("seeded wallets","HD wallets")))HD wallets are created from a single((("root seeds"))) _root seed_, which is a 128-, 256-, or 512-bit random number. Everything else in the HD wallet is deterministically derived from this root seed, which makes it possible to re-create the entire HD wallet from that seed in any compatible HD wallet. This makes it easy to back up, restore, export, and import HD wallets containing thousands or even millions of keys by simply transferring only the root seed. The root seed is most often represented by a _mnemonic word sequence_, as described in the previous section <>, to make it easier for people to transcribe and store it. +((("hierarchical deterministic wallets (HD wallets)","creation from seeds")))((("seeded wallets","HD wallets")))HD wallets are created from a single((("root seeds"))) _root seed_, which is a 128-, 256-, or 512-bit random number. Everything else in the HD wallet is deterministically derived from this root seed, which makes it possible to re-create the entire HD wallet from that seed in any compatible HD wallet. This makes it easy to back up, restore, export, and import HD wallets containing thousands or even millions of keys by simply transferring only the root seed. The process of creating the master keys and master chain code for an HD wallet is shown in <>. @@ -128,28 +90,28 @@ The parent public key, chain code, and the index number are combined and hashed .Extending a parent private key to create a child private key image::images/msbt_0411.png["ChildPrivateDerivation"] -Changing the index allows us to extend the parent and create the other children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each parent key can have 2 billion children keys. +Changing the index allows us to extend the parent and create the other children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each parent key can have 2,147,483,647 (2^31^) children (2^31^ is half of the entire 2^32^ range available because the other half is reserved for a special type of derivation we will talk about later in this chapter) Repeating the process one level down the tree, each child can in turn become a parent and create its own children, in an infinite number of generations. ===== Using derived child keys -((("child key derivation (CKD) function","using")))((("child private keys","using")))((("security","child private keys and")))Child private keys are indistinguishable from nondeterministic (random) keys. Because the derivation function is a one-way function, the child key cannot be used to find the parent key. The child key also cannot be used to find any siblings. If you have the n~th~ child, you cannot find its siblings, such as the n–1 child or the n+1 child, or any other children that are part of the sequence. Only the parent key and chain code can derive all the children. Without the child chain code, the child key cannot be used to derive any grandchildren either. You need both the child private key and the child chain code to start a new branch and derive grandchildren. +((("child key derivation (CKD) function","using")))((("child private keys","using")))((("security","child private keys and")))Child private keys are indistinguishable from nondeterministic (random) keys. Because the derivation function is a one-way function, the child key cannot be used to find the parent key. The child key also cannot be used to find any siblings. If you have the n~th~ child, you cannot find its siblings, such as the n-1 child or the n+1 child, or any other children that are part of the sequence. Only the parent key and chain code can derive all the children. Without the child chain code, the child key cannot be used to derive any grandchildren either. You need both the child private key and the child chain code to start a new branch and derive grandchildren. So what can the child private key be used for on its own? It can be used to make a public key and a bitcoin address. Then, it can be used to sign transactions to spend anything paid to that address. [TIP] ==== -A child private key, the corresponding public key, and the bitcoin address are all indistinguishable from keys and addresses created randomly. The fact that they are part of a sequence is not visible, outside of the HD wallet function that created them. Once created, they operate exactly as "normal" keys. +A child private key, the corresponding public key, and the bitcoin address are all indistinguishable from keys and addresses created randomly. The fact that they are part of a sequence is not visible outside of the HD wallet function that created them. Once created, they operate exactly as "normal" keys. ==== ===== Extended keys ((("extended keys")))((("hierarchical deterministic wallets (HD wallets)","extended keys")))((("keys","extended")))As we saw earlier, the key derivation function can be used to create children at any level of the tree, based on the three inputs: a key, a chain code, and the index of the desired child. The two essential ingredients are the key and chain code, and combined these are called an _extended key_. The term "extended key" could also be thought of as "extensible key" because such a key can be used to derive children. -Extended keys are stored and represented simply as the concatenation of the 256-bit key and 256-bit chain code into a 512-bit sequence. There are two types of extended keys. An extended private key is the combination of a private key and chain code and can be used to derive child private keys (and from them, child public keys). An extended public key is a public key and chain code, which can be used to create child public keys, as described in <>. +Extended keys are stored and represented simply as the concatenation of the 256-bit key and 256-bit chain code into a 512-bit sequence. There are two types of extended keys. An extended private key is the combination of a private key and chain code and can be used to derive child private keys (and from them, child public keys). An extended public key is a public key and chain code, which can be used to create child public keys (*public only*), as described in <>. -Think of an extended key as the root of a branch in the tree structure of the HD wallet. With the root of the branch, you can derive the rest of the branch. The extended private key can create a complete branch, whereas the extended public key can only create a branch of public keys. +Think of an extended key as the root of a branch in the tree structure of the HD wallet. With the root of the branch, you can derive the rest of the branch. The extended private key can create a complete branch, whereas the extended public key can *only* create a branch of public keys. [TIP] ==== @@ -204,7 +166,7 @@ In simple terms, if you want to use the convenience of an extended public key to ===== Index numbers for normal and hardened derivation -((("hardened child key derivation","indexes for")))((("public child key derivation","indexes for")))The index number used in the derivation function is a 32-bit integer. To easily distinguish between keys derived through the normal derivation function versus keys derived through hardened derivation, this index number is split into two ranges. ((("child private keys","index numbers for")))Index numbers between 0 and 2^31^–1 (0x0 to 0x7FFFFFFF) are used _only_ for normal derivation. Index numbers between 2^31^ and 2^32^–1 (0x80000000 to 0xFFFFFFFF) are used _only_ for hardened derivation. Therefore, if the index number is less than 2^31^, that means the child is normal, whereas if the index number is equal or above 2^31^, the child is hardened. +((("hardened child key derivation","indexes for")))((("public child key derivation","indexes for")))The index number used in the derivation function is a 32-bit integer. To easily distinguish between keys derived through the normal derivation function versus keys derived through hardened derivation, this index number is split into two ranges. ((("child private keys","index numbers for")))Index numbers between 0 and 2^31^-1 (0x0 to 0x7FFFFFFF) are used _only_ for normal derivation. Index numbers between 2^31^ and 2^32^-1 (0x80000000 to 0xFFFFFFFF) are used _only_ for hardened derivation. Therefore, if the index number is less than 2^31^, that means the child is normal, whereas if the index number is equal or above 2^31^, the child is hardened. To make the index number easier to read and display, the index number for hardened children is displayed starting from zero, but with a prime symbol. The first normal child key is therefore displayed as 0, whereas the first hardened child (index 0x80000000) is displayed as pass:[0']. In sequence then, the second hardened key would have index 0x80000001 and would be displayed as 1', and so on. When you see an HD wallet index i', that means 2^31^+i. @@ -254,6 +216,75 @@ BIP0044 specifies the structure as consisting of five predefined tree levels: | m/44'/2'/0'/0/1 | The second private key in the Litecoin main account, for signing transactions |======= + +[[mnemonic_code_words]] +==== HD Seeds and Mnemonic Code Words + +Hierarchical deterministic wallets are a very powerful model for managing many keys and addresses. They also offer a single standard that is flexible enough to support many different applications such as: + +* Multi-currency wallets +* Multi-signature wallets +* Identity management systems +* Password management systems + +All these different applications can be build on different branches of a tree, while still being recoverable from a single common seed. + +The _HD wallet_ invention and standard was later augmented by another very important invention: a standardized way of creating seeds from a sequence of english words that are easy to transcribe, export and import across wallets. This is known as a _mnemonic_ and the standard is defined by BIP0039. Today, most bitcoin wallets (as well as wallets for other crypto-currencies) use this standard and can import and export seeds for backup and recovery using interoperable mnemonics. + +((("deterministic wallets","mnemonic code words")))((("mnemonic code words")))((("seeded wallets","mnemonic code words")))Mnemonics are word sequences that represent (encode) a random number used as a seed to derive a deterministic wallet. The sequence of words is sufficient to re-create the seed and from there re-create the wallet and all the derived keys. A wallet application that implements deterministic wallets with mnemonic words will show the user a sequence of 12 to 24 words when first creating a wallet. That sequence of words is the wallet backup and can be used to recover and re-create all the keys in the same or any compatible wallet application. Mnemonic words make it easier for users to back up wallets because they are easy to read and correctly transcribe, as compared to a random sequence of numbers. + +[TIP] +==== +Mnemonic words are often confused with "brainwallets". They are not the same. The primary difference is that a brainwallet consists of words chosen by the user, whereas menmonic words are created randomly by the wallet and presented to the user. This important difference makes mnemonic words much more secure, because humans are very poor sources of randomness. +==== + +Mnemonic codes are defined in((("BIP0039"))) Bitcoin Improvement Proposal 39 (see <>). Note that BIP0039 is one implementation of a mnemonic code standard. Specifically, there is a different standard, with a different set of words, used by the((("Electrum wallet")))((("mnemonic code words","Electrum wallet and"))) Electrum wallet and predating BIP0039. BIP0039 was introduced by the((("mnemonic code words","Trezor wallet and")))((("Trezor wallet"))) Trezor wallet and is incompatible with Electrum's implementation. However, BIP0039 has now achieved broad industry support across dozens of interoperable implementations and should be considered the de-facto industry standard. + +BIP0039 defines the creation of a mnemonic code and seed as a follows: + +1. Create a random sequence (entropy) of 128 to 256 bits. +2. Create a checksum of the random sequence by taking the first few bits of its SHA256 hash. +3. Add the checksum to the end of the random sequence. +4. Divide the sequence into sections of 11 bits, using those to index a dictionary of 2048 predefined words. +5. Produce 12 to 24 words representing the mnemonic code. + +<> shows the relationship between the size of entropy data and the length of mnemonic codes in words. + +[[table_4-5]] +.Mnemonic codes: entropy and word length +[options="header"] +|======= +|Entropy (bits) | Checksum (bits) | Entropy+checksum | Word length +| 128 | 4 | 132 | 12 +| 160 | 5 | 165 | 15 +| 192 | 6 | 198 | 18 +| 224 | 7 | 231 | 21 +| 256 | 8 | 264 | 24 +|======= + +The mnemonic words represent 128 to 256 bits, which are used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The resulting seed is used to create a deterministic wallet and all of its derived keys. + +Tables pass:[#table_4-6] and pass:[#table_4-7] show some examples of mnemonic codes and the seeds they produce. + +[[table_4-6]] +.128-bit entropy mnemonic code and resulting seed +|======= +| *Entropy input (128 bits)*| 0c1e24e5917779d297e14d45f14e1a1a +| *Mnemonic (12 words)* | army van defense carry jealous true garbage claim echo media make crunch +| *Seed (512 bits)* | 3338a6d2ee71c7f28eb5b882159634cd46a898463e9d2d0980f8e80dfbba5b0fa0291e5fb88 +8a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7 +|======= + +[[table_4-7]] +.256-bit entropy mnemonic code and resulting seed +|======= +| *Entropy input (256 bits)* | 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c +| *Mnemonic (24 words)* | cake apple borrow silk endorse fitness top denial coil riot stay wolf +luggage oxygen faint major edit measure invite love trap field dilemma oblige +| *Seed (512 bits)* | 3972e432e99040f75ebe13a660110c3e29d131a2c808c7ee5f1631d0a977fcf473bee22 +fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343 +|======= + ===== Experimenting with HD wallets using Bitcoin Explorer ((("hierarchical deterministic wallets (HD wallets)","Bitcoin Explorer and")))((("Bitcoin Explorer","HD wallets and")))Using the Bitcoin Explorer command-line tool introduced in <>, you can experiment with generating and extending BIP0032 deterministic keys, as well as displaying them in different formats((("Bitcoin Explorer","seed command")))((("seed command (bx)")))((("Bitcoin Explorer","hd-seed command")))((("hd-seed command (bx)")))((("Bitcoin Explorer","hd-public command")))((("hd-public command (bx)")))((("Bitcoin Explorer","hd-private command")))((("hd-private command (bx)")))((("Bitcoin Explorer","hd-to-address command")))((("hd-to-address command (bx)")))((("Bitcoin Explorer","hd-to-wif command")))((("hd-to-wif command (bx)"))): (((range="endofrange", startref="ix_ch04-asciidoc25b")))(((range="endofrange", startref="ix_ch04-asciidoc25a")))(((range="endofrange", startref="ix_ch04-asciidoc25")))(((range="endofrange", startref="ix_ch04-asciidoc24")))(((range="endofrange", startref="ix_ch04-asciidoc23"))) From 84c1ddb69b890c03c9e9c8b0600c82571ca3d9f5 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Wed, 5 Oct 2016 13:31:07 +0200 Subject: [PATCH 11/12] Revert "chapter 5 "wallets" rewrite" This reverts commit c2f995ad1bb093a824caa4a7260572776fac2474. --- ch05.asciidoc | 159 ++++++++++++++++++++------------------------------ 1 file changed, 64 insertions(+), 95 deletions(-) diff --git a/ch05.asciidoc b/ch05.asciidoc index b2863913..8d1d1e4b 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -1,36 +1,22 @@ [[ch05_wallets]] == Introduction -The word "wallet" is used to describe a few different things in bitcoin. At a high-level, a wallet is an application that severs as the primary user interface. The wallet controls access to a user's money, managing keys and addresses, tracking the balance, and creating and signing transactions. - -More narrowly, from a programmer's perspective, the word "wallet" refers to the data structure used to store and manage a user's keys. - -In this chapter we will look at the second meaning, where ((("wallets", id="ix_ch04-asciidoc23", range="startofrange")))wallets are containers for private keys, usually implemented as structured files or simple databases. +We will see how bitcoin wallets store collections of keys controlling many bitcoin addresses. === Wallets -A common misconception about bitcoin is that bitcoin wallets contain bitcoin. In fact, the wallet contains only keys. The "coins" are recorded in the blockchain on the bitcoin network. Users control the coins on the network by signing transactions with the keys in their wallets. In a sense, a bitcoin wallet is a _keychain_. +((("wallets", id="ix_ch04-asciidoc23", range="startofrange")))Wallets are containers for private keys, usually implemented as structured files or simple databases. +Another method for making keys is((("deterministic key generation"))) _deterministic key generation_. Here you derive each new private key, using a one-way hash function from a previous private key, linking them in a sequence. As long as you can re-create that sequence, you only need the first key (known as a _seed_ or _master_ key) to generate them all. In this section we will examine the different methods of key generation and the wallet structures that are built around them. [TIP] ==== -Bitcoin wallets contain keys, not coins. Wallets are really keychains containing pairs of private/public keys (see <>). +Bitcoin wallets contain keys, not coins. Each user has a wallet containing keys. Wallets are really keychains containing pairs of private/public keys (see <>). Users sign transactions with the keys, thereby proving they own the transaction outputs (their coins). The coins are stored on the blockchain in the form of transaction-ouputs (often noted as vout or txout).((("txout notation")))((("vout notation"))) ==== -There are two primary types of wallets, distinguished by whether the keys they contain are related to each other or not. - -The first type is _non-deterministic wallets_, where each key is independently generated from a random number. The keys are not related to each other. ((("Just a Bunch Of Keys (JBOK) wallets")))This type of wallet is also known as a JBOK wallet from the phrase "Just a Bunch Of Keys." - -((("deterministic key generation")))The second type of wallet is a _deterministic wallet_, where all the keys are derived from a single master key, known as the _seed_. All the keys in this type of wallet are related to each other and can be generated again if one has the original seed. There are a number of different _key derivation_ methods used in deterministic wallets. The most commonly used derivation method uses a tree-like structure and is known as a _hierarchical deterministic_ or _HD_ wallet. - [[random_wallet]] ==== Nondeterministic (Random) Wallets -In the first bitcoin clients, wallets were collections of randomly generated private keys. For example, the original Bitcoin Core client pregenerates 100 random private keys when first started and generates more keys as needed, using each key only once. Such wallets are being replaced with deterministic wallets because they are cumbersome to manage, back up, and import. ((("backups","of random wallets")))((("random wallets","backing up")))The disadvantage of random keys is that if you generate many of them you must keep copies of all of them, meaning that the wallet must be backed up frequently. Each key must be backed up, or the funds it controls are irrevocably lost if the wallet becomes inaccessible. This conflicts directly with the principle of avoiding address re-use, by using each bitcoin address for only one transaction. Address re-use reduces privacy by associating multiple transactions and addresses with each other. A Type-0 nondeterministic wallet is a poor choice of wallet, especially if you want to avoid address re-use because that means managing many keys, which creates the need for frequent backups. Although the Bitcoin Core client includes a Type-0 wallet, using this wallet is discouraged by developers of Bitcoin Core. <> shows a nondeterministic wallet, containing a loose collection of random keys. - -[TIP] -==== -The use of non-deterministic wallets is discouraged for anything other than simple tests. They are simply to cumbersome to backup and use. Instead, use an industry standard based _hierarchical deterministic wallet_ with a _mnemonic_ backup. -==== +((("nondeterministic wallets")))((("random wallets")))((("Type-0 nondeterministic wallet")))((("wallets","nondeterministic")))((("wallets","random")))In the first bitcoin clients, wallets were simply collections of randomly generated private keys. This type of wallet is called a _Type-0 nondeterministic wallet_. For example, the((("Just a Bunch Of Keys (JBOK) wallets"))) Bitcoin Core client pregenerates 100 random private keys when first started and generates more keys as needed, using each key only once. This type of wallet is nicknamed "Just a Bunch Of Keys," or JBOK, and such wallets are being replaced with deterministic wallets because they are cumbersome to manage, back up, and import. ((("backups","of random wallets")))((("random wallets","backing up")))The disadvantage of random keys is that if you generate many of them you must keep copies of all of them, meaning that the wallet must be backed up frequently. Each key must be backed up, or the funds it controls are irrevocably lost if the wallet becomes inaccessible. This conflicts directly with the principle of avoiding address re-use, by using each bitcoin address for only one transaction. Address re-use reduces privacy by associating multiple transactions and addresses with each other. A Type-0 nondeterministic wallet is a poor choice of wallet, especially if you want to avoid address re-use because that means managing many keys, which creates the need for frequent backups. Although the Bitcoin Core client includes a Type-0 wallet, using this wallet is discouraged by developers of Bitcoin Core. <> shows a nondeterministic wallet, containing a loose collection of random keys. [[Type0_wallet]] .Type-0 nondeterministic (random) wallet: a collection of randomly generated keys @@ -40,6 +26,58 @@ image::images/msbt_0408.png["non-deterministic wallet"] ((("deterministic wallets")))((("seeded wallets")))((("wallets","deterministic")))((("wallets","seeded")))Deterministic, or "seeded" wallets are wallets that contain private keys that are all derived from a common seed, through the use of a one-way hash function. The seed is a randomly generated number that is combined with other data, such as an index number or "chain code" (see <>) to derive the private keys. In a deterministic wallet, the seed is sufficient to recover all the derived keys, and therefore a single backup at creation time is sufficient. The seed is also sufficient for a wallet export or import, allowing for easy migration of all the user's keys between different wallet implementations. +[[mnemonic_code_words]] +==== Mnemonic Code Words + +((("deterministic wallets","mnemonic code words")))((("mnemonic code words")))((("seeded wallets","mnemonic code words")))Mnemonic codes are English word sequences that represent (encode) a random number used as a seed to derive a deterministic wallet. The sequence of words is sufficient to re-create the seed and from there re-create the wallet and all the derived keys. A wallet application that implements deterministic wallets with mnemonic code will show the user a sequence of 12 to 24 words when first creating a wallet. That sequence of words is the wallet backup and can be used to recover and re-create all the keys in the same or any compatible wallet application. Mnemonic code words make it easier for users to back up wallets because they are easy to read and correctly transcribe, as compared to a random sequence of numbers. + +Mnemonic codes are defined in((("BIP0039"))) Bitcoin Improvement Proposal 39 (see <>), currently in Draft status. Note that BIP0039 is one implementation of a mnemonic code standard. Specifically, there is a different standard, with a different set of words, used by the((("Electrum wallet")))((("mnemonic code words","Electrum wallet and"))) Electrum wallet and predating BIP0039. BIP0039 was introduced by the((("mnemonic code words","Trezor wallet and")))((("Trezor wallet"))) Trezor wallet and is incompatible with Electrum's implementation. However, BIP0039 has now achieved broad industry support across dozens of interoperable implementations and should be considered the de-facto industry standard. + +BIP0039 defines the creation of a mnemonic code and seed as a follows: + +1. Create a random sequence (entropy) of 128 to 256 bits. +2. Create a checksum of the random sequence by taking the first few bits of its SHA256 hash. +3. Add the checksum to the end of the random sequence. +4. Divide the sequence into sections of 11 bits, using those to index a dictionary of 2048 predefined words. +5. Produce 12 to 24 words representing the mnemonic code. + +<> shows the relationship between the size of entropy data and the length of mnemonic codes in words. + +[[table_4-5]] +.Mnemonic codes: entropy and word length +[options="header"] +|======= +|Entropy (bits) | Checksum (bits) | Entropy+checksum | Word length +| 128 | 4 | 132 | 12 +| 160 | 5 | 165 | 15 +| 192 | 6 | 198 | 18 +| 224 | 7 | 231 | 21 +| 256 | 8 | 264 | 24 +|======= + +The mnemonic code represents 128 to 256 bits, which are used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The resulting seed is used to create a deterministic wallet and all of its derived keys. + +Tables pass:[#table_4-6] and pass:[#table_4-7] show some examples of mnemonic codes and the seeds they produce. + +[[table_4-6]] +.128-bit entropy mnemonic code and resulting seed +|======= +| *Entropy input (128 bits)*| 0c1e24e5917779d297e14d45f14e1a1a +| *Mnemonic (12 words)* | army van defense carry jealous true garbage claim echo media make crunch +| *Seed (512 bits)* | 3338a6d2ee71c7f28eb5b882159634cd46a898463e9d2d0980f8e80dfbba5b0fa0291e5fb88 +8a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7 +|======= + +[[table_4-7]] +.256-bit entropy mnemonic code and resulting seed +|======= +| *Entropy input (256 bits)* | 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c +| *Mnemonic (24 words)* | cake apple borrow silk endorse fitness top denial coil riot stay wolf +luggage oxygen faint major edit measure invite love trap field dilemma oblige +| *Seed (512 bits)* | 3972e432e99040f75ebe13a660110c3e29d131a2c808c7ee5f1631d0a977fcf473bee22 +fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343 +|======= + [[hd_wallets]] ==== Hierarchical Deterministic Wallets (BIP0032/BIP0044) @@ -60,7 +98,7 @@ The second advantage of HD wallets is that users can create a sequence of public ===== HD wallet creation from a seed -((("hierarchical deterministic wallets (HD wallets)","creation from seeds")))((("seeded wallets","HD wallets")))HD wallets are created from a single((("root seeds"))) _root seed_, which is a 128-, 256-, or 512-bit random number. Everything else in the HD wallet is deterministically derived from this root seed, which makes it possible to re-create the entire HD wallet from that seed in any compatible HD wallet. This makes it easy to back up, restore, export, and import HD wallets containing thousands or even millions of keys by simply transferring only the root seed. +((("hierarchical deterministic wallets (HD wallets)","creation from seeds")))((("seeded wallets","HD wallets")))HD wallets are created from a single((("root seeds"))) _root seed_, which is a 128-, 256-, or 512-bit random number. Everything else in the HD wallet is deterministically derived from this root seed, which makes it possible to re-create the entire HD wallet from that seed in any compatible HD wallet. This makes it easy to back up, restore, export, and import HD wallets containing thousands or even millions of keys by simply transferring only the root seed. The root seed is most often represented by a _mnemonic word sequence_, as described in the previous section <>, to make it easier for people to transcribe and store it. The process of creating the master keys and master chain code for an HD wallet is shown in <>. @@ -90,28 +128,28 @@ The parent public key, chain code, and the index number are combined and hashed .Extending a parent private key to create a child private key image::images/msbt_0411.png["ChildPrivateDerivation"] -Changing the index allows us to extend the parent and create the other children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each parent key can have 2,147,483,647 (2^31^) children (2^31^ is half of the entire 2^32^ range available because the other half is reserved for a special type of derivation we will talk about later in this chapter) +Changing the index allows us to extend the parent and create the other children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each parent key can have 2 billion children keys. Repeating the process one level down the tree, each child can in turn become a parent and create its own children, in an infinite number of generations. ===== Using derived child keys -((("child key derivation (CKD) function","using")))((("child private keys","using")))((("security","child private keys and")))Child private keys are indistinguishable from nondeterministic (random) keys. Because the derivation function is a one-way function, the child key cannot be used to find the parent key. The child key also cannot be used to find any siblings. If you have the n~th~ child, you cannot find its siblings, such as the n-1 child or the n+1 child, or any other children that are part of the sequence. Only the parent key and chain code can derive all the children. Without the child chain code, the child key cannot be used to derive any grandchildren either. You need both the child private key and the child chain code to start a new branch and derive grandchildren. +((("child key derivation (CKD) function","using")))((("child private keys","using")))((("security","child private keys and")))Child private keys are indistinguishable from nondeterministic (random) keys. Because the derivation function is a one-way function, the child key cannot be used to find the parent key. The child key also cannot be used to find any siblings. If you have the n~th~ child, you cannot find its siblings, such as the n–1 child or the n+1 child, or any other children that are part of the sequence. Only the parent key and chain code can derive all the children. Without the child chain code, the child key cannot be used to derive any grandchildren either. You need both the child private key and the child chain code to start a new branch and derive grandchildren. So what can the child private key be used for on its own? It can be used to make a public key and a bitcoin address. Then, it can be used to sign transactions to spend anything paid to that address. [TIP] ==== -A child private key, the corresponding public key, and the bitcoin address are all indistinguishable from keys and addresses created randomly. The fact that they are part of a sequence is not visible outside of the HD wallet function that created them. Once created, they operate exactly as "normal" keys. +A child private key, the corresponding public key, and the bitcoin address are all indistinguishable from keys and addresses created randomly. The fact that they are part of a sequence is not visible, outside of the HD wallet function that created them. Once created, they operate exactly as "normal" keys. ==== ===== Extended keys ((("extended keys")))((("hierarchical deterministic wallets (HD wallets)","extended keys")))((("keys","extended")))As we saw earlier, the key derivation function can be used to create children at any level of the tree, based on the three inputs: a key, a chain code, and the index of the desired child. The two essential ingredients are the key and chain code, and combined these are called an _extended key_. The term "extended key" could also be thought of as "extensible key" because such a key can be used to derive children. -Extended keys are stored and represented simply as the concatenation of the 256-bit key and 256-bit chain code into a 512-bit sequence. There are two types of extended keys. An extended private key is the combination of a private key and chain code and can be used to derive child private keys (and from them, child public keys). An extended public key is a public key and chain code, which can be used to create child public keys (*public only*), as described in <>. +Extended keys are stored and represented simply as the concatenation of the 256-bit key and 256-bit chain code into a 512-bit sequence. There are two types of extended keys. An extended private key is the combination of a private key and chain code and can be used to derive child private keys (and from them, child public keys). An extended public key is a public key and chain code, which can be used to create child public keys, as described in <>. -Think of an extended key as the root of a branch in the tree structure of the HD wallet. With the root of the branch, you can derive the rest of the branch. The extended private key can create a complete branch, whereas the extended public key can *only* create a branch of public keys. +Think of an extended key as the root of a branch in the tree structure of the HD wallet. With the root of the branch, you can derive the rest of the branch. The extended private key can create a complete branch, whereas the extended public key can only create a branch of public keys. [TIP] ==== @@ -166,7 +204,7 @@ In simple terms, if you want to use the convenience of an extended public key to ===== Index numbers for normal and hardened derivation -((("hardened child key derivation","indexes for")))((("public child key derivation","indexes for")))The index number used in the derivation function is a 32-bit integer. To easily distinguish between keys derived through the normal derivation function versus keys derived through hardened derivation, this index number is split into two ranges. ((("child private keys","index numbers for")))Index numbers between 0 and 2^31^-1 (0x0 to 0x7FFFFFFF) are used _only_ for normal derivation. Index numbers between 2^31^ and 2^32^-1 (0x80000000 to 0xFFFFFFFF) are used _only_ for hardened derivation. Therefore, if the index number is less than 2^31^, that means the child is normal, whereas if the index number is equal or above 2^31^, the child is hardened. +((("hardened child key derivation","indexes for")))((("public child key derivation","indexes for")))The index number used in the derivation function is a 32-bit integer. To easily distinguish between keys derived through the normal derivation function versus keys derived through hardened derivation, this index number is split into two ranges. ((("child private keys","index numbers for")))Index numbers between 0 and 2^31^–1 (0x0 to 0x7FFFFFFF) are used _only_ for normal derivation. Index numbers between 2^31^ and 2^32^–1 (0x80000000 to 0xFFFFFFFF) are used _only_ for hardened derivation. Therefore, if the index number is less than 2^31^, that means the child is normal, whereas if the index number is equal or above 2^31^, the child is hardened. To make the index number easier to read and display, the index number for hardened children is displayed starting from zero, but with a prime symbol. The first normal child key is therefore displayed as 0, whereas the first hardened child (index 0x80000000) is displayed as pass:[0']. In sequence then, the second hardened key would have index 0x80000001 and would be displayed as 1', and so on. When you see an HD wallet index i', that means 2^31^+i. @@ -216,75 +254,6 @@ BIP0044 specifies the structure as consisting of five predefined tree levels: | m/44'/2'/0'/0/1 | The second private key in the Litecoin main account, for signing transactions |======= - -[[mnemonic_code_words]] -==== HD Seeds and Mnemonic Code Words - -Hierarchical deterministic wallets are a very powerful model for managing many keys and addresses. They also offer a single standard that is flexible enough to support many different applications such as: - -* Multi-currency wallets -* Multi-signature wallets -* Identity management systems -* Password management systems - -All these different applications can be build on different branches of a tree, while still being recoverable from a single common seed. - -The _HD wallet_ invention and standard was later augmented by another very important invention: a standardized way of creating seeds from a sequence of english words that are easy to transcribe, export and import across wallets. This is known as a _mnemonic_ and the standard is defined by BIP0039. Today, most bitcoin wallets (as well as wallets for other crypto-currencies) use this standard and can import and export seeds for backup and recovery using interoperable mnemonics. - -((("deterministic wallets","mnemonic code words")))((("mnemonic code words")))((("seeded wallets","mnemonic code words")))Mnemonics are word sequences that represent (encode) a random number used as a seed to derive a deterministic wallet. The sequence of words is sufficient to re-create the seed and from there re-create the wallet and all the derived keys. A wallet application that implements deterministic wallets with mnemonic words will show the user a sequence of 12 to 24 words when first creating a wallet. That sequence of words is the wallet backup and can be used to recover and re-create all the keys in the same or any compatible wallet application. Mnemonic words make it easier for users to back up wallets because they are easy to read and correctly transcribe, as compared to a random sequence of numbers. - -[TIP] -==== -Mnemonic words are often confused with "brainwallets". They are not the same. The primary difference is that a brainwallet consists of words chosen by the user, whereas menmonic words are created randomly by the wallet and presented to the user. This important difference makes mnemonic words much more secure, because humans are very poor sources of randomness. -==== - -Mnemonic codes are defined in((("BIP0039"))) Bitcoin Improvement Proposal 39 (see <>). Note that BIP0039 is one implementation of a mnemonic code standard. Specifically, there is a different standard, with a different set of words, used by the((("Electrum wallet")))((("mnemonic code words","Electrum wallet and"))) Electrum wallet and predating BIP0039. BIP0039 was introduced by the((("mnemonic code words","Trezor wallet and")))((("Trezor wallet"))) Trezor wallet and is incompatible with Electrum's implementation. However, BIP0039 has now achieved broad industry support across dozens of interoperable implementations and should be considered the de-facto industry standard. - -BIP0039 defines the creation of a mnemonic code and seed as a follows: - -1. Create a random sequence (entropy) of 128 to 256 bits. -2. Create a checksum of the random sequence by taking the first few bits of its SHA256 hash. -3. Add the checksum to the end of the random sequence. -4. Divide the sequence into sections of 11 bits, using those to index a dictionary of 2048 predefined words. -5. Produce 12 to 24 words representing the mnemonic code. - -<> shows the relationship between the size of entropy data and the length of mnemonic codes in words. - -[[table_4-5]] -.Mnemonic codes: entropy and word length -[options="header"] -|======= -|Entropy (bits) | Checksum (bits) | Entropy+checksum | Word length -| 128 | 4 | 132 | 12 -| 160 | 5 | 165 | 15 -| 192 | 6 | 198 | 18 -| 224 | 7 | 231 | 21 -| 256 | 8 | 264 | 24 -|======= - -The mnemonic words represent 128 to 256 bits, which are used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The resulting seed is used to create a deterministic wallet and all of its derived keys. - -Tables pass:[#table_4-6] and pass:[#table_4-7] show some examples of mnemonic codes and the seeds they produce. - -[[table_4-6]] -.128-bit entropy mnemonic code and resulting seed -|======= -| *Entropy input (128 bits)*| 0c1e24e5917779d297e14d45f14e1a1a -| *Mnemonic (12 words)* | army van defense carry jealous true garbage claim echo media make crunch -| *Seed (512 bits)* | 3338a6d2ee71c7f28eb5b882159634cd46a898463e9d2d0980f8e80dfbba5b0fa0291e5fb88 -8a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7 -|======= - -[[table_4-7]] -.256-bit entropy mnemonic code and resulting seed -|======= -| *Entropy input (256 bits)* | 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c -| *Mnemonic (24 words)* | cake apple borrow silk endorse fitness top denial coil riot stay wolf -luggage oxygen faint major edit measure invite love trap field dilemma oblige -| *Seed (512 bits)* | 3972e432e99040f75ebe13a660110c3e29d131a2c808c7ee5f1631d0a977fcf473bee22 -fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343 -|======= - ===== Experimenting with HD wallets using Bitcoin Explorer ((("hierarchical deterministic wallets (HD wallets)","Bitcoin Explorer and")))((("Bitcoin Explorer","HD wallets and")))Using the Bitcoin Explorer command-line tool introduced in <>, you can experiment with generating and extending BIP0032 deterministic keys, as well as displaying them in different formats((("Bitcoin Explorer","seed command")))((("seed command (bx)")))((("Bitcoin Explorer","hd-seed command")))((("hd-seed command (bx)")))((("Bitcoin Explorer","hd-public command")))((("hd-public command (bx)")))((("Bitcoin Explorer","hd-private command")))((("hd-private command (bx)")))((("Bitcoin Explorer","hd-to-address command")))((("hd-to-address command (bx)")))((("Bitcoin Explorer","hd-to-wif command")))((("hd-to-wif command (bx)"))): (((range="endofrange", startref="ix_ch04-asciidoc25b")))(((range="endofrange", startref="ix_ch04-asciidoc25a")))(((range="endofrange", startref="ix_ch04-asciidoc25")))(((range="endofrange", startref="ix_ch04-asciidoc24")))(((range="endofrange", startref="ix_ch04-asciidoc23"))) From c3c911e1eb222bc15ddd4a0c783556a4673dfcb5 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Wed, 5 Oct 2016 13:34:20 +0200 Subject: [PATCH 12/12] Revert "skeleton for timelocks and state channels" This reverts commit 9b5f9d5e200bb056de199e26cd5d1696ce237862. --- state_channels.asciidoc | 18 ------------------ timelocks.asciidoc | 18 ------------------ 2 files changed, 36 deletions(-) delete mode 100644 state_channels.asciidoc delete mode 100644 timelocks.asciidoc diff --git a/state_channels.asciidoc b/state_channels.asciidoc deleted file mode 100644 index a81661cf..00000000 --- a/state_channels.asciidoc +++ /dev/null @@ -1,18 +0,0 @@ -//// - - -Will be merged later into chapter 6 or 7, as the book is reorganized - - -//// -[[state_channels]] -=== State Channels - -_State channels_, or _payment channels_ are a system of smart-contract based virtual channels that enable payments to be exchanged between two parties that do not need to trust each other, with settlement via transactions on the blockchain. - -In the simplest form, a state channel is made by constructing a sequence of time-locked transactions with incrementing value. This is a one-way state channel between two parties. A one-way channel like this is useful for making off-chain micro-payments in return for delivery of a metered service, such as streamed video or Wifi service. - -More complex state channels can be used to build bi-directional off-chain payments between two parties. These are useful for maintaining a running balance between two parties without having to commit transactions to the bitcoin blockchain. - -Finally, state channels can be linked together to form a routed multi-hop network of payments between multiple parties. Such a network can support a much higher volume of transactions, each of very small value (micro-payments), for much lower cost than the equivalent transactions on the bitcoin blockchain. Yet, the trust is entirely - diff --git a/timelocks.asciidoc b/timelocks.asciidoc deleted file mode 100644 index 8d1d9cdd..00000000 --- a/timelocks.asciidoc +++ /dev/null @@ -1,18 +0,0 @@ -//// - - -Will be merged later into chapter 6 or 7, as the book is reorganized - - -//// -[[state_channels]] -=== Time Locks - -==== nLockTime - -==== CLTV - -==== CSV - -==== Smart Contracts Using Time Locks -