From c2c5491547990c6a0bd74949f29b6a11a4e75832 Mon Sep 17 00:00:00 2001 From: ilcompratoreconsapevole Date: Sun, 23 Jun 2024 01:24:29 +0200 Subject: [PATCH] Aggiunto BIP-readme introduttivo\nAggiunto BIP-1\nAggiunto BIP-2\nModificato CSS per la visualizzazione notturna\nRipristinati i collegamenti corrotti. --- assets/images/process.png | Bin 0 -> 20813 bytes assets/images/process2.png | Bin 0 -> 10389 bytes content/en/bitcoin/_index.md | 3 +- content/en/bitcoin/bips/_index.md | 10 + content/en/bitcoin/bips/bip-0001.md | 232 ++++++++- content/en/bitcoin/bips/bip-0002.md | 451 ++++++++++++++++++ content/en/bitcoin/bips/bip-README.md | 20 + .../Ilcompratoreconsapevole/_index.md | 7 + layouts/partials/head/stylesheet.html | 1 + static/css/styles.css | 18 + 10 files changed, 734 insertions(+), 8 deletions(-) create mode 100644 assets/images/process.png create mode 100644 assets/images/process2.png mode change 100644 => 100755 content/en/bitcoin/bips/bip-0001.md create mode 100644 content/en/bitcoin/bips/bip-0002.md create mode 100755 content/en/bitcoin/bips/bip-README.md create mode 100644 content/en/contributors/Ilcompratoreconsapevole/_index.md create mode 100644 static/css/styles.css diff --git a/assets/images/process.png b/assets/images/process.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/assets/images/process2.png b/assets/images/process2.png new file mode 100644 index 0000000000000000000000000000000000000000..b53279901180a4cb13c1905e053790b290703692 GIT binary patch literal 10389 zcmb7qc{tQ<+yAtnlADNW5t1d@T1c`ck}XPxv4*j4Wz90klC5HtCA;j)kdcuQlS(GC zWgQIe3Ne;Mb~W7E2> zehUWMjRV*9`ZE%ht6?+?vovcA@{+iGF`)NnE-CO`4}t^AKlhYPP1 z94DNAyjpy7`seY7S z@Pv1Va(3r(`BX+jfBk5~syuPUESpiWh91zuTt`hUglq@4B+4acZ;erJgzf$1cT#!j zGj5~E4t7(2mWzJ$Xy+w8ORr;F9R41Ef63f;ugPC^wwiKnmt z!P7le`ifVjVjZ@oh0Y0V+~eb*tIl$DhLUz`J^Id)!SX>FDkXqZL4 zgV7RqcZu%Y>d&6S{qNuUUqvbS&6httYcFQ`eRGM!St&={yT>No!OL51$~ z^A(QWFWkFwuHfh6q#N(D{KYE}gV}s?*>`!OZA$yu>A#Q3I)Ask|97NfcIp}9irJx8 zPVfB_!flCG#Nhq+c!_V;MgtM6i8@mER%ZGXthd`rjmij2& zzx@*~{pC*bDhhSuVXSJ|;)|Q~vF#2_#Z#&V-nQjQg-(hTek7Pa$8$Jwx7J)36YCRd zVB;2zx|(&Mk-k72lQe(b)&BfK3%58z!YM%zCq#T%Rkr3j*4QAd>=w96b~uDozi1pi z`&e%D$m4J8cGP|>VzpJg(i>}5+i^&+?Av2?!Q4(GS<@e09jWKO6~{}HeZH!1>v520 zeU71TmRL3r6gIv;wRn6?c7)Hhbk$ zzXxC_csH|m_yV02f}lq1>qKE4fiw7Pb$A>y z?mblS{=p&G=AZCQ!^7 ziO(u{b5YZ8u^C=(sIS!b__&;ub^S4s-q#}CZ1~wJ5zO2ek+@%8FkSDwz_oZjx8bOR zM?FVI4Qp9$Pl;v+g^?0BZm#i|Fo0@#<8<&y`nqcv^)pYTN=RpF5a?;mxhaHyUMzY;Ew|k7DP4GJkxQUNEfZ zHjICa^rK>Hp*ggDLaDH*A6l((8L&TEtCK8oFU2ajj`F}@7Vk>_f;FiUENnEbaYo8L z)Z|C^(h}fO=7W8eR$~pcnX>&0Ckh)Y8)>Z+?;gF1ppB(&uZj4OOAsI>uC(%*lxUKDGU?+QOW(HHR1>hN9cO9(8Ahk(qa&D?9*8>m z6Bx#F_O`2}gZ1mbA0D55hrOSD*{2lUPu!f4)@qY7!+-v2#t;PS)otJ*yUJ!4zJPFJ z@3shmDN`jRcrAN-Q?$@hE4*VsVgB{0x#a_xcI6_ck=IoW>D5`X*9V?pM(0d#$x{KG zbCuHCh?gYGnf|Hvba-{;Qp3ls(;;QLr5R=Q-NxqkB2Va)Zf5GDj4LhYf*Dk+VT$S; zoZoQ3G7y`|`pI0h41I`fo3QIl|O^RcEZy!kcB?mp+eZ ziN+P?^3+oqGnWr-rmru;Iq3pVMfLG3l?|(=rc>Ni*=WJC`7^QHpIi~IocmfM4A|T( zQNkfZM2F6-e$%pT>{qeW^dx?6edQ@_AtU{>$v&f}i|Ct-A{E9b&qkY5_m!gI$mYj3 z3P%iQ2FiSt3%y0JK86Q$-Z>aWhGUejVfs{b>^5t8#!3m+?;oZL+|DksZ%-2r;_9zW zE30fwt6(z!tbc#DG(PF8w&aDO!v36b_{;UzeYJF}t)-Mz$>6nlO83fet%uwvMfz-Y z9@> zS6o#0&is0lIvTXxo{F1UD_%ZziSH^rAgND6uB3vii5SyyR4dA~C(PWdT~?%-W)`7T z8O@mGMowJcpGC+!?TH#!}kpHT2MX`^buEl`yzTkE#sT-jbe zS?gXJ8;0M`d|j?3bX^Y(9|*sX>2vwyakkLA;&es$xukNJD}&JDtMZ zBtAsd8m`P)PRP8Ka7BaQ_{w8l+p^leJr*yq7fB3mNLuJAiqAA|(vaLYgtu$ssb}Pm z^${f+BdHElR>TT&2O!1OOdW!`m|I_5O7Q<^6k|?_)Wc%MCz7A znhXc&HpjVMrVHX)1aPz{r^&D!j{F%DY@r`|t4*r@b7Rvwig(sF4uJX-hgs&LG1`0n ztvglu>fB=sV#pC?fF}sepQ}$b(Kl+^L)ubgikoG!rm{muTc>^PF0U}=JVL5Jl={pN zi^L+l15L24HUN{59nz&A6zp0L)6v~8H1;o)m=U5~=Q+rEbEe}S!z|sjbrbfd>F=Y< zr7Es$=tVZF)1)ra5~tuQ2D$@>DNR3XX+9E9Mf47=)Lu>`1>9Vrux@UYtm#d?5nQb{ zMnyJ`M8!x_G@=(wbGC{WPiL2AY@aWdrW4Y0d_H+r*k}wVPI$C;9dcb^i!CpVWL-ro z-TKD}nqoLYdmifW8%g1l`$UN2{8xOO>eIIRBDOme7EHFWx;#kt!pYCdxJ98jv$0wk zi2LM!_(> zmzMF&dEGSv)pU}G%k5|@{)>>?u;Kh?t6Ff1h?Tw$?IVm|7O{2>2&;ZuZe;H8C(CFd zahiG7O9*Nh;SIl34EYql+>xei854hwQ_jVd)AU=G*NEE`p+%65L_2LHb(IodGb5bp zJL{aIuM6W^tA{3+T@6sewL?52gd-ecxN^{8f(-bB`m5~`lHQ`v%{GxhJ zJvq+*#$lvSzVV3=5Csf#o|=4%3ANzL(-%hMo(1EK^Qk9Ui^@)*&OjhOP8RkpL(`Q zs=rC2*2zcr*sD`P+4tBUJ(_By&&PfAHNo_GV`eOKl%F|Iu=XEch33@?g=Q^fHYrf6 zN^qq~Qk<^)x|ft6JNV2c$v9lz*l%y}TKyREs9TRK6HN)ZwQ9k-xgu~HciFE7taGtZ zp^wV{8g;@hJ-J*b1DOP&!A1G!96!voaZTd1kJyzaRJtyT-~am|vlNRl#n+*yaLSkx z{*pq81Nhyi|B`jo*`vAnOFj5yihFoKZ@gCco?|kO2?+EtB`iTEOfi~f@6^ztRKrpH z#=VJIQgR$J=L*q$z-YrYkKzR!&s&Cua^KPG!F>+)4&gE70yqK)x4@S_zqH1Zu^vHvI=|^Y$n4T_Za*nM@0UM+;sp-J8ue#_eyuF&xQ-pM&PVKfbG;sjy?K)Jzg-dAK)38}7;0+MRP= z*qSobH-*qi(L{&!-72(wcF?6OwnIT!Q~ja`K&v`=aZF!t%z%ZTMRLpZf--MOr^{F) z8vCelh*O%liEAcw7}nrRjEwG8N;_>ev3{!H`lOEdVQ!4HX#2W9(DD$Syd7=YE>~W% zKk2G0Q&J&k@5mTUh5qK4H;XjR*?-`f=MwiyOkYNM(@1$n>80*x5z13%nEM(8QoZ^b zH0pY%JerF>Af|MF25_jjJm6C*s?Gj3#@yjfy z=c*&vFL%}DCmW)#7-sy)gi>4n zdg&AUCGfcoKZZ%2=emuM%DAGy>VrYitX&wU#3R37{=2R{9eZr}Ign7rADelhg3vqC z3Bk5RKOQMcmG}He9p^us`}rxHg#YQRQy9`^K*t?6rneiOw)v@jrK-DruUo#Oh=BnFb<0*W-0JlnATiX^{zwVoq}~2Uz}VDzJfD($sr~J2 zN6rcmycb3(vQA$<;Ejq6n&t+pPR$WOt{U|2!(Bi-D@>|v=7EH974^V{2bOS{14(KV z1ax^ae>iY;)@eBEuM=r`?rm$-fzBta7^Z(rkI^Hb+ma>m4S;b&R{k@aBqc%mbW!%u z>XQ=+AIq(3oReJ0xB|+kwCSs2m+lvlW_6x+$!OI3S1+SkDpL0l`F#|7ef>P44IdBqIKlEu zQPUlxGDM9Oi>WhEIjG4J$i!Qy_w#ZgTS3M-s=NF~{io`h!dcAZ*%ZZ%D>8-&K4pP` z0=sggJ#qQ?=%_nj%T9eN!JGGoYr(bq;7jXOxzo4uqa~vyb{4M&3J77YLY(*5m3|p` zPk$+htN;0q)y)hfyCb09JWuhP<+loAhpQd*UuB``t93xMcz#KQi|oBx1}PhWW;cV-ax)|j-N&%ij}_{r&-%4zaC8oP5Km+(owP)~@2_-c zrlDsCtIqlGU-l*u&I&;C7ECaml@lq%i3~d{h+DK^g`|zOFFMl5vI5#8FzS2glnq$0CSu_rJ}YcYGLt0p<#Gbou>>BxBe5{M!r%#y4x>q%=+!AO*Vr z`q5o+Bl9xC{awU_`$*rlupu_NC-dxu*DoauYqdz8L)7$6MB{fX<$Gl91drR zg-g$aJnYV%3S5AIS}G%g+1A3BY*%sj?{^n}&K9P-duF3ok>2$Yc&(=*7d6XgbZUd! zjm#=7mCCHJ9mmZ3UpW~m71r&JS<_-l_YI7>hq(k$!+BIVg%pSzEUHL<;ixh{5yyWb8?MS4>N{o zr=`%0GdKV)UVE4iMoUrZ{rvROWUAb_&)mKX6y2RKc6veb|1Z>yB?;nw2e5=db>IKQ z+EC~XtWFaJgaE_g(JI@P)Ri&>)>G09@7)~B?WGaN<0EPM>Mp>!M`DI$2+84vZcYB0 z`TdcsaNiZ`fFF?ToRbCVAcuNQ@S&PAin0Pq6}C5*DdSDyl)v9c*|vhJK9AO`$8c5v zsH*^8GXI`kMVD^U{K~0kHkFn8%y;MB;=g&MEgz9~?^sFI{V-DNn}r|6Zn)*~akzza zQ_r2V`-=&@jwQ(ILaZ4MrS*uUeL&o(^gEA)$@plkoI zOG+ksmFzxHVbKj76cNb}V?<9=R{De8xU!tmVmx zB+Y}k2%PL$~bXE z`OB>$f)CMas^bUk`2`2l4L}9!!CDlt*vzQrB)e2LTr40t=OE5w7*+>O;1LQ7Z+c84 z$NZ;GK>Ho)8i<9w^FUs_u|a;vN9`>!#Ey*Ad2!8jjm!L*aSW5xWZiX?2H-qg_7Vmm z##m}!nX%dim~#`IQd&*`hHW+Sadvt?JLy2|Y`RC|bMNH6D}G9IuX3sYq5CmhwptG~kqOGi6{aU|{m8k+>tU=VZEvuA=bs zMDlb`QGMV-!$78ItJuY)0U#G1rYuaPSmD2QRVjg87k5&^NnhQ>TYXPEsyfnS+a}sl zI-mG|h(2`ji0*=M>20z9H1*AY0#7Uyc+!HjZ-MO0U9$X`Ik)<)VxHSdBRl+Ty873h zu-ef8@j~+;ezM%?{r9r&BZD)^*GscYnNcM=Vfnv+SR0$%2a{ym_mtNqbVyH*@?9BZ zN~yH>yk%W)UV&gBY=C`tQgG{Znwswq@u5By9~0nxl@2^n^zU-Hd*e*GN*vs-VBj{5(i;9EJ}er6!{# zIOqV`MP)J);_4=|6#>jx02H$6S6S&byvXPPNH}{#c>}e!{w==6b-Udo*w%18e>Y~r z<_T$c6+5&v?!J?r3~(((T_gd0>xWe1`q$!6ykocEwP4xW3CY?KP7C<#sbRd^aOza; zSO67!POwbV&Us6xy+lm@guEx}-8taL?X52J+U;>ATHn8EAgJ};(_iQ7rufAD`jHNG zmBg(fyi;r*6d%@@8#*_pvKOFTs1_;bfeN=3mhO8$?#r?`Y)V>7(`XIAwMA%YA|-d4 z!hFrsT%N|s3$lJth9arjMXS#%r?vNwe0+R7?}aJB+i7h)oPCJO!gv4eWMc2r#}QdP z`Adn-D8VxSb6{`oj-CDI)W7?&X7D7{cC(U=3&Pp)N~@_5NGJ6ehATq*7(SfcK=mh& zWNE}6t`fFH`D6r`-UNz%Ui{*1YSn6rfy+BTJw@qzeV14E^Pp+Js*)$i1?2WOwEig4 z)K|SF-}g-=d~&JRYaSF-Zh)`Bt%5NB(PLlB&x{L$qWW2`l@JC6VnvxY9+-(T@nOXt z^ilPdH-t(^d?hXq`klV`#*26v$4#@zjohh}E!O3#)3IUXDK&qH;o{k=1JdN?rhObsO-# z*TzCTeCVBTn|U!zHvBNmwx%Bdze}ax+>l)*B-90> zTTb{5K4QM|F1FlM{~Op+4fuszhVp>tY$xwO;`|J@0Zu7@BR2%rD!o@G0bSZ19RL&} z&p@nG)34_Xjdb_G2K)A7fmSu6GexGE&Fykyt}XD*gK+b^SH5(1tNLgF+8-AVX(gHK-Gn?`aC-KB1&f1G%+~G1-xsZg7K>R~mQa9NU4MnXXkR*g%n(pi^w+@^Z7f zQ`uz#?@n=E!MhA}^t%Y8G2==qEAi4uoKPEdmH zq>k5hP(BJoz(XnknK{=oZsuIgiLCivnqg`k{svG}yz&-9HvIuX&oQ0vuah$LP)o4y z=1~A8NT3x`uAsOn-qmS$QEySf6|qm>oRt76u9-_ykrl@z88{y%n);>7d1NJ%VnO<6hE5|Q*m+ZBoD#KM zQk8KYZx$cAfE`<7m| zz1Wt!$qv3ay2~?VjR(*o80@?@>g4hjXwG-&75Mq@Ux?E|umAfOX91mdk-)?v5AaC* zICHyr+`Vzbehp|ve1;65I(gf*KD!4|jc{hR)~Z`bpzI73>K%us1SU`$;|j7+3y^-h z)-hIxE%L5CHg62t&~=7OnB2YXLj=c45Pt1xvJ`M$WdXmMz{YQrSNH8v8HnO z6zX}^IQQWgMq^)_;~>ov7OKmIg!cXYhMbBttaLVe{qR8WasSbki!bIc@0Ud4KD0^z z5~U${s0>oXd;vFPZK#BkzZB@y|2ZXK#y@%r%Wk%?zW8k}b*3LneaLov5-?0>is&n7 zRf35W!L_H$)t(0$-(7Hk<0A4OiAlH34RlDC&(KHmx`Wl&i+TX65y?aAptnl*f9Cu* z7uhi`R2#%S&vP~b5;(j7BI7-<1s;zK`1Qkj7@YP^nP{%3wcn8HIiG+w2cxW|`pTcP_xA$<+>`pB0W1C9E2O`chb38DV4?D$GTO`jL6w zE|$>+kEB%#LK+Oi_NkSNqz2v*4Jc|YARfeb_z6n3GsJ4I1HgjvN z7X_7{j&>ak0QvigWn>uIwJk|J>UYbrJK|Il2oTKI=SCY8F5l6)g_~>DlxrKt?h~TLa$W82;|fS=O;zkRSjAYc&j;@(To!ilBcI&7M5~m&)iW z@&*#BRLIsQbovE4_O;p-aoK0aM2Sm8_tMurhu+PD>Iw}Pz&>DkS;Qpf#5tP?Hs+on z95}tDw&Ql5c_e0ddqXKt2T+LW*p=4>rh@~5u!R#}-v3L>39opkNEZLxI2{Yd)(j}K zMMJ=f?w1vT2*ARSnZIX6iW9lM@!ORlAq8~!|LW;~{N -
-Ci stiamo lavorando... \ No newline at end of file +
\ No newline at end of file diff --git a/content/en/bitcoin/bips/_index.md b/content/en/bitcoin/bips/_index.md index 77aa8db..9546c71 100644 --- a/content/en/bitcoin/bips/_index.md +++ b/content/en/bitcoin/bips/_index.md @@ -5,8 +5,18 @@ date: 2022-10-11T16:54:24+02:00 draft: false --- +
+
+ BIP-README → +
+
BIP-0001 →
+
+
+
+ BIP-0002 → +
\ No newline at end of file diff --git a/content/en/bitcoin/bips/bip-0001.md b/content/en/bitcoin/bips/bip-0001.md old mode 100644 new mode 100755 index 3541fa1..e62764f --- a/content/en/bitcoin/bips/bip-0001.md +++ b/content/en/bitcoin/bips/bip-0001.md @@ -1,13 +1,233 @@ --- title: "BIP-0001" -description: "BIP Obiettivi e Linee guida" -date: 2022-10-12T20:18:15+02:00 +description: "Amir Taaki - 19 Settembre 2011 | Status: Replaced | Type: Process | Superseded-By: 2" +date: draft: false -weight: 100 +weight: 101 images: [] categories: [] -contributors: [] +contributors: ["ilcompratoreconsapevole", "cyphersats"] --- -
-Ci stiamo lavorando... \ No newline at end of file +[Originale](https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki) + +
+  BIP: 1
+  Title: BIP Purpose and Guidelines
+  Author: Amir Taaki <genjix@riseup.net>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
+  Status: Replaced
+  Type: Process
+  Created: 2011-09-19
+  Superseded-By: 2
+ +# Sommario +[Cos'è un BIP](#cosè-un-bip) +[Tipi di BIP](#tipi-di-bip) +[Il flusso di lavoro BIP](#il-flusso-di-lavoro-bip) +[Cosa si trova in un BIP di successo?](#cosa-si-trova-in-un-bip-di-successo) +[Formati e modelli di BIP](#formati-e-modelli-di-bip) +  [Preambolo dell’intestazione del BIP](#preambolo-dellintestazione-del-bip) +  [File ausiliari](#file-ausiliari) +[Trasferimento della proprietà del BIP](#trasferimento-della-proprietà-del-bip) +[Editori del BIP](#editori-del-bip) +[Responsabilità e flusso di lavoro dell’editore del BIP](#responsabilità-e-flusso-di-lavoro-delleditore-del-bip) +[Storia](#storia) +[Registro delle modifiche](#registro-delle-modifiche) + +## Cos'è un BIP? + +
+ +BIP è l'acronimo di *Bitcoin Improvement Proposal*. Un BIP è un documento di progettazione che fornisce informazioni alla comunità Bitcoin o descrive una nuova funzionalità per Bitcoin, i suoi processi o ambienti. Il BIP deve fornire una specifica tecnica concisa della funzionalità e una motivazione. + +I BIP devono essere i principali meccanismi per proporre nuove funzionalità, raccogliere i contributi dalla comunità su un argomento e documentare le decisioni di progettazione che sono state prese per Bitcoin. L'autore del BIP è responsabile della costruzione del consenso all'interno della comunità e della documentazione delle opinioni contrastanti. + +Poiché i BIP sono mantenuti come file di testo in un repository versionato, la loro storia di revisione è il registro storico della proposta. + +## Tipi di BIP + +
+ +Esistono tre tipi di BIP: + ++ *Standards Track* descrive qualsiasi modifica che influisce sulla maggior parte o tutte le implementazioni di Bitcoin, come una modifica al protocollo di rete, alle regole di validità dei blocchi o delle transazioni, o qualsiasi modifica o aggiunta che influisce sull'interoperabilità delle applicazioni che utilizzano Bitcoin. + ++ *Informational* descrive un problema di progettazione di Bitcoin, fornisce linee guida o informazioni generali alla comunità, ma non propone una nuova funzionalità. Gli *Informational* BIP non rappresentano necessariamente un consenso o una raccomandazione della comunità Bitcoin, pertanto gli utenti e gli implementatori sono liberi di ignorarli o seguire i loro consigli. + ++ *Process* descrive un processo relativo a Bitcoin, o propone una modifica a (un evento in) un processo. I *Process* BIP sono simili agli *Standards Track*, ma si applicano ad aree diverse dal protocollo. Possono proporre un'implementazione, ma non al codice sorgente di Bitcoin; spesso richiedono il consenso della comunità; a differenza degli *Informational* BIP, sono più che raccomandazioni e gli utenti in genere non sono liberi di ignorarli. Tra gli esempi vi sono procedure, linee guida, modifiche al processo decisionale e modifiche agli strumenti o all'ambiente utilizzato nello sviluppo di Bitcoin. Qualsiasi tipologia di BIP è considerata anche un *Process* BIP. + +## Il flusso di lavoro BIP + +
+ +Il processo BIP inizia con una nuova idea per Bitcoin. Ogni potenziale BIP deve avere un sostenitore -- qualcuno che lo scriva utilizzando lo stile e il formato descritti di seguito, guidi le discussioni nei forum appropriati e cerchi di costruire il consenso nella comunità intorno all'idea. Il sostenitore del BIP (anche detto Autore) dovrebbe innanzitutto cercare di accertarsi se l'idea è adatta a diventare un BIP. La pubblicazione sulla mailing list [bitcoin-dev@lists.linuxfoundation.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev) (e forse anche sul forum [Development & Technical Discussion](https://bitcointalk.org/index.php?board=6.0)) è il modo migliore per procedere. + +Verificare pubblicamente un'idea prima di scrivere un BIP ha lo scopo di far risparmiare tempo sia al potenziale autore che alla comunità. Sono state presentate molte idee per modificare Bitcoin che sono state respinte per varie ragioni. Chiedere prima alla comunità Bitcoin, se un'idea è originale, aiuta a evitare che si dedichi troppo tempo a qualcosa che sicuramente verrà respinto sulla base di discussioni precedenti (la ricerca su internet non è sempre sufficiente). Aiuta anche a garantire che l'idea sia applicabile all'intera comunità e non solo all'autore. Solo perché un'idea sembra buona per l'autore, non significa che funzionerà per la maggior parte delle persone nelle aree in cui Bitcoin è utilizzato. Piccoli miglioramenti o correzioni spesso non necessitano di una standardizzazione tra più progetti; non hanno bisogno di un BIP e dovrebbero essere inseriti nel flusso di lavoro dello sviluppo di Bitcoin con un invio di una patch pertinente al suo issue tracker. + +Una volta che il sostenitore ha chiesto alla comunità Bitcoin se un'idea ha qualche possibilità di essere accettata, deve presentare una bozza di BIP alla mailing list [bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev). Questo offre all'autore l'opportunità di perfezionare la bozza per formattarla correttamente e renderla presentabile, pronta per affrontare ulteriori dubbi. A seguito di una discussione, la proposta deve essere inviata alla mailing list bitcoin-dev e all'editore del BIP, insieme alla bozza. Quest'ultima deve essere scritta nello stile BIP come descritto di seguito, altrimenti sarà rifiutata senza ulteriore considerazione fino a quando non saranno seguite le regole di formattazione corrette. + +Gli autori sono responsabili della raccolta dei feedback della comunità sia sull'idea iniziale che sul BIP prima di sottoporlo alla revisione. Tuttavia, ove possibile, è consigliabile evitare lunghe e aperte discussioni sulle mailing list pubbliche. Le strategie per mantenere le discussioni efficienti sono: la creazione di una mailing list SIG separata relativa all'argomento, l'accettazione da parte dell'autore del BIP di commenti privati nelle fasi iniziali di progettazione, la creazione di una pagina wiki o un repository git, ecc. Gli autori del BIP dovrebbero scegliere a loro discrezione la strategia opportuna. + +Si raccomanda vivamente che un singolo BIP contenga una singola proposta chiave o una nuova idea. Più il BIP è mirato, più tende ad avere successo. In caso di dubbi, dividilo in più proposte ben focalizzate. + +Gli editori assegnano i numeri ai BIP e ne modificano lo stato. Si prega di inviare tutte le email relative ai BIP all'editore, il cui contatto è elencato sotto la sezione [Editori del BIP](#editori-del-bip). Consultare anche [Responsabilità e flusso di lavoro dell'editore del BIP](#responsabilità-e-flusso-di-lavoro-delleditore-del-bip). L'editore si riserva il diritto di rifiutare le proposte di BIP che appaiono troppo poco mirate o troppo ampie. + +Gli autori NON DEVONO autoassegnarsi i numeri del BIP, ma devono utilizzare uno pseudonimo come "bip-johndoe-infinitebitcoins", che include il nome/nick dell'autore e l'oggetto del BIP. + +Se l'editore approva, assegnerà al BIP un numero, lo etichetterà come *Standards Track*, *Informational* o *Process*, gli assegnerà lo stato "Draft" (N.d.T. in italiano *Bozza*) e lo aggiungerà al repository git. L'editore non rifiuterà irragionevolmente un BIP. Le ragioni per negarne lo status includono la duplicazione di sforzi, l'inosservanza delle regole di formattazione, la mancanza di focalizzazione o l'eccessiva generalizzazione, l'essere tecnicamente non valido, l'assenza di una motivazione adeguata o della discussione sulla retrocompatibilità, o il non essere in linea con la filosofia di Bitcoin. Per essere accettato, un BIP deve soddisfare alcuni criteri minimi. Deve essere presente una descrizione chiara e completa del miglioramento proposto. Esso deve rappresentare un netto progresso. L'implementazione proposta, se applicabile, deve essere solida e non complicare eccessivamente il protocollo. + +L'autore del BIP può aggiornare la bozza nel repository git. Gli aggiornamenti alle bozze possono anche essere inviati dall'autore attraverso pull request. + +Gli *Standards Track* BIP sono composti da due parti: un documento di progettazione e un'implementazione di riferimento. Il BIP deve essere riesaminato e accettato prima di iniziare un'implementazione di riferimento, a meno che essa non agevoli la sua comprensione. Gli *Standards Track* BIP devono includere un'implementazione -- sotto forma di codice, patch o URL -- prima di essere considerati definitivi. + +Una volta che un BIP è stato accettato, l'implementazione di riferimento deve essere completata. Quando essa è completa e accettata dalla comunità, lo stato verrà modificato in "Final" (N.d.T. in italiano *Finale*). + +A un BIP può anche essere assegnato lo stato "Deferred" (N.d.T. in italiano *Rinviato*). L'autore o l'editore possono assegnare questo stato quando non si stanno più facendo progressi sul BIP. Una volta che è stato rinviato, l'editore può riassegnarlo allo stato di bozza. + +Un BIP può anche essere "Rejected" (N.d.T. in italiano *Respinto*). Forse, alla fine dei conti, non era una buona idea. È comunque importante che questo fatto venga registrato. + +I BIP possono anche essere sostituiti da un altro BIP, rendendo l'originale obsoleto. Questo è previsto per gli *Informational* BIP, in cui la versione 2 di un'API può sostituire la versione 1. + +I possibili percorsi dello stato dei BIP sono i seguenti: + +![Processi BIP](/images/process.png) + +Alcuni *Informational* e *Process* BIP possono anche avere uno stato "Active" (N.d.T. in italiano *Attivo*) se non devono mai essere modificati. Ad esempio, il BIP 1 (questo BIP). + +## Cosa si trova in un BIP di successo? + +
+ +Ogni BIP dovrebbe avere le seguenti parti: + +- Preambolo -- Intestazioni in stile RFC 822 contenenti metadati sul BIP, tra cui il numero del BIP, un breve titolo descrittivo (limitato a un massimo di 44 caratteri), i nomi e, facoltativamente, le informazioni di contatto di ciascun autore, ecc. + +- Abstract -- Una breve descrizione (~200 parole) della questione tecnica trattata. + +- Copyright/pubblico dominio -- Ogni BIP deve essere esplicitamente etichettato come di pubblico dominio (si veda questo BIP come esempio) o concesso in licenza secondo la Open Publication License. + +- Specifica -- La specifica tecnica deve descrivere la sintassi e la semantica di qualsiasi nuova funzionalità. Essa deve essere sufficientemente dettagliata da consentire implementazioni concorrenti e interoperabili per qualsiasi delle attuali piattaforme Bitcoin (Satoshi, BitcoinJ, bitcoin-js, libbitcoin). + +- Motivazione -- La motivazione è fondamentale per i BIP che vogliono modificare il protocollo Bitcoin. Deve spiegare chiaramente perché le specifiche del protocollo esistente sono inadeguate ad affrontare il problema che il BIP risolve. Le proposte prive di una motivazione sufficiente possono essere respinte definitivamente. + +- Logica -- La logica arricchisce la specifica descrivendo ciò che ha motivato la progettazione e le ragioni per cui sono state prese particolari decisioni. Dovrebbe descrivere i progetti alternativi che sono stati presi in considerazione e il lavoro correlato, ad esempio come la funzionalità è supportata in altri linguaggi. + +- La logica dovrebbe fornire prova del consenso all'interno della comunità e discutere importanti obiezioni o preoccupazioni sollevate durante la discussione. + +- Retro-compatibilità -- Tutti i BIP che introducono incompatibilità con le versioni precedenti devono includere una sezione che descriva tali incompatibilità e la loro gravità. Il BIP deve spiegare come l'autore propone di affrontarle. Le proposte senza un sufficiente trattato sulla retro-compatibilità possono essere rifiutate definitivamente. + +- Implementazione di riferimento -- L'implementazione di riferimento deve essere completata prima che al BIP venga assegnato lo stato "Final", ma non è necessario che sia completata prima che venga accettato. È meglio completare prima le specifiche e la logica, raggiungendo il consenso, e successivamente scrivere il codice. + +- L'implementazione finale deve includere il codice di test e la documentazione appropriata per il protocollo Bitcoin. + +## Formati e modelli di BIP + +
+ +I BIP devono essere scritti in formato mediawiki o markdown. + +### Preambolo dell'intestazione del BIP + +Ogni BIP deve iniziare con un preambolo d'intestazione in stile RFC 822. Le intestazioni devono apparire nel seguente ordine. Quelle contrassegnate con "*" sono opzionali e descritte di seguito. Tutte le altre sono obbligatorie. + +
+  BIP: <BIP number>
+  Title: <BIP title>
+  Author: <list of authors' real names and optionally, email addrs>
+* Discussions-To: <email address>
+  Status: <Draft | Active | Accepted | Deferred | Rejected |
+           Withdrawn | Final | Superseded>
+  Type: <Standards Track | Informational | Process>
+  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
+* Post-History: <dates of postings to bitcoin mailing list>
+* Replaces: <BIP number>
+* Superseded-By: <BIP number>
+* Resolution: <url>
+
+ +L'intestazione `Author` elenca i nomi e, facoltativamente, gli indirizzi email di tutti gli autori/proprietari del BIP. Il formato del suo valore deve essere + +
+  Random J. User 
+
+ +se l'indirizzo email è incluso, e solo + +
+  Random J. User
+
+ +se l'indirizzo non viene indicato. + +Se sono presenti più autori, ciascuno deve essere segnato in una riga separata seguendo le convenzioni di continuazione riga RFC 2822. + +Nota: l'intestazione Resolution è necessaria solo per gli *Standards Track* BIP. Contiene un URL che deve puntare a un messaggio di posta elettronica o a un'altra risorsa web in cui viene fatta la dichiarazione del BIP. + +Mentre un BIP è nelle discussioni private (di solito durante la fase iniziale di *Draft*), l'intestazione Discussions-To indicherà la mailing list o l'URL in cui il BIP viene discusso. Non è necessaria se il BIP viene discusso privatamente con l'autore o nelle mailing list di bitcoin. + +L'intestazione Type specifica il tipo di BIP: *Standards Track*, *Informational* o *Process*. + +L'intestazione Created registra la data in cui è stato assegnato un numero al BIP, mentre Post-History viene utilizzato per registrare le date in cui le nuove versioni del BIP sono state pubblicate nelle mailing list bitcoin. Entrambe le intestazioni devono essere nel formato aaaa-mm-gg, ad esempio 2001-08-14. + +I BIP possono avere un'intestazione Requires, che indica i numeri BIP da cui dipendono. + +I BIP possono anche avere un'intestazione Superseded-By, che indica che un BIP è stato reso obsoleto da un documento successivo; il valore è il numero del BIP che sostituisce il documento corrente. Quello più recente deve avere un'intestazione Replaces contenente il numero del BIP che ha reso obsoleto. + +### File ausiliari + +I BIP possono includere dei file ausiliari, come i diagrammi. I file immagine devono essere inclusi in una sottodirectory dedicata a quel BIP. I file ausiliari devono essere denominati BIP-XXXX-Y.ext, dove "XXXX" è il numero del BIP, "Y" è un numero di serie (a partire da 1) e "ext" è sostituito dall'estensione effettiva del file (ad esempio "png"). + +## Trasferimento della proprietà del BIP + +
+ +Occasionalmente è necessario trasferire la proprietà dei BIP a un nuovo sostenitore. In generale, vorremmo mantenere l'autore originale come co-autore del BIP trasferito, ma in realtà dipende lui. Una buona ragione per trasferire la proprietà è che l'autore originale non ha più il tempo o l'interesse per aggiornarlo o seguirne il processo, oppure è scomparso dalla rete (ovvero non è raggiungibile o non risponde alle email). Un cattivo motivo per trasferire la proprietà è perché non si è d'accordo con la direzione del BIP. Cerchiamo di costruire un consenso attorno a un BIP, ma se ciò non è possibile, si può sempre presentare un BIP concorrente. + +Se sei interessato ad assumere la proprietà di un BIP, invia un messaggio chiedendo di subentrare, indirizzato sia all'autore originale che all'editore del BIP. Se l'autore originale non risponde tempestivamente, l'editore prenderà una decisione unilaterale (non è detto che tali decisioni non possano essere cambiate :). + +## Editori del BIP + +
+ +L'attuale editore è Luke Dashjr, contattabile all'indirizzo . + +## Responsabilità e flusso di lavoro dell'editore del BIP + +
+ +L'editore si iscrive alla Bitcoin development mailing list. Tutta la corrispondenza relativa al BIP deve essere inviata (o inviata in CC) a . + +Per ogni nuovo BIP ricevuto, un editore esegue quanto segue: + +- Leggere il BIP per verificare se è pronto: valido e completo. Le idee devono avere un senso tecnico, anche se sembra improbabile che vengano accettate. +- Il titolo deve descrivere accuratamente il contenuto. +- Modificare il linguaggio (ortografia, grammatica, struttura delle frasi, ecc.), il markup (per i BIP reST), lo stile del codice (gli esempi devono corrispondere ai BIP 8 e 7). + +Se il BIP non è pronto, l'editore lo invia all'autore per la revisione, con istruzioni specifiche. + +Una volta che il BIP è pronto per il repository, deve essere inviato come "pull request" al repository [bitcoin/bips](https://github.com/bitcoin/bips) su GitHub, dove può ottenere ulteriori riscontri. + +L'editore successivamente: + +- Assegnerà un numero al BIP (quasi sempre il successivo numero disponibile, ma a volte si tratta di un numero speciale/scherzoso, come 666 o 3141) nei commenti della pull request. +- Unirà la pull request quando l'autore sarà pronto (concedendo del tempo per un'ulteriore revisione tra pari). +- Elencherà il BIP in [README.mediawiki](https://github.com/bitcoin/bips/blob/master/README.mediawiki) +- Invierà un'e-mail all'autore con i passi successivi (pubblica sulla mailing list bitcoin-dev). + +Gli editori del BIP hanno il compito di assolvere alle responsabilità amministrative ed editoriali. Loro monitorano le modifiche al BIP e correggono eventuali errori di struttura, grammatica, ortografia o markup che notano. + +## Storia + +
+ +Questo documento è stato derivato in gran parte dal PEP-0001 di Python. In molti punti il ​​testo è stato semplicemente copiato e modificato. Sebbene il testo del PEP-0001 sia stato scritto da Barry Varsavia, Jeremy Hylton e David Goodger, loro non sono responsabili del suo utilizzo nel processo di miglioramento di Bitcoin e non devono essere disturbati da domande tecniche specifiche su Bitcoin o sul processo dei BIP. Si prega di indirizzare tutti i commenti agli editori o alla Bitcoin development mailing list. + +## Registro delle modifiche + +
+ +10 ottobre 2015 - Aggiunti chiarimenti sul processo di invio e assegnazione del numero del BIP. + +01 gennaio 2016 - Chiarite le prime fasi di sostegno dell'idea di BIP, raccolta dei feedback della comunità, ecc. diff --git a/content/en/bitcoin/bips/bip-0002.md b/content/en/bitcoin/bips/bip-0002.md new file mode 100644 index 0000000..1f22900 --- /dev/null +++ b/content/en/bitcoin/bips/bip-0002.md @@ -0,0 +1,451 @@ +--- +title: "BIP-0002" +date: +draft: false +weight: 102 +images: [] +categories: [] +contributors: ["ilcompratoreconsapevole"] +--- + +[Originale](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) + +
  BIP: 2
+  Title: BIP process, revised
+  Author: Luke Dashjr <luke+bip@dashjr.org>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002
+  Status: Active 
+  Type: Process
+  Created: 2016-02-03
+  License: BSD-2-Clause  
+           OPL 
+  Replaces: 1
+ +# Sommario +[Abstract](#abstract) +[Copyright](#copyright) +[Flusso di lavoro BIP](#flusso-di-lavoro-bip) +  [Trasferimento della proprietà BIP](#trasferimento-della-proprietà-bip) +  [Redattori BIP](#redattori-bip) +  [Responsabilità e flusso di lavoro dell'editor BIP](#responsabilità-e-flusso-di-lavoro-delleditor-bip) +[Formato e struttura BIP](#formato-e-struttura-bip) +  [Specifica](#specifica) +    [Preambolo dell'intestazione BIP](#preambolo-dellintestazione-bip) +    [File ausiliari](#file-ausiliari) +[Tipi di BIP](#tipi-di-bip) +[Campo di stato del BIP](#campo-di-stato-del-bip) +  [Specifica](#specifica-1) +    [Progressione verso lo stato finale](#progressione-verso-lo-stato-finale) +  [Fondamento logico](#fondamento-logico) +[Commenti del BIP](#commenti-del-bip) +  [Specifica](#specifica-2) +  [Fondamento logico](#fondamento-logico) +[Licenza BIP](#licenza-bip) +  [Specifica](#specifica-3) +    [Licenze consigliate](#licenze-consigliate) +    [Licenze non consigliate ma accettabili](#licenze-non-consigliate-ma-accettabili) +    [Licenze non accettabili](#licenze-non-accettabili) +  [Fondamento logico](#fondamento-logico-2) +[Modifiche rispetto al BIP 1](#modifiche-rispetto-al-bip-1) +[Guarda anche](#guarda-anche) + +## Abstract + +
+ +Una Bitcoin Improvement Proposal (BIP) è un documento di progettazione che fornisce informazioni alla comunità Bitcoin o descrive una nuova funzionalità per Bitcoin o i suoi processi o ambiente. Il BIP dovrebbe fornire una specifica tecnica concisa della caratteristica e la motivazione della stessa. + +Intendiamo che i BIP siano il meccanismo principale per proporre nuove funzionalità, raccogliere input dalla comunità su un problema e documentare le decisioni di progettazione che sono entrate in Bitcoin. L'autore del BIP è responsabile della costruzione del consenso all'interno della comunità e della documentazione delle opinioni dissenzienti. + +Poiché i BIP vengono mantenuti come file di testo in un repository con versione, la cronologia delle revisioni è la registrazione storica della proposta di funzionalità. + +Questo particolare BIP sostituisce il BIP 1 con un processo più chiaro e ben definito. + +## Copyright + +
+ +Questo BIP è concesso in doppia licenza ai sensi della Open Publication License e della licenza BSD a 2 clausole. + +## Flusso di lavoro BIP + +
+ +Il processo BIP inizia con una nuova idea per Bitcoin. Ogni potenziale BIP deve avere un sostenitore: qualcuno che scrive il BIP utilizzando lo stile e il formato descritti di seguito, guida le discussioni nei forum appropriati e tenta di costruire il consenso della comunità attorno all'idea. Il campione BIP (aka Autore) dovrebbe prima tentare di accertare se l'idea è compatibile con BIP. Piccoli miglioramenti o patch a un particolare software spesso non richiedono la standardizzazione tra più progetti; questi non necessitano di un BIP e devono essere inseriti nel flusso di lavoro di sviluppo specifico del progetto pertinente con l'invio di patch al tracker dei problemi applicabile. Inoltre, sono state avanzate molte idee per cambiare Bitcoin che sono state rifiutate per vari motivi. Il primo passo dovrebbe essere quello di esaminare le discussioni passate per vedere se un'idea è stata presa in considerazione in precedenza e, in tal caso, quali problemi sono emersi nel suo sviluppo. Dopo aver analizzato il lavoro passato, il modo migliore per procedere è pubblicare la nuova idea sulla [mailing list di sviluppo Bitcoin](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev). + +Valutare pubblicamente un'idea prima di scrivere un BIP ha lo scopo di far risparmiare tempo sia al potenziale autore che alla comunità più ampia. Chiedere prima alla comunità Bitcoin se un'idea è originale aiuta a evitare di dedicare troppo tempo a qualcosa che sicuramente verrà rifiutato in base a discussioni precedenti (la ricerca su Internet non sempre risolve il problema). Aiuta anche a garantire che l'idea sia applicabile all'intera comunità e non solo all'autore. Solo perché un'idea sembra buona all'autore non significa che funzionerà per la maggior parte delle persone nella maggior parte delle aree in cui viene utilizzato Bitcoin. + +Una volta che il campione ha chiesto alla comunità Bitcoin se un'idea ha qualche possibilità di accettazione, una bozza BIP dovrebbe essere presentata alla [mailing list di sviluppo Bitcoin](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev). Ciò offre all'autore la possibilità di arricchire la bozza del BIP per renderla adeguatamente formattata, di alta qualità e per affrontare ulteriori preoccupazioni sulla proposta. Dopo una discussione, la proposta dovrebbe essere inviata al [repository git del BIP](https://github.com/bitcoin/bips) come richiesta pull. Questa bozza deve essere scritta in stile BIP come descritto di seguito e denominata con un alias come "bip-johndoe-infinitebitcoins" finché un editore non le assegna un numero BIP (gli autori NON DEVONO autoassegnare i numeri BIP). + +Gli autori del BIP sono responsabili della raccolta del feedback della comunità sia sull'idea iniziale che sul BIP prima di inviarlo per la revisione. Tuttavia, ove possibile, dovrebbero essere evitate lunghe discussioni aperte su mailing list pubbliche. Le strategie per mantenere efficienti le discussioni includono: impostare una mailing list SIG separata per l'argomento, fare in modo che l'autore del BIP accetti commenti privati ​​nelle prime fasi di progettazione, impostare una pagina wiki o un repository git, ecc. Gli autori BIP dovrebbero usare la loro riservatezza. + +Si consiglia vivamente che un singolo BIP contenga un'unica proposta chiave o una nuova idea. Più il BIP è mirato, maggiore sarà il successo che tende ad avere. In caso di dubbio, dividi il tuo BIP in più BIP ben mirati. + +Una volta completata la bozza del BIP, un editor BIP assegnerà al BIP un numero, lo etichetterà come Standards Track, Informational o Process e unirà la pull request al repository git del BIP. Gli editori del BIP non rifiuteranno irragionevolmente un BIP. Le ragioni per rifiutare i BIP includono la duplicazione degli sforzi, inosservanza delle regole di formattazione,, l'essere troppo vaghi o troppo ampi, essere tecnicamente non validi, non fornire una motivazione adeguata o affrontare la compatibilità con le versioni precedenti, o non essere in linea con la filosofia Bitcoin. Per essere accettato, un BIP deve soddisfare determinati criteri minimi. Deve trattarsi di una descrizione chiara e completa del miglioramento proposto. Il miglioramento deve rappresentare un miglioramento netto. L'implementazione proposta, se applicabile, deve essere solida e non deve complicare indebitamente il protocollo. + +L'autore del BIP può aggiornare la bozza secondo necessità nel repository git. Anche gli aggiornamenti alle bozze dovrebbero essere inviati dall'autore come pull request. + +### Trasferimento della proprietà BIP + +Occasionalmente diventa necessario trasferire la proprietà dei BIP a un nuovo campione. In generale, vorremmo mantenere l'autore originale come coautore del BIP trasferito, ma la decisione spetta all'autore originale. Un buon motivo per trasferire la proprietà è perché l'autore originale non ha più il tempo o l'interesse per aggiornarlo o portare a termine il processo BIP, o è scomparso dalla rete (ovvero non è raggiungibile o non risponde alle e-mail). Un cattivo motivo per trasferire la proprietà è perché non sei d'accordo con la direzione del BIP. Cerchiamo di creare consenso attorno a un BIP, ma se ciò non è possibile, puoi sempre inviare un BIP concorrente. + +Se sei interessato ad assumere la proprietà di un BIP, invia un messaggio di richiesta di subentro, indirizzato sia all'autore originale che ai curatori di BIP. Se l'autore originale non risponde all'e-mail in modo tempestivo, gli editori di BIP prenderanno una decisione unilaterale (non è che tali decisioni non possano essere annullate :). + +### Redattori BIP + +Gli attuali editor BIP sono: + +- Luke Dashjr [(luke_bipeditor@dashjr.org)](mailto:luke_bipeditor@dashjr.org) +- Kalle Alm [(karljohan-alm@garage.co.jp)](mailto:karljohan-alm@garage.co.jp) + +### Responsabilità e flusso di lavoro dell'editor BIP + +Gli editori di BIP si iscrivono alla mailing list di sviluppo Bitcoin. La corrispondenza relativa al BIP fuori elenco deve essere inviata (o inviata in CC) agli editori del BIP. + +Per ogni nuovo BIP che arriva in un editor fa quanto segue: + +- Leggere il BIP per verificare se è pronto: valido e completo. Le idee devono avere un senso tecnico, anche se sembra improbabile che vengano accettate. +- Il titolo dovrebbe descrivere accuratamente il contenuto. +- La bozza del BIP deve essere stata inviata alla mailing list di sviluppo Bitcoin per la discussione. +- La motivazione e la compatibilità con le versioni precedenti (se applicabile) devono essere affrontate. +- L'intestazione deve essere assegnata correttamente per la specifica data. +- I termini di licenza devono essere accettabili per i BIP. + +Se il BIP non è pronto, il curatore lo rispedirà all'autore per la revisione, con istruzioni specifiche. + +Una volta che il BIP è pronto per il repository, dovrebbe essere inviato come "pull request" al repository [git del BIP](https://github.com/bitcoin/bips) dove potrebbe ottenere ulteriore feedback. + +L'editor BIP: + +- Assegnare un numero BIP nella richiesta pull. +- Unisci la pull request quando è pronta. +- Elenca il BIP in [README.mediawiki](https://github.com/bitcoin/bips/blob/master/README.mediawiki) + +I redattori del BIP sono destinati ad adempiere alle responsabilità amministrative ed editoriali. Gli editor BIP monitorano le modifiche BIP e aggiornano le intestazioni BIP in modo appropriato. + +## Formato e struttura BIP + +
+ +### Specifica + +I BIP dovrebbero essere scritti in formato mediawiki o markdown. + +Ogni BIP dovrebbe avere le seguenti parti: + +- Preambolo: intestazioni contenenti metadati sul BIP [(vedi sotto)](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#user-content-BIP_header_preamble). + +- Abstract: una breve descrizione (~200 parole) del problema tecnico da affrontare. + +- Copyright: il BIP deve essere concesso in licenza esplicitamente in base a termini di copyright accettabili [(vedere di seguito)](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#user-content-BIP_licensing). + +- Specifica: la specifica tecnica dovrebbe descrivere la sintassi e la semantica di qualsiasi nuova funzionalità. Le specifiche dovrebbero essere sufficientemente dettagliate da consentire implementazioni concorrenti e interoperabili per qualsiasi delle attuali piattaforme Bitcoin. + +- Motivazione: la motivazione è fondamentale per i BIP che desiderano modificare il protocollo Bitcoin. Dovrebbe spiegare chiaramente perché il protocollo esistente è inadeguato ad affrontare il problema risolto dal BIP. + +- Fondamento logico: la logica arricchisce la specifica descrivendo ciò che ha motivato la progettazione e il motivo per cui sono state prese particolari decisioni di progettazione. Dovrebbe descrivere i progetti alternativi presi in considerazione e il lavoro correlato. La logica dovrebbe fornire prova del consenso all'interno della comunità e discutere importanti obiezioni o preoccupazioni sollevate durante la discussione. + +- Compatibilità con le versioni precedenti: tutti i BIP che introducono incompatibilità con le versioni precedenti devono includere una sezione che descriva tali incompatibilità e la loro gravità. Il BIP deve spiegare come l'autore propone di affrontare queste incompatibilità. + +- Implementazione di riferimento: l'implementazione di riferimento deve essere completata prima che a qualsiasi BIP venga assegnato lo stato "Finale", ma non è necessario che sia completata prima che il BIP venga accettato. È meglio completare prima le specifiche e la logica e raggiungere il consenso su di esse prima di scrivere il codice. L'implementazione finale deve includere il codice di test e la documentazione appropriata per il protocollo Bitcoin. + +#### Preambolo dell'intestazione BIP + +Ogni BIP deve iniziare con un preambolo di intestazione in stile RFC 822. Le intestazioni devono apparire nel seguente ordine. Le intestazioni contrassegnate con "*" sono facoltative e sono descritte di seguito. Tutte le altre intestazioni sono obbligatorie. + +
  BIP: <BIP number, or "?" before being assigned>
+* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
+  Title: <BIP title; maximum 44 characters>
+  Author: <list of authors' real names and email addrs>
+* Discussions-To: <email address>
+* Comments-Summary: <summary tone>
+  Comments-URI: <links to wiki page for comments>
+  Status: <Draft | Active | Proposed | Deferred | Rejected |
+          Withdrawn | Final | Replaced | Obsolete>
+  Type: <Standards Track | Informational | Process>
+  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
+  License: <abbreviation for approved license(s)>
+* License-Code: <abbreviation for code under different approved license(s)>
+* Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>   
+* Requires: <BIP number(s)>
+* Replaces: <BIP number>
+* Superseded-By: <BIP number>  
+
+ +L'intestazione Layer (solo per i BIP Standards Track) documenta a quale layer di Bitcoin si applica il BIP. Vedere [BIP 123](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki) per le definizioni dei vari livelli BIP. L'attivazione di questo BIP implica l'attivazione del BIP 123. + +L'intestazione Autore elenca i nomi e gli indirizzi email di tutti gli autori/proprietari del BIP. Il formato del valore dell'intestazione Autore deve essere + +
  Random J. User
+ +Se sono presenti più autori, ciascuno dovrebbe trovarsi su una riga separata seguendo le convenzioni della riga di continuazione RFC 2822. + +Mentre un BIP è in discussioni private (di solito durante la fase iniziale di Draft), un'intestazione Discussions-To indicherà la mailing list o l'URL in cui viene discusso il BIP. Non è necessaria alcuna intestazione Discussions-To se il BIP viene discusso privatamente con l'autore o nelle mailing list di bitcoin. + +L'intestazione Type specifica il tipo di BIP: Standards Track, Informational, o Process. + +L'intestazione Created registra la data in cui al BIP è stato assegnato un numero, mentre Post-History viene utilizzata per registrare quando nuove versioni del BIP vengono pubblicate nelle mailing list bitcoin. Le date devono essere nel formato aaaa-mm-gg, ad es. 2001-08-14. Post-History può essere un collegamento a un thread specifico in un archivio di mailing list. + +I BIP possono avere un'intestazione Requires, che indica i numeri BIP da cui dipende questo BIP. + +I BIP possono anche avere un'intestazione Superseded-By che indica che un BIP è stato reso obsoleto da un documento successivo; il valore è il numero del BIP che sostituisce il documento corrente. Il BIP più recente deve avere un'intestazione Replaces contenente il numero del BIP che ha reso obsoleto. + +#### File ausiliari + +I BIP possono includere file ausiliari come i diagrammi. I file ausiliari devono essere inclusi in una sottodirectory per quel BIP o devono essere denominati BIP-XXXX-Y.ext, dove "XXXX" è il numero BIP, "Y" è un numero di serie (a partire da 1) e "ext" viene sostituito dall'estensione effettiva del file (ad esempio "png"). + +## Tipi di BIP + +
+ +Esistono tre tipi di BIP: + +- Un Standards Track BIP descrive qualsiasi modifica che influisce sulla maggior parte o su tutte le implementazioni Bitcoin, come una modifica al protocollo di rete, una modifica nelle regole di validità del blocco o della transazione, o qualsiasi modifica o aggiunta che influisca sull'interoperabilità delle applicazioni che utilizzano Bitcoin. I BIP Standards Track sono costituiti da due parti, un documento di progettazione e un'implementazione di riferimento. + +- Un Informational BIP descrive un problema di progettazione di Bitcoin o fornisce linee guida generali o informazioni alla comunità Bitcoin, ma non propone una nuova funzionalità. I BIP informativi non rappresentano necessariamente un consenso o una raccomandazione della comunità Bitcoin, quindi gli utenti e gli implementatori sono liberi di ignorare i BIP Informativi o seguire i loro consigli. + +- Un Process BIP descrive un processo che circonda Bitcoin o propone una modifica a (o un evento in) un processo. I Process BIP sono come gli Standards Track BIP ma si applicano ad aree diverse dal protocollo Bitcoin stesso. Potrebbero proporre un'implementazione, ma non al codice base di Bitcoin; spesso richiedono il consenso della comunità; a differenza degli Informational BIP, sono più che semplici raccomandazioni e gli utenti in genere non sono liberi di ignorarli. Gli esempi includono procedure, linee guida, modifiche al processo decisionale e modifiche agli strumenti o all'ambiente utilizzato nello sviluppo di Bitcoin. Qualsiasi meta-BIP è anche considerato un BIP di processo. + +## Campo di stato del BIP + +
+ +### Specifica + +I percorsi tipici dello stato dei BIP sono i seguenti: + +![Processi BIP](/images/process2.png) + +I Campioni di un BIP possono decidere autonomamente di modificare lo stato tra Draft, Deferred o Withdrawn. Un editor BIP può anche modificare lo stato in Deferred quando non viene effettuato alcun progresso sul BIP. + +Un BIP può cambiare stato solo da Bozza (o Rifiutato) a Proposto, quando l'autore lo ritiene completo, ha un'implementazione funzionante (ove applicabile) e ha piani della comunità per portarlo allo stato Finale. + +I BIP dovrebbero essere modificati dallo stato di Bozza o Proposta allo stato di Rifiutato, su richiesta di qualsiasi persona, se non hanno fatto progressi in tre anni. Tale BIP può essere modificato nello stato di Bozza se il campione fornisce revisioni che affrontano in modo significativo le critiche pubbliche alla proposta, o nello stato di Proposta se soddisfa i criteri richiesti come descritto nel paragrafo precedente. + +Un BIP proposto può passare alla fase finale solo quando si sono verificati criteri specifici che riflettono l'adozione nel mondo reale. Questo è diverso per ciascun BIP a seconda della natura delle modifiche proposte, che verranno approfondite di seguito. La valutazione di questo cambiamento di stato dovrebbe essere oggettivamente verificabile e/o essere discussa nella mailing list di sviluppo. + +Quando un BIP Finale non è più rilevante, il suo stato può essere cambiato in Sostituito o Obsoleto (che equivale a Sostituito). Anche questo cambiamento deve essere oggettivamente verificabile e/o discusso. + +Un BIP di processo può cambiare stato da Bozza ad Attivo quando raggiunge un consenso approssimativo sulla mailing list. Si dice che tale proposta abbia un consenso approssimativo se è stata aperta alla discussione sulla mailing list di sviluppo per almeno un mese, e nessuno mantiene obiezioni circostanziate e non indirizzate ad essa. Le obiezioni affrontate o ostruttive possono essere ignorate/respinte previo accordo generale che siano state sufficientemente affrontate, ma in tali circostanze deve essere fornita una motivazione chiara. + +#### Progressione verso lo stato finale + +Un BIP soft-fork richiede rigorosamente una chiara maggioranza dei minatori espressa dal voto blockchain (ad esempio, utilizzando BIP 9). Inoltre, se l’economia sembra disposta a effettuare un hard fork di “sfiducia” (come ad esempio una modifica nell’algoritmo di prova del lavoro), il soft fork non diventa Finale finché tale hard fork potrebbe avere il sostegno della maggioranza, o al massimo tre mesi. I BIP soft-fork possono anche stabilire requisiti aggiuntivi per la loro adozione. A causa della possibilità di modifiche alle dinamiche dei miner, soprattutto alla luce del voto delegato (pool minerari), si raccomanda vivamente che il BIP stesso richieda un voto a maggioranza qualificata intorno al 95%, a meno che non venga fornita la motivazione per una soglia inferiore. + +Un BIP hard-fork richiede l’adozione da parte dell’intera economia Bitcoin, in particolare compresi coloro che vendono beni e servizi desiderabili in cambio di pagamenti in bitcoin, così come i detentori di Bitcoin che desiderano spendere o spenderebbero i loro bitcoin (inclusa la vendita per altre valute) in modo diverso in caso di un hard-fork così duro. L'adozione deve essere espressa attraverso l'uso de facto dell'hard fork nella pratica (vale a dire, non semplicemente esprimendo il sostegno pubblico, anche se questo è un buon passo per stabilire un accordo prima dell'adozione del BIP). Questa adozione economica non può essere stabilita semplicemente da una super-maggioranza, se non forzando letteralmente la minoranza ad accettare l’hard fork (che ciò sia fattibile o meno esula dallo scopo di questo documento). + +Il peer che revisiona dovrebbe osservare che i BIP siano adottati da almeno l’1% dei nodi di ascolto pubblici per un mese. + +API/RPC e BIP del livello applicativo devono essere implementati da almeno due applicazioni software indipendenti e compatibili. + +Gli autori di software sono incoraggiati a pubblicare riepiloghi di quali BIP sono supportati dal loro software per facilitare la verifica delle modifiche di stato. Buoni esempi di ciò al momento della stesura di questo BIP possono essere osservati nel file [doc/bips.md di Bitcoin Core](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md) e nel file [wallet/README.specs.md di Bitcoin Wallet per Android](https://github.com/bitcoin-wallet/bitcoin-wallet/blob/main/wallet/README.specs.md). + +Questi criteri sono considerati modalità oggettive per osservare l'adozione di fatto del BIP e non devono essere utilizzati come ragioni per opporsi o respingere un BIP. Qualora un BIP venisse effettivamente e inequivocabilmente adottato nonostante non soddisfi i criteri qui delineati, dovrebbe comunque essere aggiornato allo stato Finale. + +### Fondamento logico + +Perché è necessario? + +- Il BIP 1 definisce un criterio ambiguo per lo Stato del campo dei BIP, che è spesso fonte di confusione. Di conseguenza, molti BIP con un utilizzo significativo nel mondo reale sono stati lasciati allo stato di Bozza o Proposta più a lungo del necessario. Fornendo criteri oggettivi per giudicare la progressione dei BIP, questa proposta mira a contribuire a mantenere lo stato accurato e aggiornato. + +Come viene definita l'intera economia Bitcoin dalle persone che vendono beni/servizi e dagli Holders? + +- Affinché Bitcoin funzioni come valuta, deve essere accettato come pagamento. I Bitcoin non hanno valore se non puoi acquisire nulla in cambio di essi. Se tutti coloro che accettano tali pagamenti richiedono un particolare insieme di regole di consenso, i "bitcoin" sono di fatto definiti da quell'insieme di regole - questo è già il caso oggi. Se si prevede che tali regole di consenso si allarghino (come con un hard-fork), i commercianti dovranno accettare i pagamenti effettuati secondo la nuova serie di regole, altrimenti rifiuteranno i “bitcoin” in quanto non validi. I detentori sono importanti nella misura in cui scelgono i commercianti con cui desiderano spendere i loro bitcoin e potrebbero anche decidere di vendere in base a una serie di regole di consenso o all’altra, inondando così il mercato di bitcoin e facendo crollare il prezzo. + +Perché non sono inclusi nell'economia? + +- Alcune entità potrebbero, in una certa misura, anche essere coinvolte nell’offerta di beni e/o servizi in cambio di bitcoin, quindi in tale veste (ma non in quella di) essere coinvolte nell’economia. + +- I minatori non sono inclusi nell’economia, perché semplicemente *si affidano* ad altri per vendere/spendere i loro prodotti minerari altrimenti privi di valore. Pertanto, devono accettare la direzione di tutti gli altri nel decidere le regole del consenso. + +- Gli scambi non sono inclusi nell’economia, perché forniscono semplicemente servizi di collegamento tra commercianti e utenti che desiderano commerciare. Anche se tutti gli scambi dovessero abbandonare Bitcoin, quei commercianti e utenti possono sempre commerciare direttamente e/o creare i propri scambi. + +- Gli sviluppatori non sono inclusi nell’economia, poiché si limitano a scrivere codice, e spetta ad altri decidere se utilizzare quel codice o meno. + +Ma stanno facendo qualcosa di importante e hanno investito molto in Bitcoin! Non dovrebbero essere coinvolti in una decisione così importante? + +- Questo BIP non mira ad affrontare ciò che "dovrebbe" essere la base delle decisioni. Una tale affermazione, non importa quanto perfetta nella sua giustificazione, sarebbe inutile senza un modo per costringere gli altri a usarla. Il processo BIP non mira ad essere una sorta di "governance" forzata di Bitcoin, ma semplicemente a fornire un archivio collaborativo per proporre e fornire informazioni sugli standard, che le persone possono adottare volontariamente o meno. Si può solo sperare di raggiungere la precisione per quanto riguarda il campo "Stato", sforzandosi di riflettere la realtà di *come sono effettivamente le cose*, piuttosto che *come dovrebbero essere*. + +Cosa succede se un singolo commerciante desidera bloccare un hard fork? + +- Questo BIP riguarda solo la progressione del campo Stato BIP, non l'implementazione dell'hard fork (o qualsiasi altra modifica) stessa. + +- In ogni caso, un negozio non può operare nel vuoto: se fosse davvero solo, presto si ritroverebbe a non vendere più in cambio di pagamenti in bitcoin, poiché nessun altro sarebbe disposto a utilizzare la precedente blockchain per pagarlo. Se non vendono più, cessano di soddisfare i criteri qui stabiliti che consentono il loro veto. + +Che ne dici di un piccolo numero di commercianti (forse solo due) che vendono prodotti tra loro? + +- In questo scenario, sembrerebbe che il precedente Bitcoin sia vivo e funzionante e che l’hard fork abbia fallito. Come risolvere tale divisione non rientra nell'ambito di questo BIP. + +Come può un accordo economico porre il veto a un soft-fork? + +- Il gruppo di minatori è determinato dalle regole di consenso per la firma multiparte ad adesione dinamica (per Bitcoin, l'algoritmo di prova del lavoro), che può essere modificato con un hard fork. Pertanto, se le stesse condizioni richieste per modificare questo gruppo vengono soddisfatte in opposizione a un soft-fork, la maggioranza dei minatori che sostiene il soft-fork è effettivamente nullo perché l’economia può decidere di sostituirli con un altro gruppo di aspiranti minatori che lo fanno i quali non supportano il soft-fork. + +Cosa succede se l’economia decide di abbandonare una controversa soft-fork, più di tre mesi dopo? + +- Il controverso soft-fork, in questa circostanza, cambia dallo stato Final a Replaced per riflettere la natura dell'hard-fork che sostituisce il precedente (finale) soft-fork. + +Qual è la percentuale ideale di nodi di ascolto necessaria per adottare proposte di servizi peer? + +- Questo è sconosciuto e fissato in modo piuttosto arbitrario in questo momento. Affinché una selezione casuale di peer abbia almeno un altro peer che implementi l'estensione, sarebbe necessario il 13% o più, ma i nodi potrebbero continuare a scansionare la rete alla ricerca di tali peer con forse un discreto successo. Inoltre, esistono bit di servizio per facilitare l'identificazione in anticipo. + +Perché è necessario che almeno due progetti software rilascino un'implementazione di API/RPC e BIP del livello applicativo, prima che diventino definitivi? + +- Se esiste una sola implementazione di una specifica, non esiste nessun altro programma per il quale viene utilizzata o necessaria un'interfaccia standard. + +- Anche se ci sono solo due progetti anziché più, esiste un coordinamento standard tra loro. + +Cosa succede se viene proposto un BIP che ha senso solo per un singolo progetto specifico? + +- Il processo BIP esiste per la standardizzazione tra progetti indipendenti. Se qualcosa riguarda solo un progetto, dovrebbe essere fatto attraverso i processi interni di quel progetto e in primo luogo non essere mai proposto come BIP. + +## Commenti del BIP + +
+ +### Specifica + +Ogni BIP dovrebbe, nel suo preambolo, collegarsi ad una pagina wiki pubblica con un riepilogo dei commenti su quella pagina. I revisori del BIP che si considerano qualificati dovrebbero pubblicare i propri commenti su questa pagina wiki. La pagina dei commenti dovrebbe generalmente essere utilizzata solo per pubblicare commenti finali per un BIP completato. Se un BIP non è ancora stato completato, i revisori dovrebbero invece postare sul thread della mailing list di sviluppo applicabile per consentire agli autori del BIP di affrontare eventuali preoccupazioni o problemi evidenziati dalla revisione. + +Alcuni BIP ricevono visibilità al di fuori della comunità di sviluppo prima del completamento, mentre altri BIP potrebbero non essere completati affatto. Per evitare una situazione in cui le revisioni BIP critiche possano passare inosservate durante questo periodo, i revisori possono, a loro discrezione, pubblicare comunque la propria revisione sulla pagina dei commenti, a condizione che la pubblichino prima nella mailing list e pianifichino di rimuoverla o revisionarla successivamente, a seconda dei casi, sulla base della versione completata. Tali revisioni dovrebbero essere effettuate modificando la revisione precedente e aggiornando il timestamp. Le recensioni effettuate prima della versione completa potrebbero essere rimosse se non sono più applicabili e non sono state aggiornate in modo tempestivo (ad esempio, entro un mese). + +Le pagine devono essere nominate con il numero BIP completo (ad esempio, "BIP 0001") e inserite nel namespace "Comments". Ad esempio, il collegamento per BIP 1 sarà [https://github.com/bitcoin/bips/wiki/Comments:BIP-0001](https://github.com/bitcoin/bips/wiki/Comments:BIP-0001). + +I commenti pubblicati su questa wiki dovrebbero utilizzare il seguente formato: + +
    <Your opinion> --<Your name>, <Date of posting, as YYYY-MM-DD>
+ +I BIP possono anche scegliere di elencare un secondo forum per i commenti BIP, oltre al wiki dei BIP. In questo caso, l'URI del secondo forum dovrebbe essere elencato sotto l'URI del wiki principale. + +Dopo qualche tempo il BIP stesso potrà essere aggiornato con un tono riepilogativo dei commenti. I toni di riepilogo possono essere scelti tra i seguenti, ma questo BIP non intende coprire tutte le possibili sfumature e altri riassunti possono essere utilizzati secondo necessità: + +- Ancora nessun commento. +- Consigliato all'unanimità per l'attuazione +- Scoraggiare all'unanimità l'attuazione +- Per lo più consigliato per l'implementazione, con qualche scoraggiamento +- Per lo più scoraggiata l'implementazione, con qualche raccomandazione + +Ad esempio, il preambolo di BIP 1 potrebbe essere aggiornato per includere la riga: + +
+    Comments-Summary: No comments yet.
+    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
+                  https://some-other-wiki.org/BIP_1_Comments
+
+ +Questi campi devono seguire l'intestazione "Discussions-To" definita nel BIP 1 (se tale intestazione non è presente, dovrebbe seguire la posizione in cui sarebbe presente; generalmente questa è immediatamente sopra l'intestazione dello stato). + +Per evitare dubbi: commenti e stato sono parametri non correlati per giudicare un BIP e nessuno dei due dovrebbe influenzare direttamente l'altro. + +### Fondamento logico + +Qual è lo scopo dei commenti BIP? + +- Sono stati adottati diversi BIP (criteri necessari per lo Status “Finale”) pur essendo considerati generalmente sconsigliabili. Alcuni attualmente considerano i BIP come una "buona idea" semplicemente in virtù del fatto che è stato assegnato loro un numero BIP. A causa della bassa barriera di ingresso per la presentazione di nuovi BIP, sembra consigliabile che i revisori possano esprimere le loro opinioni su di essi in modo che siano utilizzabili dal pubblico senza la necessità di rivedere l'intera discussione sullo sviluppo. + +I commenti BIP verranno censurati o limitati a particolari partecipanti/"esperti"? + +- I partecipanti dovrebbero astenersi liberamente dal commentare al di fuori della loro area di conoscenza o competenza. Tuttavia, i commenti non dovrebbero essere censurati e la partecipazione dovrebbe essere aperta al pubblico. + +## Licenza BIP + +
+ +### Specifica + +Nuovi BIP possono essere accettati con le seguenti licenze. Ogni nuovo BIP deve identificare almeno una licenza accettabile nel suo preambolo. L'intestazione License nel preambolo deve essere posizionata dopo l'intestazione Created. Ciascuna licenza deve fare riferimento alla rispettiva abbreviazione fornita di seguito. + +Ad esempio, un preambolo potrebbe includere la seguente intestazione di licenza: + +
    License: BSD-2-Clause
+             GNU-All-Permissive
+ +In questo caso, il testo BIP è completamente concesso in licenza sia in base alla licenza BSD a 2 clausole approvata dall'OSI sia alla licenza GNU All-Permissive, e chiunque può modificare e ridistribuire il testo purché rispetti i termini di *entrambe* le licenze . In altre parole, l'elenco delle licenze è una "scelta OR", non un requisito "AND". + +È anche possibile concedere in licenza il codice sorgente in modo diverso dal testo BIP. Un'intestazione License-Code opzionale viene inserita dopo l'intestazione License. Anche in questo caso, ciascuna licenza deve fare riferimento alla rispettiva abbreviazione fornita di seguito. + +Ad esempio, un preambolo che specifica l'intestazione License-Code opzionale potrebbe essere simile a: + +
    License: BSD-2-Clause
+             GNU-All-Permissive
+    License-Code: GPL-2.0+
+ +In questo caso, il codice nel BIP non è disponibile sotto le licenze BSD o All-Permissive, ma solo secondo i termini della GNU General Public License (GPL), versione 2 o successiva. Se il codice fosse disponibile esattamente *solo* nella versione 2, il simbolo "+" dovrebbe essere rimosso dall'abbreviazione della licenza. Per una versione successiva (ad esempio, GPL 3.0), dovresti aumentare il numero di versione (e mantenere o rimuovere il "+" a seconda dell'intento). + +
    License-Code: GPL-2.0   # This refers to GPL v2.0 *only*, no later license versions are acceptable.    
+    License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.
+    License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.
+    License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.
+ +Nel caso in cui la licenza per il testo o il codice sia troppo complicata per essere espressa con un semplice elenco di alternative, l'elenco dovrebbe invece essere sostituito con il solo termine "Complex". In tutti i casi, i dettagli dei termini di licenza devono essere forniti nella sezione Copyright del BIP. + +Non è necessario che i BIP siano concessi in licenza *esclusivamente* secondo termini approvati e possono anche essere concessi in licenza con licenze inaccettabili *oltre a* almeno una licenza accettabile. In questo caso, solo le licenze accettabili dovrebbero essere elencate nelle intestazioni License e License-Code. + +#### Licenze consigliate + +- BSD-2-Clause: [OSI-approved BSD 2-clause license](https://opensource.org/licenses/BSD-2-Clause) +- BSD-3-Clause: [OSI-approved BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause) +- CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/) +- GNU-All-Permissive: [GNU All-Permissive License](http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html) + +Inoltre, si consiglia che il codice letterale incluso nel BIP abbia una doppia licenza con gli stessi termini di licenza del progetto che modifica. Ad esempio, il codice letterale destinato a Bitcoin Core avrebbe idealmente una doppia licenza secondo i termini della licenza MIT e una delle precedenti con il resto del testo BIP. + +#### Licenze non consigliate ma accettabili + +- Apache-2.0: [Apache License, version 2.0](http://www.apache.org/licenses/LICENSE-2.0) +- BSL-1.0: [Boost Software License, version 1.0](http://www.boost.org/LICENSE_1_0.txt) +- CC-BY-4.0: [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/) +- CC-BY-SA-4.0: [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/) +- MIT: [Expat/MIT/X11 license](https://opensource.org/licenses/MIT) +- AGPL-3.0+: [GNU Affero General Public License (AGPL), version 3 or newer](http://www.gnu.org/licenses/agpl-3.0.en.html) +- FDL-1.3: [GNU Free Documentation License, version 1.3](http://www.gnu.org/licenses/fdl-1.3.en.html) +- GPL-2.0+: [GNU General Public License (GPL), version 2 or newer](http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html) +- LGPL-2.1+: [GNU Lesser General Public License (LGPL), version 2.1 or newer](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html) + +#### Licenze non accettabili + +Tutte le licenze non esplicitamente incluse negli elenchi di cui sopra non sono termini accettabili per una proposta di miglioramento Bitcoin a meno che un BIP successivo non estenda questa per aggiungerle. Tuttavia, i BIP precedenti all'accettazione di questo BIP erano consentiti in base ad altri termini e dovrebbero utilizzare queste abbreviazioni quando non viene concessa nessun'altra licenza: + +- OPL: [Open Publication License, version 1.0](http://opencontent.org/openpub/) +- PD: Released into the public domain + +### Fondamento logico + +BIP 1 ha consentito la Open Publication License o il rilascio nel pubblico dominio; era insufficiente? + +- L'OPL è generalmente considerata obsoleta e non una licenza adatta a nuove pubblicazioni. +- Molti non hanno familiarità con i termini OPL e potrebbero semplicemente preferire utilizzare il dominio pubblico piuttosto che concedere in licenza a termini incerti. +- I termini della licenza OPL consentivano all'autore di impedire la pubblicazione e i lavori derivati, il che era ampiamente considerato inappropriato per gli standard Bitcoin. +- Il dominio pubblico non è universalmente riconosciuto come un'azione legittima, quindi è sconsigliabile. + +Perché sono incluse le licenze software? + +- Alcuni BIP, in particolare il livello di consenso, possono includere codice letterale nel BIP stesso che potrebbe non essere disponibile secondo gli esatti termini di licenza del BIP. +- Nonostante ciò, non tutte le licenze software sarebbero accettabili per i contenuti inclusi nei BIP. + +Perché il dominio pubblico non è più accettabile per i nuovi BIP? + +- In alcune giurisdizioni, il dominio pubblico non è riconosciuto come un'azione legale legittima, lasciando il BIP semplicemente protetto da copyright senza alcuna ridistribuzione o modifica consentita. + +## Modifiche rispetto al BIP 1 + +
+ +- Le licenze accettabili vengono completamente riselezionate, consentendo un'ampia varietà di licenze aperte, vietando al contempo le vecchie scelte problematiche. +- Lo stato Accettato è stato rinominato Proposto. +- Ora è necessaria un'implementazione (se applicabile) prima che i BIP possano procedere allo stato di proposta. +- I commenti BIP sono stati introdotti di recente. +- Sono state aggiunte le intestazioni del preambolo della licenza. +- L'intestazione del livello è inclusa da BIP 123. +- Nella sottodirectory bip-XXXX sono consentiti file ausiliari non di immagine. +- Gli indirizzi email sono ora obbligatori per gli autori. +- L'intestazione Post-History può essere fornita come collegamento anziché come semplice data. +- L'intestazione Risoluzione è stata eliminata, poiché non è applicabile a un sistema decentralizzato in cui non esiste alcuna autorità per prendere decisioni finali. + +## Guarda anche + +
+ +- [BIP 1: BIP Purpose and Guidelines](https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki) +- [BIP 123: BIP Classification](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki) +- [RFC 7282: On Consensus and Humming in the IETF](https://tools.ietf.org/html/rfc7282) \ No newline at end of file diff --git a/content/en/bitcoin/bips/bip-README.md b/content/en/bitcoin/bips/bip-README.md new file mode 100755 index 0000000..7f211d2 --- /dev/null +++ b/content/en/bitcoin/bips/bip-README.md @@ -0,0 +1,20 @@ +--- +title: "BIP-README" +description: "" +date: +draft: false +weight: 100 +images: [] +categories: [] +contributors: ["ilcompratoreconsapevole"] +--- + +[Originale](https://github.com/bitcoin/bips/blob/master/README.mediawiki) + +Le persone che desiderano inviare un BIP, devono prima proporre la loro idea o documento alla mailing list [bitcoin-dev@lists.linuxfoundation.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev) (non assegnare un numero - leggi [BIP 2]() per l'intero processo). Dopo la discussione, si prega di aprire una PR. Successivamente alla revisione e accettazione, verrà pubblicato qui. + +Siamo abbastanza liberali nell’approvazione dei BIP e cerchiamo di non essere troppo coinvolti nel processo decisionale per conto della comunità. L'eccezione avviene in casi molto rari di risoluzione delle controversie quando una decisione non può essere concordata. In questi casi, l’opzione conservativa sarà sempre preferita. + +Avere un BIP nella lista non lo rende uno standard formalmente accettato finché il suo stato non diventa Final o Active (N.d.T. in italiano *Finale o Attivo*). + +Coloro che propongono modifiche dovrebbero considerare che, in ultima analisi, il consenso potrebbe dipendere dal consenso degli utenti Bitcoin (vedi anche: [maggioranza economica](https://en.bitcoin.it/wiki/Economic_majority)). \ No newline at end of file diff --git a/content/en/contributors/Ilcompratoreconsapevole/_index.md b/content/en/contributors/Ilcompratoreconsapevole/_index.md new file mode 100644 index 0000000..54749b9 --- /dev/null +++ b/content/en/contributors/Ilcompratoreconsapevole/_index.md @@ -0,0 +1,7 @@ +--- +title: "Ilcompratoreconsapevole" +date: 2023-11-15T01:11:07+01:00 +draft: false +--- + +Matrice economica Austriaca e sostenitore del libertarismo. \ No newline at end of file diff --git a/layouts/partials/head/stylesheet.html b/layouts/partials/head/stylesheet.html index 4dc25c0..8854e2e 100644 --- a/layouts/partials/head/stylesheet.html +++ b/layouts/partials/head/stylesheet.html @@ -2,6 +2,7 @@ {{ $options := (dict "targetPath" "main.css" "enableSourceMap" true "includePaths" (slice "node_modules")) -}} {{ $css := resources.Get "scss/app.scss" | toCSS $options -}} + {{ else -}} {{ $options := (dict "targetPath" "main.css" "outputStyle" "compressed" "includePaths" (slice "node_modules")) -}} {{ $css := resources.Get "scss/app.scss" | toCSS $options | postCSS (dict "config" "config/postcss.config.js") -}} diff --git a/static/css/styles.css b/static/css/styles.css new file mode 100644 index 0000000..7112c96 --- /dev/null +++ b/static/css/styles.css @@ -0,0 +1,18 @@ +.summary { + float: left; + margin-top: -0.2em; + line-height: 1; + margin-right: .2em; +} + +.bip_preamble { + background-color : #f6f8fa; + padding : 16px; + overflow: auto; + border-radius: 6px; + color: black; +} + +.summary::after { + content: "⌞"; +} \ No newline at end of file