From ce40c0f8f02e83892eb185aabea306ee2a3ab10e Mon Sep 17 00:00:00 2001 From: genjix Date: Sat, 29 Oct 2011 11:39:58 +0100 Subject: [PATCH] BIP 0001, 0011, 0012, 0013. --- bip-0001-1.png | Bin 0 -> 20813 bytes bip-0001.txt | 172 +++++++++++++++++++++++++++++++++++++++++++++++++ bip-0011.txt | 57 ++++++++++++++++ bip-0012.txt | 84 ++++++++++++++++++++++++ bip-0013.txt | 52 +++++++++++++++ 5 files changed, 365 insertions(+) create mode 100644 bip-0001-1.png create mode 100644 bip-0001.txt create mode 100644 bip-0011.txt create mode 100644 bip-0012.txt create mode 100644 bip-0013.txt diff --git a/bip-0001-1.png b/bip-0001-1.png new file mode 100644 index 0000000000000000000000000000000000000000..51eb2b25826c3f97b38a4fa17425a86d27c0d962 GIT binary patch literal 20813 zcma%@1ymg0w&n}>;7)*GA-D#2_u%gC5Q2pOjRYrHaEIXT?(V@oKyVKpe2V|Q_szUn zZ`PV#D@li{ZmLh6v(Mh&_uC!%K~V|~nFtvG05lnCaTNf7h6kVTAVPzGzX@8>1OI`w z6j2ZXfJNAq>Lu{UEt}ZWyx{O!|Pyyxz zxK8kid?7>~8a|-QsMIL_pCj~I)Gx>Tku{JAP~iir{Qv(BBL?vYOzi41Bmg*Yo5-Kf zVZjeRQf)=~Y5mN@L-f0mUk3jju?;Sa(<&kzWf8Gh32bOp?UxfcgchqLa#zjn_R zlg`e;19%OjH)s;dg}&q%h_KLyBfoKAEErsFPV`Bmf)C)Ur?SvG8G~3Sr2li`7s1Sd zO{A})3Ffz71P{h`Rs4=9_t# za+CFDKSG&R#6AQ6DsM6o40e4P?NSe0ud&dC!_WOU$!_oIEMh0IY2=eIUf9pO^gbvVRspzJVf; z++wcwes}Y|ff@#Q3NC&CGe0=yqPeU`hzhBIaG6F6iE@eh@UT4qc$%Y~mdRn?(~bP< zhnrSWUzyOQSvw@DSU1?RdR(ewbnUYN0N1nf{JM88)Ll#;jIz))X8?f9wRYZmf$Qdr zfdB*E$jzFskoVoEH5y`;%g>xZBjy`m-hmzX>G|p2@#)b0;c^)n+*C-1WJ5$JBVbL%DLjOasq$Sr_tww-q&c2k08! zmPG6JNK^GbCDT^4ZZ0cHKTmte88W3Fa>fc|)r$J)0NS$K`}47PfYH%$>%+7?`CD1+ zP2pvq)@*H<8|gUJxZl)3r&UFUfa^)Ht~Vwo%Nw5rI|qt`ZNj>F=I7k<4`_hX;j?Ya z0x2%%STUQjtMD|&m9)vj-W~yO*XG$P5^f{5hfy<;*~$4pztkm;dS$0@YBcuKuW$} z#AlD;?*vt1o7D|@CR0aWfJTp}FJ5X9UBXg*g0U=%8k7-jj0F?5tBo+gO|Pu#?%O6e zs))AZf)2a(VlD}B`G~gN0h`^;H(~NLB^4DDgM(SLvL&-8zuLTRPFC41MhC~n#)gNH zT?14uA<&AxZ8e7pP!1~7*fb~rWYR#*FxxMUP9b8Z-uKMBCLjGIH2sNef@)c_#;HK)-TBc#kLSU70eM`)mEWf|M zuXyutIj!V-IVlAnU>uG0Io(vs9%@*^U~ag&`Qx&e)6EoT9d&sHRZD#JYmND4(uBkk z`@|a(1}C49^C|e{*=Dw)!$Wv&k>uv!dIR6Nx+h3&?c(R!t1OoTa>u>O3Z|K&YJM(H ztC5d$DJdy;_lD;K_>tb=WnEocw&azBpSyj3 z2=sA_F{X0n%FACNG=IAOEvge_lUg3{)yFn)KyJHNtq~y7i#SrvFq?t~1jv;^Sh|}r z>*@Sv7Xm{_kZfH&>z6AOHFQoXt|ymE^RzUMDV}_%`MSR>4ZVAUg8@|1#O7$g`x)Wvu zPafVb8o?Fvvg541a-AF8oKn~56{xMUdSsXS-ts3I^N*e#qe%Giov*TRF|b0nuI3Ge ze4koXksg&%CkVFEMXgJMwtK&}lC)7P?r5#axn->K(H~@KC(NQ!NNTxV76w*wkU#+t za*CzqZJR_!q2;=Rp}h*hcgcyi3-|pi>~8^br6M0&5fhT>WfczJYei0B^Q(qaMj4Hn z{VB!af*&P-8Fj&T;!Fwx3`B<$9hSTgaO8~pHjCVT`B2i%EX^UO?f2y$XmOCgQpC`* zv0*(%hP*s5kiY&w^Ai?sHvRLcI87ZYo|7vTC3v&qvOAt$v*vq$ZEwaTt*AIYGNM~= zx7g^sDd}N&hoZ5jYTcDkI|L1cB&QnE(KD$*sad|h@0p^0k6rO3s-Qu=^gSV+_j_V2 zIg8EmI6YUzV;B{b@cm?}_FRwWcJNar+Z)NOwqJ9VUM^y=NWc;bnR(90cAmYuBb794 z#P#obJ?kp0@3&;N3_{VPZ5q}x%R>)VDRYlM%2)NZ^vd8rShhEo>@IWBhBbTo%zyX% z3VfLQseU;M8wSs&VwdSu-VMdQTN7|%(Zj4^?n$`NYs3+{Z z2VhjrC3v5eK3$`!rlFA&YWwrZVz2JpqgBLzS-awk`su$`woDw2z~klgTcwOo0wUmg zU#zj5$Pjp0??XdKuISWW9fs+L8%IIqZPv~v+<&gi`_RiZp*y#iaUfb4P%K#lgbLS` zN}m*^udzN4!|zd>X->Aw~2nd;hirfLKnRDK@?SF5-O-+TF~+vAK(;Yds}EV~RZQNFXCL;X|EsdrkX zS7!S9;K!=ATFDi|tw@-;bxOWfig`;}(a10d!?KQrK%VfTxo@^yJTYmH*R&rs1%(MX zG8o8hu-0Ag>Y8VvT+#cg(;B0BZm?wU8Aa?S7FB95jEJ|J2)fz=$(`G-#B7%jiwwC7 ztvoYY*BbQ60YEv70s)MP^$qnTk6Y_q>9PROczzMhO6@>|31vQ=ufQDh#FBWAifK_`t0rLc{@Pn+iJi3{?s9?=}F=pS97smX89*U zkv4nHX-S-ViwpFGgq?9$_Jh(6H^N!}Soe>sXtM09nq}_a`2^VJuNu7(rZ?uOM;gBG z(qD8bY$-o0?d(Kpmb%B_%9u6%AcX>yZ&uL(;5^aX*#VgwTBE`sl16d&;CLS@zrB_}<7RGD*-=hluAC7Sft=ijqAK z?p7IVCro3|#0}ZKPnFNFvz;du^7)b_7bv>X{S~FAx|)rRje>%r_5Mh=#JxG3t}Ylw zmy#@r4(>zGjEsYjT`Z0q)C>@J;_8()wbJ~xe#_JIhL4neg+u-uQ6;>`Z)(|n2W>}j zx{1`|q}DDYkH1h*fEI4KitVK{gQ|~@VCICBTi@W|Ab3G!b7-1sbhFpT%d4cZ(o_|# z=dxgYh*J{WzxW~*I4%x@Do4Fg@z9Jps_y>s&jDKX_BxM2&0me% z+FMn0^unf-9JS{(R>0r=%6Q`_!M`oT1HlqbP}i$^H+0Mc|2kzy_@q1!>wTdb z-Bz$oN8G?>US3`{Mm-oJ{mNf+MqsjHO=a6){-_BKsA{O$Df_;ktRcZjU#7=lR){q1 ziPbh3s~V~6f<;9UThb=>9xhkFhVdITK@fQTcYC=}Y1cw$z1Y4Fn`A95ElL^u$*HM) zD&Bz8)q-L4q_jp#A_*m4=rLyK=B^{1=qsLh+<^+{5X(GD6#MPF*xYim%)c>jV?-Kw z-5)0vxyW`sSZ!MAFTxH;&}~z%k8PVA=69pM?fK64UzZj2fi-eE+hn%=>4&$JxgQRS zyY&i&W-iksaXA@Lg^zM+>&0%b9a=meyQ$RBobN8J-+Hr{_D38qH@LgI=VH`XWuZ$_ zNp^=tYaj*JC)%yG!&Mmvm^crQ4$4ed*J}%K{_sQ)TK>-ei7ob2UD?mmKE( zHbp0e$kxqX<_*p0$e6%I-0HF>>Ft)d-0p12F{3LzMS<>S@kKp@lby?!w&;kAdShU5 zx}f*xE`K;_GHI$l`BG9Y?J@GqS}*W zNFN%pIqa^&B~+Hq+QL<%1Jmm!s@&%ppPtPzU91%z8Y>ah5;D9_cs@me<0LF1;ujZi zyG~7_VL-%0KFIU8lT<%`jI5|syQkVNxEgWA*!4JTDQu-LC#UM z(#vdL=@TZ^-Uthvh1c6GDdG;j?hv!CckO3W?w)hxEErC|5_Mb39qgr)(Xd(~N@GeK zLa|A0nWIAEUQgB3Syu44{PS})dwtj`!` zI8%7Yt);VG+|)anZTpEEETxT&H%@(@?``MHU-P*!fHiCcsyOD}q!hZ|I$|)k^weEG z&U(zc5uy2+VT^lK)?@gnQg|Hsc_=Ia*{lAO0Q@ff{3#nwz`BOQTu*R>8J~}^*5g>$$6{gLx zO~clVz?~DCaR>og#O%j2{x&6|$^KNH)ne)1-rn=m>9fyXcJRqcld871=kEAxoH81` zaPThh8F#}*N~#(dl+Pc=_!et1Xwc$-$?k6EOWpb$aSdkq6*_fc#Pro#49CaEl*wCk zovxH0Jg6n1QA9Ax%E}D9a=*^B{l$$DpJKj(H3?mAn$=^%8VHe8HOhgZh}q-nxK*f> zV?`A=8Om}LqY5RIuR?lx9;QTv5n>uth;K3^Tyu!h8w+6qF2QN~aapxM@v-9hjyX@I z$$SLw-i6d--EX!;)AxGOvg3aB^yo$@jobO^V79KV4qSz`YtQ|}j#+4=QM+q0=sma< zz0z8&Zfel*?8OVU*4QE#{G^T#f6tg(|3Cu_y7ltp7%NRK2!K`sZg?NK(IEq^59cEs z3WuLGTAH;O4C?I&0S5i%%ahd>-t?1~+6z<#0=)Q=FrZ3cQ9&g$Cs>gBhgQ8^a+@;% z^hXjm*v!&tZbGye+=$h*_NO|(lVA^n3L@d*-p^7TO;Pi% z<4$()H1GoPhtJ1o=y93oh31u9KWOS}6Wvc0pt z{SGJ0Z(M}lGP@%DzF&09)KnXfaixD2tyVsD(T+4SjxZ2UPj}3Rkn@zTzgWGb*QCmE z6RW$y!Q)&#h#R~XQcsd9h7lJia|j;nP5oBJ)b#WPsGA7gAJu^R+#h!XzgFgxI<)Wj zpX*i(UnQ7}iO^@6Wc_xogI-k&@x9Ik?gz#H zU2lt^Jm*ZYjV49jA(KeA#!`i5@XUWd%W?Qi$@J#Sp(HsqBokEDKnXU>Q~9SCE+VY- ztP`>j3%X*F8gyq2r4%%VY3K<(OR>Y?@Ia90qZ$fXfyrG@_+vh_^I&Cfhcstc!08yxQD=?UW1w|8wJ=t!K1u8Dc;>1uIQPnSQD-_meEE zxvQGtfDiers9>gJmDZ>Qdtj?K`HILfQh6VQF4Wz%hs+siLzm0I`$|1j{QN}~6Ndg9 z8Z(2Yl$(g;FMN*Tim#O*(S-c9yRfhj6UWEu6`A0u{qt3YuY%&Wk@FZP1XLn#;ND+} z#cq*%I>R7k=c8k+Br3&H(NXC%y<6BO!sbpk7cDjsUYLsn-$I#XGj86sM>W1PIW)R> zR}ESw)<@rV$cp0$e9LX0x!GC!wf5ICDnfp0(3unHokS`bTjoNruWi=&5o`jS#I&qx zkv27dPVexZQ4$(l(;I7YIjprmE?Q=`T~5hu@NG^@9|TF!K`mx`yeIQyBCgafZDnXg zAQAlX7fg9U`L)5p8%#*U@tLm;zongD9C~|Z;BzG%UE+x%kVaWnX*HgpGyn|!72G`d zA5}WTe>~tM0vp;~pzc*^JxvqPRcYK4WR%z^2TrvhV{YhF#7)VhuIKR-gjXa^OEtdF zPl*PfhkSX0zGKsAl8)z1tVx`|QdD-%L$h)2$5UMEzz1iOALY>jyiUO0csk$4Vc_tF z#Ofal8nyCCH;eZZpiERq%EEwL zVRaWez^Xt8lK;|ub99gF^SjdzraVEaX7S6Pb&+RtA|`u6)PBvCcJF&7-@CZBuXyYh zNIX5Y0{7R)#B)BV@SAX8gfTWS_ytB9f+PPx*e7CbBotA1r1XS@gzIa!hTs{SE1{>e zC~&^{{Nm6^X!FoOLR%6`-IxrjmDF;qy!OX@NBB{|m591mbxTobmY4rexi%B;y zO4xu2!o#lbQ-L&zN&tLh73N|ekl!6HEQw}j46cYGqUH&>1i0Ct*x!7s3=XN zvz`*Q|81#GU2%2w$Jt`_E+%PdmX{Yedk}u5bh-n8lcrr#K)B|^o3cu$jqaCmy}bO( zEDXg?mCX~-O#mg}nYrKygOLb9!UvV#4R9nWVnU`7j8u^}`y<7KVl>EQrYfM2linD! zia-P4D$+T_V2!=u?l0RV@DiPLQq$DbG&G#phiUkcpYQW@y9*}D$XZ1#Nzu?{?jtOy z1;kp8UUsG{pHF%T$h5)RFqtQp_!4%zuArcs-qbZTfO_%YO2ET|5F76&#~2GLmosk) zyx#~KG88mv^~0KI@mv3qnf2%dS0FXGeVDObU0s3k zGRPQQ<(s1h3;YA6R}c569hyaIihKw}+R8<0YrfCkSz&k_m9m{i-B_SU!;660lf@Z% zY*|KzXZoJW`0jH5>({S}I$g(uVX}FjFUGhElrl+wp2NYEVzDGu!oGtk_l4lCZtAH8 z_i1I!T7szx3O>`PWBP?$l_ESQy`TF9O)4m*-bzCgHUtNQ%R z5NwOtQ&x=wj0gs7cB9p$h)tS4v3*1@k}JaiwV9DQJRe{G?kt1l)Vo0d3uU}6P@l{33s+ZDkV|4k&@$sy@q(>d4jgc6yLaWt7Z1W03 zoi<2U69CrpyYR8!FE#WBm7p#yEgeb84t&%TwX?I+(IJvhPSa@gx?#G(--ijynVOn1 zF*Oa)n}a~qyBEIx%N60_xdpe)7Eo*ZFpOdR$jn?JprxVn{cWO-JMH}LQ zeL=NO(Te9@IQe0dA7-wvS#))W^JYIdClb@rzHIiRd1k|svS#lZk+8X=*fP>`e~ z0!1>X-3Yi!S%T?7vugJ>@0;U>wU=ZM97Qcn&H4Fx{J@Wc_!WB9Usm(WaHZOhZD>XA z)xO5}uvN-?+ORH3#|mzZRI|>fcCSRw&d-C>wgFra!K9z}Uf$?t)!m#;yAlOgl>hnR z0xJ~OPGNTH^lfuH zURqdK7#$tGyZfB|!2|R{O3~B6;$5r#3(rzM?EzRu08ZyyGC$A(qucXs(QFp0Z4`z# z_-!Pg`q%$d|D)(j*;9bl+l#p8bv>HI`r=N3))WhkT8l;F*>#!U1p9S;n&7nC<||+Y zn_eM3lWL=wCHMI61`%2(e=GszK}XL2Wk9$q6M$l-rb1ad5rCl>qL9Wz&&mX^uTy2B z;=>7iaep%LLjB1hE)Yw=e9dppQs0o~@U&BmL_yQv_te<2)KkDJ3QB;=`uc5-Ywe(b z`)!$!kWkyu@Kl2=VzCkSTUuHgc&(@(IUwdp?+qsU{(`0t5deCy?l^c$dXAS!z&-4(f-2% z;C=X`1>KK)K+kOr7v6`37!Z3NFpJz5h8u2)6?1W3rm*kNSfN8Q5zW2`SBO=;!VGQJOxkNsBUVSl-x~$0L$b^ocPlv|N=x>2wED@J`He)Bjyj zyv-qVvfhaS-`^0&jz>2zu7kCQ_w9BfC{3MkoOY8x!t`o=lUpY!q-UvbMxA_Yi-#XD6J&WGivy=JqILgBgFPS zTFYJxqdyv(i$(~0wUrs)>;xfxbS9LDUtOs)lFddI)|r~Ec7|4fi8iTv`;IuuVHLs= z#L@Eb$3UW$07&XTmQz7Nm|-{gQ{nq~*c*y1n|J=QuW!|YwaFc5)4963f*(0NGEyJ( zPye26f)ny_Bbe-?fg~tRTXmp^;~RjX6dweOZ4rR@AD&hhmT`uNXSBqJM-URCs>u_m25QKxs^>Pidh>0WuIsh?Uej?DHe+k zB`&e0@;%kOu1!}<8fYWcHmR!x#gX9Q9NH9fFU9zUsrky3nmGpZJb?gwB?AY?eL`OI z^s?FyGuuvYu$bCeN!q}fMztTwXKQXwJyH$MCWo6Sb5JZz%aDFqD%H3VJjhicUGHp&S2leJjWPTd9L=c@*pKkS|8t@0-uzwmB)`7v; zGMD?Ur}PICtd1^rCvJWuviLqdyp(?p4ft1BKV<<>`<*?!x^4?(Z4m{e6crV{z1yZU z$m6N4jN&om`=iKSDp=SSoJVk<0yVo90je131ZKmGxVVd6Y^A?~rmsH$6e6RsWdrfi z3~TxDkWp)D{UZ%3m3OO*CHgX;!t349QwJZgv4Nm>z?#=&ex)0`yUk+&1f>QIDMMrR zssNmwKfENyHPQQjzHe z8h(8wl0&R(#z$t*sg8ObhhVX7lV8zId^C;6Wju|C&+X{%^4e29m`G#4Ra{u^Rfe5g zryL~!K&J}~IlHaO18UsR2-n=*K;tw5=;AC?nS$Qr4Y(C0fW~>JBc+3>YkZyB;l;O{ zqHh$rAH4L`lXRy~$RDo$kxF znEk*O9WVLoDDwknK$q||M+)^aY3`(!u5M~fOxNy3ZcYw-sCG{!Lkl?Wz{?G(MyC$Sd3>j>F2_rC5aJL3=pE!7aHWA${@wDvN;lnbDhCci(1)oY))a@D zi2HrkjaD;M9}56vszs;gK5P+C)5PJ=ymv2?!GZxout3U!XFH9?tUw?P`uaDXJ)f>a z1?~^)D8)-!bBsKDha+CE%1(udlm+@V0_Q6XYDsa7E+Qsx0AF&sU%OyP)Ch8Y5D8ylW%cqbT?X(Q(Wu<6%#86Us zB?0~CmnT0d@wmQyX5R`d%-oz_zy|S0Fx8KE6=A4$B&9n^RX*E=z{wM!A6A7Zf&l_u zPX&h@Apww0ES6lrG@W9K_Y}iy;&ZQeIB5VOWs*FNU?w^MD?*MrW{-;GChBS-kH#E@ zCthTWo@2Z+rJ5INY&Fzn^aW92nkFtZ-3PaXE?ne4p<)C#0` zcBmF=|6&s zKfPhz0plTumJ!FqFB}=|wLXcl?8?lZRga51Wv4SzQcPzxLl4W~W@HX+SPrPbMZ>w^ zpp;_xRemLRmW7raxsjd*;jY5t#7zwl9k)rzkTUw9PRBexcJ>9AfAkL+?=}TiAh<+>Sjb;tMOaXKb}yu~T{t;5&OE4O zK)uON7}7c}Kq88YFV6u-4h>-R;kRn)@Rwi!mz4D-fwcae>mm|`U>3%TuzMY9Q4 z#o&cY(Bhome%ZQ&|4VpB$PtRB(hq81T0fNM=*Yg3ujeKTm z3JG%+->0*JWyoA%mNn5}VQ_(bC?>k#F_Ozw_oBls?s2M<)C;felP!ZY10zbZPUU&SFW1f}LPs6y{yG{=vE zP6W?>8Sl9=gy@13ZyXG~H+&jz19Xah2Y#L`zP%=uddZR*@SBPm4$lILZ!!6+E}M6`accJ4Ns@^Dn`?q2Lz{Yy{m|BC zl8WD-)~G%BmSujEQqLgGSYL!%BrkZCpt7$rZ1fToD8FLM4Ep;$nLMD~)G9OkO=EPG zziJmRD=jZAt)E7KD-)nTb34{L{u)&pmop-_%mLCnwUYWEQSf2M_ooS&IXR>C;r{-~ ziG!^J?U3a3PBFXT$}FGooTvG)!|SnXwL_6ZklVUSoD6yrjZ`3$9#O1QW{^`Qx>}@b zy7Y;K1&*a0b*@CL#fZnM8RQz?$pL_{wu%cBkW}J&QFih?V|yQ5 zrJpn!^yaQJd0nRhSXn`^Ls43B`OEsJCK3Rc`5Mg3D^(D)NmgdFSE$usRjmbpTX!>b zItu38#@fhR^z6u~nz!?LR3QK?h0O1jG|Dv%s!$+8lPFq1#>Yut2bv`!#xGE!q?C8# z=d%sejI1r!4`ENW7_6vzIP4SepDhJjs+Ir5tRv1`1|wwbPs1hgVdBoGea+@m^0+|Z zoRW%sK3&3soq+s}`k|4_KS}N3vAze1WZu7N38+qSK0f*I-_sv|Ljkq(%ew8{I_=No zv42bsMa%CTpUR(mfy)h|F0K;|d5iH((wefbZ`vVYP5NR55 zk#k-e=b^J#=I0zuL;xMT99wfelW6Ss7hGZd`|kGYsYlsHzVXKy$hp0fuhPzExwDkT zWfFua`|*k`7}Y$$CW&{bY#J-C#k|f%X4|voHHtY40jZBL0C?{;sMrQZhbYy+ym%hi z2O+=lIXS-bCmEmu%Ug%rDU?H40LELY>?%`FWo?OSuLhNy8oYfkFZj{YhO=)kqpU%;)kYx#`&$iUq}*vDEF;dnL9?gP`Hsg6c&O$7%Mwo)*ZA+2 z_^CJ_Xo-ioI25iu;oEet-T89Wg2;khKv}rcjg4gi9{E`xgBt4Wd(Tf{IXmL2a&o2$ zeF-@J3+~G3{;(2Fbsw~+b8(k#Q$X1(YR*pihq#j57_MPBu=Msw&QMRECwE zb<@v}DqqEBMKNEt&_LR_=~wF83KM0pkgJ;c$CeY}SSn9V7tbpY*#un89h$`|AtAMi zj>9XT3I?m8ue`$bsMmX?$Y4G|7rNwO3r1g03>51LDK!~<*0?!dNviD`&aplRS?c0p z26f;3aBFxV7RQ&tv2a`y8c@UIg=dkEzyOmzTzA^kf+2PAG*NZhzLE`tms`guJ$0~x zy)k8>Fz7jdAcQ>I@z}u#kpE*RhizSt7nA=x_ak!JdtXsopZY`|!}pCX;u`>Itj!6+ zvL&_Q+=^f5CIHOfh_QNse;d_2=Eze=Qg3sd4*y9kJ!3YF!LV*0{1JCp6{n+6dEU9Q zw(|@O1gxl1|JmuS=yr?}O&CNm zU{f3t?n9xISd%bcnj)|h{*~~#q1Z1~G=@6U@Gih1V*k)hm*KDZ(DCCrW@Zx))61K*IYWI$>}wzW~v?a3=LvEnjN?9ZQNcX<w+&?NDLccSHF`maoP}fqe@TP9FCd ze}2bbPu7M;UOT>-YG>8z+$=7G(%N!0gFjPg1Z{Vl-8R&Ko~O-mY_D17_n%N~Ga7Y7 z)a3WLu?mQaipKHljz?sC!NF0l!Oza|U;O1Q3wS5r;dgh_^f)t$_bP z`d8O-3d;*!Sn?{d?RppQ#6c^ub;ZXb<*-0VvZjAz#4sEmz`ifU5k`xSb;{Idn@?@e z*%^%-nB_97;xY%5e;gqYP>&t~%{%g0xmc>tJB1r3#srj4`DuhrtW2%ZLuLctUXOqj z+&>s%qBIpKC`=3udHxQ4+p5S8219F~IwGUpgo$4|)kVJDEXSIB?!~Va%a{Zn2ez%< zEWa3h8Hx`m7hNBos8A|j2@eJM zOs^q7TmcU`9XGU#f=UT0l)}2_qnK2Vkw5L*G_1F|6Xt&NM7X#z#PqobY{s}7*(v#~ zD&E_>;N?^5Cb;BzTd*vw_?@QTul~_PtOouhhNgg~Pws_>7w|e*L2tODpfD1BU|3uc zX9ZZ6+^%q8gw>8Hk=$-smr4%k8wStN-}Wz$?m8SiV`Y$ytC#I#hg-imlC9 zbN_%H;VzSIbcx1dym;}El{U`A6-z{9%UnS@nH_G)2w6o&odI0*>d!Q7LEUl2-gy0A z5BH4;*87LAl_qTG)TmINn(XH6I00c9^p-`M@nlLz#i3GIh#jXZM7N=B``Kaw z7Rd%G(%TKt0P;A$;qsa4*dXTj1z)|qBBzn5WUyfUKEY_f`*jVO?KWlgD;5&aOVf)> zN-mw&YB9W6cge|BRaGFz^azqh0`dy64`9-fC1N1}dF=cs(nW#<@lf=0l_*Nj^qxfl zI%}WvFoyba%vX}wWdsocfCB3PCryxmpbi<>@`S68uberzrq;CIIm~B7xx4aHqe*OG zvW7E*9j@eERU`w1Z;o}Zmgig240!IxcyqaL1F#4I0LS->h^@esms>bz$w9{#=h^0I z59fwsQp0pF!%MY8hj?URx`~klZC|_sNB$+AnX({+FM?#+EPLtZ|=pHjR}4)&2BWWN4`8-F^W`UG9JG{(~la9WbgHm(c4BGqO!@ z26hzs9o2DGvXcSG^c{L!?oCg2j9A%=+ZBzU^PxL`vxU*MG}(527sZ9t{wOiugiV1b z?=z`HksK79y(;+5joGRD?7+#Y-!37NM(|I4&@Ml9t{RN{?hNSEbNq7Mr54|E1Y|wf z%@@DT?YR44W>9W?O6)R`20-}p?#kdoo#h?nCLb30W`X$Gwe|+HUnRC#TA<72J`7jP#o2un>?o@=W*N#lgpi=>#<|Y)C7p$b0*? z6)KC1i}!-WyYZj9X%G-cOpL$T(w2W&TQW<83J>nh&NMUYvgTc|7|g$LNadU?KocLxn%?)< zkA`$#VS$*$Zhc~>@tT}gjm4NzXg|OCYcq}Qi9|W&IGzd?mygecaf$dlxR&bBgE+|0w zL~+hbd^5o^Mlc#zz0R68H8hlXFzMkS0s8&|e3cA^^Jjx1F}lUC6aB{4QAo<*w)Q_M z^S|w-T~_GdPxAwI9>>=B+O!@!b!aP5M|3wZBMu=!8~sUrf?;~<@s6hswIgerW=Z35 zpyCuApJua?5=V|1gIOS@+bb2yyt5P(Eys?vx?n3FI+3sxlT8+ZV)((ERN0*ub)-cRQJ z&TQdZt~i(+v#Ufi2`H6!h@1@fsvFLK_k&vQVGa$XWnP_tCOJsjgMk12-JPTfIZ;GX z!TVh(0LRY98e+UT#GK83J~!&(9<*sUZ?b5su_^Do)4D(9dCRB1nt?}M-Y6Ez|EwPW z_55-M%nZidUI`oycv`3_Uy1|32TcnFato|299syKT7hEfd+%rSOUnItSLrTXd!6o~ zC)it^AGFBtJ8Za`U(qbXv(G4^(y$oCv*d$72MB9`zVbNOg&=7`P6VrbV4DY=<4&M8 zLOVRTR15*bI7JQ$M}?M{#>DoKy0yo4O>IL4Dc5`Av9;Gi6oXG3(y8Wed54?-cd5fE zu0Ud6_Y{q(3;<5P-)m&vl^2RxA3_(3XnauV)ebdNpLptSCS-S%BL&Plc-IvF%Eiv( zLJ42nq8y`{{vfy&=J6o$BUl{{FyUW^Ao0T<+HVb(RJ4Cy@AP{i6Sbx zyLXFysO(EV>gtmFFn8suW^_EZsovApdb3N)D9c1=fEKWPf2$~_L7IvhlbNsccO z1|{a8HG@c^w4X;|O7%?)KB8SyiTCsp&z~H$v%y~GFywC$5fNcwVId*pGFW5IJ8^m} zrWpUumMJF@L?o%cVZxc`!Nl|`mZE^7dOcGNRloW=ZVw;V@d zZe0)6C@e330vrC`DyDJ&_BRIAYnq=PKd{6pV&rM$WMr!5k;_eyK=Mqh>7zM7F%KSx z-$dtsZD7#!aeFM4%bbm{02dV=<_6#H&ggeH&uu@tOVC$6XHJyXb;=%sD=T5SvB3S%9Ki`Z81jpXxQbbjx;lAX(T_e^xnvP1i_Sc zS}Ynn;bDlmwx6(3l~$nWo6Ly@Ee3FaDvt*zz#0V*9!{c?A&mkp4QFO3cF~{$u%%!F zu1c$P{!kxX0AwXVb0{-P_A3%GcNwUhh+s%_8JS}cq{+K!5gJL3|4|b)Gux^*A9;G% z6>1^v*2t|wwaNV0ljZ91Ca>2y!VrogShB6W;G4#o_WCbDZ|GDO+h;J zm*wF9a$xQ0cuhq`r7^Rqsi~d*-#Y^Yh2)1HC=|;X-I5-=5vH%3cXAnSOylFS%!r1y{?qiF$ zY9fIcAtMu$Bz76Nn!q!KQ3=%pbGHHzQwaSl`+SYxev)s5Y)fK@DE)F}G*cqr-6EJ! z!eBu32c>|$$eb)HPy^V2P9W}r9zwg%T-k!ofLLZDT7#Wz+IR|Ny$V4Qb)c|B2pcyP z*b9fhcH)`E2Y!h{Bw`*ts`a3g1;Lyy5Rk=i9m|4?k5t_jiMXdq~(c;!=_)%~?14Ro=putMLBhh@#Gu+*3cepB-@OgI3#E2^#c-s=ktg z9b!C_#78->#13aJwSK7Mqy~p;2L1*W@Ic*?XNOLih6X6{Nna4XYD-KYCv_NBSl%xB zN_SEaL+bbO4Cddgo*z7c2ttroj20R=Ryk$MpehU$AFDH3r^b3GR91Q4A8Pjtlji0~>I!S?al7`?we+{I5FBJRGWpkKF5)qQ@Yh$mmri^Ns36aW{EwV>+WgCP@ma@EOy7#?r?|q(o z{yEQcmOsvUp0oUZpYP`fpl3hVnO2XauJ0C7v?sO~y&E4;r=sAiFJ+~HmZf@DKabGJ zZbhZ)&d<0RJAKG(NI!NUuXZ)hB_Scql=T5bPrt^ydFBu!__J^EY4p1n+AMg25b>;m z3$4s=A~&GGdOT766QD0_clO+VcpfGia~^oWwjfK`v7obAWinOg>lchJ(7P6SDo-Zt z>{!Ih!VKpX&n`si2upi~8b+ukeRLI#`xHvcaK}7i1xau2?XnwUoPMxx1XA6U%ySBEl~Xh-Wb8;Cv&^*;QOq zy>1OWGU78>##cde^3*nvk=B6d-BqXFpuJw)gIggkKU@@|Tn?Psn{3|VyQ4UWy&AE~ zuFfkY3I-v5iwG{lE?p1^lvF$83iAIIrpsJ}oS*kBr<9>kV~%6P_@^4PrpDLZ7+c5{ zl^?c2Z*u~o?B0-NJE`}GMIWHu2DRg70N>vxXN?TOm4}I3?>@JlB2^`87?9tQUKduk zHl(>6D*3l&?>~>x)ouH}I83o3y>jzkyLG%-C&NrB<0k)vRqc0mD?hGJTVcR3R=ha49z`gVs zfCD*4+}^>H{ulug5+@LulE2W0t}`j!L(t%IPl!97M~&Rxne%|Am%^MYo1WD_k`pMI zSG5MEg!!yYsSEH+|tL*y>+XV*CB{2Z; z65ou%_{%>3%!Zuv2N>fO;z>8V>(+ohU0rG&_Eb+U33il#<{rdRIQ0zcBn`^?=l$E# zZPkvYn^$PLE`1DTZc(SnhuT#@KqiOa;EFTgN=Nh3*)-MWV}i$` zR^R#*yHQ`NTUyEhsX6O?(r>9bqAM$|`}jTF;LHcmt882hp2Y=QUR&Wd@V&^2)CMyd z_hv6VXJ9$(p1!MN8>lj4dSM0Rsrn}Rq-e^CrU-ZB+q+~8E(%j_Dt#iu>^e29FGg^z zJg3UsIjN$$EzC*zIy@)?tGtaGiaUh%*Ge7aKn*=|wj8~p7&&@4uEZ0p`M-eQGFNT_ zo`T!v=gXdy+|m-8+0KU}fZ}KW7XKr$L^xGPv@QxmNb0O`>+GR-oQZMwT1tQ!`*s~KH z@tx<<#~`?J5qc26Dl)r}EUCwnVVSCZuan~V$6Y?pOrKp^jFct3 zbsv8)u^s1aiw9}{7JW;e$PeBk1jinfT4aElyq@aPwE~3b&fNWKKXIe} zkHTp##w)>64HgGbwyWDK()T2Ks|D}o?0YR?#Kh~2dYzls3QwUb@9cdDF(9YIL9l|g zVtx%4Sf_O5NQNTWCQ?fyhEOCbk{@&ond^=zETIZU?s)nh?=zli(W6MyjpKtc6r-OT zl$u=0o_Iqw7g|Qk5g|qp$ZV2&@kN5q!{d-C`>c13(}gr4%ZWahR6Q}OmRMRbNm@gE zzoTLo%g~&x<`%%yVH;kJM-AVn5$A}hV)9bYzR7kWYeG+r#wA=3(fSp*ONoD3^{lWI zUOnrC*VQnM^b2plw`9%X?S-naP)m=^Q%?TYpC)LE^{ui5+8;3x`~dQFk*oAZ{#AE3 z_lge``0Xr&yvk;m$+d}+qrYxl8$H&hlKtb4s|O% zXKV7=T-T~{NsNtS8!8)-fLv@A_jtO$@GppIG5|nK4jFfTm+1ei{GrpLira%HsXoka z&DFfwJbA?=D=Og&74uY^q`$dm!1wS&=hTihZUoY-=j47gaayABDl`7srM00C`a7)x zJR3z*>MiHC;UA0%>&|$t6auAgqKW>#A4GlT%5rM44HRUgLosTC#evI}Tu~H({Axx|MncF_P}gR`z1Y{K#8seb=@@Dmx^QD&29}{U z*z6<)($i#x9Vq8+I1D_<>FsO=9VX>3=37ba>G_H4X)d=*NyN7b(}v>m551PH(#0SV zlB=c}YV)gb7j15!lOZ%yYNA*8vOsmT`PB>$mxt@I+_8iz; zNQ80d+pwQ`&3A+1f2m8uui(80S}rw}A?+9_&`*m#HRa8p(+_%PF6#Z%rc0@abFuX` zVl*jdK&li;Yd*B25D%o{daS;I(Ot0l2n|`5WO&dQmc3|R`UE%@PP+X5#?x) zMK9?nWjkI7=gEG0@UO!8bL1Fb9?=Y(qkWl9;8h{ z9WCj4QxC74(vX}4@LKirXhhF9vTXm#HP^(I$w7Cdrl8NsOxDG^Rw)1FhKVp+`^i#V z(95fNiP6F6*dxt#3j&E~`@?*>O*}2%+`PP{k25wm+CmG$z2xubhpwwIE^ypZ*YFb8 zRY45#RTggA9U1aJ+FG;ywVLbmz%%xW6deI6-oBfs2<9qJ7Zmy!b*9qiiol2rIVO<4 i7$`*>{O_xqpf3x=q-)GRcEEf@kiL$wcI5?!$o~K`%#W)8 literal 0 HcmV?d00001 diff --git a/bip-0001.txt b/bip-0001.txt new file mode 100644 index 00000000..8057839b --- /dev/null +++ b/bip-0001.txt @@ -0,0 +1,172 @@ +
+  BIP: 1
+  Title: BIP Purpose and Guidelines
+  Author: Amir Taaki 
+  Status: Draft
+  Type: Standards Track
+  Created: 19-08-2011
+
+ +==What is a BIP?== + +BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. + +We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. + +Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal +. +==BIP Types== + +There are three kinds of BIP: + +* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validitity rules, or any change or addition that affects the interoperability of applications using Bitcoin. +* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice. +* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP. + +==BIP Work Flow== + +The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below. + +The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focussed the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocussed or too broad. If in doubt, split your BIP into several well-focussed ones. + +Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum or the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list is the best way to go about this. + +Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. + +Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. + +Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors . This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. + +If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. + +The BIP author may update the Draft as necessary on the wiki. + +Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final. + +BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page, etc. BIP authors should use their discretion here. + +For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. + +Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final". + +A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status. + +A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. + +BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1. + +The possible paths of the status of BIPs are as follows: + +[[File:bip-0001-1.png]] + +Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP). + +==What belongs in a successful BIP?== + +Each BIP should have the following parts: + +* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. + +* Abstract -- a short (~200 word) description of the technical issue being addressed. + +* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License [7]. + +* Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin). + +* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright. + +* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. + +* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. + +* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. + +* The final implementation must include test code and documentation appropriate for the Bitcoin protocol. + +==BIP Formats and Templates== + +BIPs should be written in mediawiki wiki syntax. Image files should be included in the current subdirectory for that BIP. + +==BIP Header Preamble== + +Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. + +
+  BIP: 
+  Title: 
+  Author: 
+* Discussions-To: 
+  Status: 
+  Type: 
+  Created: 
+* Post-History: 
+* Replaces: 
+* Superseded-By: 
+* Resolution: 
+
+ +The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be + + Random J. User + +if the email address is included, and just + + Random J. User + +if the address is not given. + +If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. + +Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made. + +While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists. + +The Type header specifies the type of BIP: Standards Track, Informational, or Process. + +The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. + +BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on. + +BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete. +Auxiliary Files + +BIPs may include auxiliary files such as diagrams. Such files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). + +==Transferring BIP Ownership== + +It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP. + +If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor . If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). +BIP Editor Responsibilities & Workflow + +A BIP editor must subscribe to the list. All BIP-related correspondence should be sent (or CC'd) to (but please do not cross-post!). + +For each new BIP that comes in an editor does the following: + +* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted. +* The title should accurately describe the content. +* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7). + +If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions. + +Once the BIP is ready for the repository, the BIP editor will: + +* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141). + +* List the BIP in BIP 0 (in two places: the categorized list, and the numeric list). + +* Add the BIP to the wiki. + +* Send email back to the BIP author with next steps (post to bitcoin mailing list). + +Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. + +The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume. + +==History== + +This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org. + diff --git a/bip-0011.txt b/bip-0011.txt new file mode 100644 index 00000000..e5257ba2 --- /dev/null +++ b/bip-0011.txt @@ -0,0 +1,57 @@ +
+  BIP: 11
+  Title: M-of-N Standard Transactions
+  Author: Gavin Andresen 
+  Status: Draft
+  Type: Standards Track
+  Created: 18-10-2011
+  Post-History: 02-10-2011
+
+ +==Abstract== + +This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. + +==Motivation== + +Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. + +A couple of motivating use cases: + +* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business. + +* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP. + +==Specification== + +A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks: + + m {pubkey}...{pubkey} n OP_CHECKMULTISIG + +But only for n less than or equal to 3. + +OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig: + OP_0 ...signatures... + +(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack). + +==Rationale== + +OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. + +One argument against using OP_CHECKMULTISIG is that old clients and miners count it as "20 sigops" for purposes of computing how many signature operations are in a block, and there is a hard limit of 20,000 sigops per block-- meaning a maximum of 1,000 multisig transactions per block. Creating multisig transactions using multiple OP_CHECKSIG operations allows more of them per block. + +The counter-argument is that these new multi-signature transactions will be used in combination with OP_EVAL (see the OP_EVAL BIP), and '''will''' be counted accurately. And in any case, as transaction volume rises the hard-coded maximum block size will have to be addressed, and the rules for counting number-of-signature-operations-in-a-block can be addressed at that time. + +A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes. + +==Implementation== + +OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type. + +https://github.com/gavinandresen/bitcoin-git/tree/op_eval + +== Post History == + +* [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal] + diff --git a/bip-0012.txt b/bip-0012.txt new file mode 100644 index 00000000..2ef52633 --- /dev/null +++ b/bip-0012.txt @@ -0,0 +1,84 @@ +
+  BIP: 12
+  Title: OP_EVAL
+  Author: Gavin Andresen 
+  Status: Draft
+  Type: Standards Track
+  Created: 18-10-2011
+
+ +==Abstract== + +This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. + +==Motivation== + +Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners. + +==Specification== + +OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows: + +* When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script. +* If there is no item on the top of the stack or the item is not a valid script then transaction validation fails. +* If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails. +* If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2. +* Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail. + +A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined: + + DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL + +Which is redeemed by a standard scriptSig: + ...signatures... {serialized script} + +Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the ''serialized script'' is, itself, one of the standard transaction types. + +==Rationale== + +OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the ''serialized script'', and one new type of bitcoin address can be used to fund arbitrarily complex transactions. + +If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver. + +The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties. + +That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure. + +There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: + +# Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. +# Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. +# Attacker manages to mine a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block. + +The attack is expensive because it requires the attacker create a block that they know will be invalidated. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions. + +==Backwards Compatibility== + +Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the ''serialized script'' hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners). + +Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner. + +Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases: + +# An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners. +# An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners. + +For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved). + +For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op. +Example of a transaction that must fail for both old and new miners/clients: + scriptSig: {serialized OP_11} + scriptPubKey: OP_EVAL OP_11 OP_EQUAL + +==Reference Implementation== + +https://github.com/gavinandresen/bitcoin-git/tree/op_eval + +==See Also== + +https://bitcointalk.org/index.php?topic=46538 + +"Bitcoin Address 01" BIP + +M-of-N Multisignature Transactions BIP 11 + diff --git a/bip-0013.txt b/bip-0013.txt new file mode 100644 index 00000000..1b08085f --- /dev/null +++ b/bip-0013.txt @@ -0,0 +1,52 @@ +
+  BIP: 13
+  Title: Address Format for OP_EVAL
+  Author: Gavin Andresen 
+  Status: Pre-Draft
+  Type: Standards Track
+  Created: 18-10-2011
+
+==Abstract== + +This BIP describes a new type of bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. + +In essence, an address encoded under this proposal represents the encoded hash of a script, rather than the encoded hash of an ECDSA [[public key]]. + +==Motivation== + +Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services. + +==Specification== + +The new bitcoin address type is constructed in the same manner as existing bitcoin addresses: + + base58-encode: [one-byte version][20-byte hash][4-byte checksum] + +Version byte is 1 for a main-network address, 112 for a testnet address. +The 20-byte hash is the hash of the script that will be used to redeem the coins. +And the 4-byte checksum is the first four bytes of the SHA256 hash of the version and hash. + +==Rationale== + +One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism. + +Another criticism is that bitcoin addresses are inherently insecure because there is no identity information tied to them; if you only have a bitcoin address, how can you be certain that you're paying who or what you think you're paying? + +Furthermore, truncating SHA256 is not an optimal checksum; there are much better error-detecting algorithms. If we are introducing a new form of Bitcoin address, then perhaps a better algorithm should be used. + +This is one piece of the simplest path to a more secure bitcoin infrastructure. It is not intended to solve all of bitcoin's usability or security issues, but to be an incremental improvement over what exists today. A future BIP or BIPs should propose more user-friendly mechanisms for making payments, or for verifying that you're sending a payment to the Free Software Foundation and not Joe Random Hacker. + +Assuming that typing in bitcoin addresses manually will become increasingly rare in the future, and given that the existing checksum method for bitcoin addresses seems to work "well enough" in practice and has already been implemented multiple times, the Author believes no change to the checksum algorithm is necessary. + +==Backwards Compatibility== + +This proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction. + +==Reference Implementation== + +https://github.com/gavinandresen/bitcoin-git/tree/op_eval + +==See Also== + +The OP_EVAL BIP. +