diff options
author | Mike Hearn <mike@plan99.net> | 2013-06-19 15:20:10 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-19 13:20:18 +0000 |
commit | d88330df25b1ec8b75621510497f2f36c87b1386 (patch) | |
tree | 6d21698ff31a6dab2845bdb5bb2a9e7b15704c7d | |
parent | 9efd4126f662ec3dea67b7f9e95e405dfaa8b9e6 (diff) | |
download | pi-bitcoindev-d88330df25b1ec8b75621510497f2f36c87b1386.tar.gz pi-bitcoindev-d88330df25b1ec8b75621510497f2f36c87b1386.zip |
Re: [Bitcoin-development] Missing fRelayTxes in version message
-rw-r--r-- | be/97f00a7813b2416e22a7f0412526675363afaa | 518 |
1 files changed, 518 insertions, 0 deletions
diff --git a/be/97f00a7813b2416e22a7f0412526675363afaa b/be/97f00a7813b2416e22a7f0412526675363afaa new file mode 100644 index 000000000..aa90ac9e9 --- /dev/null +++ b/be/97f00a7813b2416e22a7f0412526675363afaa @@ -0,0 +1,518 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1UpIJ7-0006sL-Vf + for bitcoin-development@lists.sourceforge.net; + Wed, 19 Jun 2013 13:20:18 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.175 as permitted sender) + client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; + helo=mail-ob0-f175.google.com; +Received: from mail-ob0-f175.google.com ([209.85.214.175]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1UpIJ6-0006uP-Fu + for bitcoin-development@lists.sourceforge.net; + Wed, 19 Jun 2013 13:20:17 +0000 +Received: by mail-ob0-f175.google.com with SMTP id xn12so5894040obc.20 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 19 Jun 2013 06:20:11 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.33.234 with SMTP id u10mr1995427oei.29.1371648011018; + Wed, 19 Jun 2013 06:20:11 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.23.36 with HTTP; Wed, 19 Jun 2013 06:20:10 -0700 (PDT) +In-Reply-To: <BLU404-EAS74077C5D43EACD319CCA3DA58D0@phx.gbl> +References: <BLU404-EAS74077C5D43EACD319CCA3DA58D0@phx.gbl> +Date: Wed, 19 Jun 2013 15:20:10 +0200 +X-Google-Sender-Auth: wXzSPY6o6xss6XM8SSlyaZTXuus +Message-ID: <CANEZrP0Pr=_L7CA4hdt9esVCHqf-EOjfDjnVrw8rFxL1OtUw7A@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Paul Lyon <pmlyon@hotmail.ca> +Content-Type: multipart/alternative; boundary=089e013c7042742a4204df81b023 +X-Spam-Score: -0.2 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 0.3 HTML_FONT_FACE_BAD BODY: HTML font face is not a word + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1UpIJ6-0006uP-Fu +Cc: "bitcoin-development@lists.sourceforge.net" + <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 19 Jun 2013 13:20:18 -0000 + +--089e013c7042742a4204df81b023 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +If you want to criticise the Bitcoin protocol for sloppyness, the variable +length of some messages isn't where I'd start. + +Note that ping has the same issue, its length has changed over time to +include the nonce. + +If your parser can't handle that kind of thing, you need to fix it. The +protocol has always worked that way. + + + +On Wed, Jun 19, 2013 at 3:03 PM, Paul Lyon <pmlyon@hotmail.ca> wrote: + +> I=E2=80=99m also running into this exact same issue with my parser, now I +> understand why the relay field behavior I was seeing doesn=E2=80=99t matc= +h the wiki. +> +> So to parse a version message, you can=E2=80=99t rely on the protocol ver= +sion? You +> have to know how long the payload is, and then parse the message +> accordingly? I agree with Turkey Breast, this seems a bit sloppy to me. +> +> Paul +> +> P.S. I=E2=80=99ve never used a dev mailing list before and I want to get = +involved +> with the Bitcoin dev community, so let me know if I=E2=80=99m horribly vi= +olating +> any mailing list etiquette. =F0=9F=98=8A +> +> *From:* Mike Hearn +> *Sent:* =E2=80=8EWednesday=E2=80=8E, =E2=80=8EJune=E2=80=8E =E2=80=8E19= +=E2=80=8E, =E2=80=8E2013 =E2=80=8E7=E2=80=8E:=E2=80=8E43=E2=80=8E =E2=80=8E= +AM +> *To:* Turkey Breast +> *Cc:* bitcoin-development@lists.sourceforge.net +> +> Bitcoin-Qt on master does send it now although it doesn't affect anything= +, +> but as old pre-filtering versions will continue to exist, you'll always +> have to be able to deserialize version messages without it. +> +> Bitcoin version messages have always had variable length, look at how the +> code is written in main.cpp. If you didn't experience issues until now al= +l +> it means is that no sufficiently old nodes were talking to yours. +> +> The standard does not say it should appear. Read it again - BIP 37 says +> about the new version message field: +> If false then broadcast transactions will not be announced until a +> filter{load,add,clear} command is received. *If missing or true*, no +> change in protocol behaviour occurs. +> +> +> On Wed, Jun 19, 2013 at 12:33 PM, Turkey Breast <turkeybreast@yahoo.com>w= +rote: +> +>> It's a problem if you work with iterators to deserialize the byte stream= +. +>> Even failing that, it's just sloppy programming. What happens in the fut= +ure +>> when new fields are added to the version message? It's not a big deal to +>> say that this protocol version has X number of fields, that (higher) +>> protocol version message has X + N number of fields. Deterministic numbe= +r +>> of fields per protocol version is sensical and how Bitcoin has been for = +a +>> long time. +>> +>> And yes, it was a problem for me that caused a lot of confusion why this +>> byte didn't exist in many version messages despite the standard saying i= +t +>> should and the code in bitcoind indicating it should. Nowhere was this +>> written. It doesn't help other implementations to have an unclear behavi= +our +>> that depends on some magic from one implementation. +>> +>> ------------------------------ +>> *From:* Mike Hearn <mike@plan99.net> +>> *To:* Turkey Breast <turkeybreast@yahoo.com> +>> *Cc:* "bitcoin-development@lists.sourceforge.net" < +>> bitcoin-development@lists.sourceforge.net> +>> *Sent:* Wednesday, June 19, 2013 11:39 AM +>> +>> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version +>> message +>> +>> It has to be optional because old clients don't send it, obviously. +>> +>> Why is this even an issue? There's no problem with variable length +>> messages in any codebase that I'm aware of. Is this solving some actual +>> problem? +>> +>> +>> On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast <turkeybreast@yahoo.com>= +wrote: +>> +>> That's me. I never said to make all messages fixed length. I said to mak= +e +>> a fixed number of fields per protocol. So given a protocol version numbe= +r, +>> you know the number of fields in a message. This is not only easier for +>> parsing messages, but just good practice. I don't see why a 1 byte flag +>> needs to be optional anyway. +>> +>> ------------------------------ +>> *From:* Mike Hearn <mike@plan99.net> +>> *To:* Turkey Breast <turkeybreast@yahoo.com> +>> *Cc:* Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +>> *Sent:* Tuesday, June 18, 2013 9:48 PM +>> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version +>> message +>> +>> It's not a bug (although there was recently a change to make bitcoind/qt +>> always send this field anyway). +>> +>> I don't know where Amir is going with BIP 60. Version messages have +>> always been variable length. There's nothing inherent in the Bitcoin +>> protocol that says all messages are fixed length, indeed, tx messages ar= +e +>> allowed to have arbitrary data appended after them that gets relayed. +>> +>> +>> On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast <turkeybreast@yahoo.com>w= +rote: +>> +>> See this BIP. I'm not sure if this is a bug or what, but it would be goo= +d +>> if messages always had a fixed number of fields per protocol version. +>> +>> https://en.bitcoin.it/wiki/BIP_0060#Code_Updates +>> +>> This BIP details everything that needs to be done and proposes a protoco= +l +>> upgrade. +>> +>> +>> ------------------------------------------------------------------------= +------ +>> This SF.net <http://sf.net/> email is sponsored by Windows: +>> +>> Build for Windows Store. +>> +>> http://p.sf.net/sfu/windows-dev2dev +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> +>> +>> +>> +>> +>> +>> ------------------------------------------------------------------------= +------ +>> This SF.net email is sponsored by Windows: +>> +>> Build for Windows Store. +>> +>> http://p.sf.net/sfu/windows-dev2dev +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> +>> +>> +>> +>> +>> +>> ------------------------------------------------------------------------= +------ +>> This SF.net email is sponsored by Windows: +>> +>> Build for Windows Store. +>> +>> http://p.sf.net/sfu/windows-dev2dev +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> +>> +> + +--089e013c7042742a4204df81b023 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">If you want to criticise the Bitcoin protocol for sloppyne= +ss, the variable length of some messages isn't where I'd start.<div= +><br></div><div>Note that ping has the same issue, its length has changed o= +ver time to include the nonce.</div> +<div><br></div><div style>If your parser can't handle that kind of thin= +g, you need to fix it. The protocol has always worked that way.</div><div s= +tyle><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail= +_quote"> +On Wed, Jun 19, 2013 at 3:03 PM, Paul Lyon <span dir=3D"ltr"><<a href=3D= +"mailto:pmlyon@hotmail.ca" target=3D"_blank">pmlyon@hotmail.ca</a>></spa= +n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= +order-left:1px #ccc solid;padding-left:1ex"> +<div><div dir=3D"ltr" style=3D"font-family:Calibri,'Segoe UI',Meiry= +o,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun = +Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',= +Ebrima,sans-serif;font-size:12pt"> +<div>I=E2=80=99m also running into this exact same issue with my parser, no= +w I understand why the relay field behavior I was seeing=C2=A0doesn=E2=80= +=99t match the wiki.</div><div>=C2=A0</div><div>So to parse a version messa= +ge, you can=E2=80=99t rely on the protocol version? You have to know how lo= +ng the payload is, and then parse the message accordingly? I agree with Tur= +key Breast, this seems a bit sloppy to me.</div> +<div>=C2=A0</div><div>Paul</div><div>=C2=A0</div><div>P.S. I=E2=80=99ve nev= +er used a dev mailing list before and I want to get involved with the Bitco= +in dev community, so let me know if I=E2=80=99m horribly violating any=C2= +=A0mailing list etiquette. <span style=3D"font-family:"Segoe UI Symbol= +","Apple Color Emoji"">=F0=9F=98=8A</span></div> +<div>=C2=A0</div><div style=3D"padding-top:5px;border-top-color:rgb(229,229= +,229);border-top-width:1px;border-top-style:solid"><div><font face=3D"Calib= +ri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsof= +t JhengHei UI', 'Malgun Gothic', 'Khmer UI', 'Nirma= +la UI', Tunga, 'Lao UI', Ebrima, sans-serif" style=3D"line-heig= +ht:15pt;letter-spacing:0.02em;font-family:Calibri,"Segoe UI",Meir= +yo,"Microsoft YaHei UI","Microsoft JhengHei UI","M= +algun Gothic","Khmer UI","Nirmala UI",Tunga,"= +Lao UI",Ebrima,sans-serif;font-size:11pt"><b>From:</b>=C2=A0Mike Hearn= +<br> +<b>Sent:</b>=C2=A0=E2=80=8EWednesday=E2=80=8E, =E2=80=8EJune=E2=80=8E =E2= +=80=8E19=E2=80=8E, =E2=80=8E2013 =E2=80=8E7=E2=80=8E:=E2=80=8E43=E2=80=8E = +=E2=80=8EAM<br><b>To:</b>=C2=A0Turkey Breast<br><b>Cc:</b>=C2=A0<a href=3D"= +mailto:bitcoin-development@lists.sourceforge.net" target=3D"_blank">bitcoin= +-development@lists.sourceforge.net</a></font></div> +</div><div><div class=3D"h5"><div>=C2=A0</div><div dir=3D"ltr">Bitcoin-Qt o= +n master does send it now although it doesn't affect anything, but as o= +ld pre-filtering versions will continue to exist, you'll always have to= + be able to deserialize version messages without it.<div> + +<br></div><div>Bitcoin version messages have always had variable length, lo= +ok at how the code is written in main.cpp. If you didn't experience iss= +ues until now all it means is that no sufficiently old nodes were talking t= +o yours.</div> + +<div><br></div><div>The standard does not say it should appear. Read it aga= +in - BIP 37 says about the new version message field:</div><div><table styl= +e=3D"line-height:19.2px;border-collapse:collapse;font-size:12.8px;backgroun= +d-color:rgb(249,249,249);font-family:sans-serif;margin:1em 0px;border:1px s= +olid rgb(170,170,170)"> + +<tbody><tr><td style=3D"padding:0.2em;border:1px solid rgb(170,170,170)">If= + false then broadcast transactions will not be announced until a filter{loa= +d,add,clear} command is received. <b>If missing or true</b>, no change in p= +rotocol behaviour occurs.<br> + +</td></tr></tbody></table></div></div><div class=3D"gmail_extra"><br><br><d= +iv class=3D"gmail_quote">On Wed, Jun 19, 2013 at 12:33 PM, Turkey Breast <s= +pan dir=3D"ltr"><<a title=3D"mailto:turkeybreast@yahoo.com" href=3D"mail= +to:turkeybreast@yahoo.com" target=3D"_blank">turkeybreast@yahoo.com</a>>= +</span> wrote:<br> + +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding= +-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l= +eft-style:solid"><div><div style=3D"font-family:times new roman,new york,ti= +mes,serif;font-size:12pt"> +<div><span>It's a problem if you work with iterators to deserialize the= + byte stream. Even failing that, it's just sloppy programming. What hap= +pens in the future when new fields are added to the version message? It'= +;s not a big deal to say that this protocol version has X number of fields,= + that (higher) protocol version message has X + N number of fields. Determi= +nistic number of fields per protocol version is sensical and how Bitcoin ha= +s been for a long time.</span></div> + +<div style=3D"font-family:times new roman,new york,times,serif;font-size:16= +px;font-style:normal;background-color:transparent"><br><span></span></div><= +div style=3D"font-family:times new roman,new york,times,serif;font-size:16p= +x;font-style:normal;background-color:transparent"> + +<span>And yes, it was a problem for me + that caused a lot of confusion why this byte didn't exist in many vers= +ion messages despite the standard saying it should and the code in bitcoind= + indicating it should. Nowhere was this written. It doesn't help other = +implementations to have an unclear behaviour that depends on some magic fro= +m one implementation.<br> + +</span></div><div><br></div> <div style=3D"font-family:times new roman,new= + york,times,serif;font-size:12pt"> <div style=3D"font-family:times new roma= +n,new york,times,serif;font-size:12pt"> <div dir=3D"ltr"> <hr size=3D"1"> = +<font face=3D"Arial"><div> + + <b><span style=3D"font-weight:bold">From:</span></b> Mike Hearn <<a tit= +le=3D"mailto:mike@plan99.net" href=3D"mailto:mike@plan99.net" target=3D"_bl= +ank">mike@plan99.net</a>><br> <b><span style=3D"font-weight:bold">To:</s= +pan></b> Turkey Breast <<a title=3D"mailto:turkeybreast@yahoo.com" href= +=3D"mailto:turkeybreast@yahoo.com" target=3D"_blank">turkeybreast@yahoo.com= +</a>> <br> + +</div><b><span style=3D"font-weight:bold">Cc:</span></b> "<a title=3D"= +mailto:bitcoin-development@lists.sourceforge.net" href=3D"mailto:bitcoin-de= +velopment@lists.sourceforge.net" target=3D"_blank">bitcoin-development@list= +s.sourceforge.net</a>" <<a title=3D"mailto:bitcoin-development@list= +s.sourceforge.net" href=3D"mailto:bitcoin-development@lists.sourceforge.net= +" target=3D"_blank">bitcoin-development@lists.sourceforge.net</a>> <br> + + <b><span style=3D"font-weight:bold">Sent:</span></b> Wednesday, June 19, 2= +013 11:39 AM<div><div><br> <b><span style=3D"font-weight:bold">Subject:</sp= +an></b> Re: [Bitcoin-development] Missing fRelayTxes in version message<br> + + </div></div></font> </div><div><div> <div><br> +<div><div dir=3D"ltr">It has to be optional because old clients don't s= +end it, obviously.<div><br></div><div>Why is this even an issue? There'= +s no problem with variable length messages in any codebase that I'm awa= +re of. Is this solving some actual problem?</div> + + +</div><div><br><br><div>On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast <sp= +an dir=3D"ltr"><<a title=3D"mailto:turkeybreast@yahoo.com" href=3D"mailt= +o:turkeybreast@yahoo.com" rel=3D"nofollow" target=3D"_blank">turkeybreast@y= +ahoo.com</a>></span> wrote:<br> + +<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-= +color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div>= +<div style=3D"font-family:times new roman,new york,times,serif;font-size:12= +pt"> +<div><span>That's me. I never said to make all messages fixed length. I= + said to make a fixed number of fields per protocol. So given a protocol ve= +rsion number, you know the number of fields in a message. This is not only = +easier for parsing messages, but just good practice. I don't see why a = +1 byte flag needs to be optional anyway.<br> + + +</span></div><div><div><br></div> </div><div style=3D"font-family:times ne= +w roman,new york,times,serif;font-size:12pt"><div> </div><div style=3D"font= +-family:times new roman,new york,times,serif;font-size:12pt"> +<div> <div dir=3D"ltr"> <hr size=3D"1"> <font face=3D"Arial"> <b><span sty= +le=3D"font-weight:bold">From:</span></b> Mike Hearn <<a title=3D"mailto:= +mike@plan99.net" href=3D"mailto:mike@plan99.net" rel=3D"nofollow" target=3D= +"_blank">mike@plan99.net</a>><br> + <b><span style=3D"font-weight:bold">To:</span></b> Turkey Breast <<a ti= +tle=3D"mailto:turkeybreast@yahoo.com" href=3D"mailto:turkeybreast@yahoo.com= +" rel=3D"nofollow" target=3D"_blank">turkeybreast@yahoo.com</a>> <br> + +<b><span style=3D"font-weight:bold">Cc:</span></b> + Bitcoin Dev <<a title=3D"mailto:bitcoin-development@lists.sourceforge.n= +et" href=3D"mailto:bitcoin-development@lists.sourceforge.net" rel=3D"nofoll= +ow" target=3D"_blank">bitcoin-development@lists.sourceforge.net</a>> <br= +> <b><span style=3D"font-weight:bold">Sent:</span></b> Tuesday, June 18, 20= +13 9:48 PM<br> + + + <b><span style=3D"font-weight:bold">Subject:</span></b> Re: [Bitcoin-devel= +opment] Missing fRelayTxes in version message<br> </font> </div></div><div>= +<div> <div><br> +<div><div dir=3D"ltr">It's not a bug (although there was recently a cha= +nge to make bitcoind/qt always send this field anyway).=C2=A0<div><br></div= +><div>I don't know where Amir is going with BIP 60. Version messages ha= +ve always been variable length. There's nothing inherent in the Bitcoin= + protocol that says all messages are fixed length, indeed, tx messages are = +allowed to have arbitrary data appended after them that gets relayed.</div> + + + +</div><div><br><br><div>On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast <spa= +n dir=3D"ltr"><<a title=3D"mailto:turkeybreast@yahoo.com" href=3D"mailto= +:turkeybreast@yahoo.com" rel=3D"nofollow" target=3D"_blank">turkeybreast@ya= +hoo.com</a>></span> wrote:<br> + +<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-= +color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div>= +<div style=3D"font-family:times new roman,new york,times,serif;font-size:12= +pt"> +<div>See this BIP. I'm not sure if this is a bug or what, but it would = +be good if messages always had a fixed number of fields per protocol versio= +n.</div> + + +<div><br></div><div style=3D"font-family:times new roman,new york,times,ser= +if;font-size:16px;font-style:normal;background-color:transparent"><a title= +=3D"https://en.bitcoin.it/wiki/BIP_0060#Code_Updates" href=3D"https://en.bi= +tcoin.it/wiki/BIP_0060#Code_Updates" rel=3D"nofollow" target=3D"_blank">htt= +ps://en.bitcoin.it/wiki/BIP_0060#Code_Updates</a></div> + + + +<div style=3D"font-family:times new roman,new york,times,serif;font-size:16= +px;font-style:normal;background-color:transparent"><br></div><div style=3D"= +font-family:times new roman,new york,times,serif;font-size:16px;font-style:= +normal;background-color:transparent"> + + + +This BIP details everything that needs to be done and proposes a protocol u= +pgrade.<br></div></div></div><br>------------------------------------------= +------------------------------------<br> +This <a title=3D"http://sf.net/" href=3D"http://sf.net/" rel=3D"nofollow" t= +arget=3D"_blank">SF.net</a> email is sponsored by Windows:<br> +<br> +Build for Windows Store.<br> +<br> +<a title=3D"http://p.sf.net/sfu/windows-dev2dev" href=3D"http://p.sf.net/sf= +u/windows-dev2dev" target=3D"_blank">http://p.sf.net/sfu/windows-dev2dev</a= +><br>_______________________________________________<br> +Bitcoin-development mailing list<br> +<a title=3D"mailto:Bitcoin-development@lists.sourceforge.net" href=3D"mailt= +o:Bitcoin-development@lists.sourceforge.net" rel=3D"nofollow" target=3D"_bl= +ank">Bitcoin-development@lists.sourceforge.net</a><br> +<a title=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen= +t" href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" rel=3D"nofollow" target=3D"_blank">https://lists.sourceforge.net/lists/li= +stinfo/bitcoin-development</a><br> + +<br></blockquote></div><br></div> +</div><br><br></div> </div></div></div> </div> </div></div><br>-----------= +-------------------------------------------------------------------<br> +This SF.net email is sponsored by Windows:<br> +<br> +Build for Windows Store.<br> +<br> +<a title=3D"http://p.sf.net/sfu/windows-dev2dev" href=3D"http://p.sf.net/sf= +u/windows-dev2dev" rel=3D"nofollow" target=3D"_blank">http://p.sf.net/sfu/w= +indows-dev2dev</a><br>_______________________________________________<br> +Bitcoin-development mailing list<br> +<a title=3D"mailto:Bitcoin-development@lists.sourceforge.net" href=3D"mailt= +o:Bitcoin-development@lists.sourceforge.net" rel=3D"nofollow" target=3D"_bl= +ank">Bitcoin-development@lists.sourceforge.net</a><br> +<a title=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen= +t" href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" rel=3D"nofollow" target=3D"_blank">https://lists.sourceforge.net/lists/li= +stinfo/bitcoin-development</a><br> + +<br></blockquote></div><br></div> +</div><br><br></div> </div></div></div> </div> </div></div><br>-----------= +-------------------------------------------------------------------<br> +This SF.net email is sponsored by Windows:<br> +<br> +Build for Windows Store.<br> +<br> +<a title=3D"http://p.sf.net/sfu/windows-dev2dev" href=3D"http://p.sf.net/sf= +u/windows-dev2dev" target=3D"_blank">http://p.sf.net/sfu/windows-dev2dev</a= +><br>_______________________________________________<br> +Bitcoin-development mailing list<br> +<a title=3D"mailto:Bitcoin-development@lists.sourceforge.net" href=3D"mailt= +o:Bitcoin-development@lists.sourceforge.net" target=3D"_blank">Bitcoin-deve= +lopment@lists.sourceforge.net</a><br> +<a title=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen= +t" href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> + +<br></blockquote></div><br></div> +</div></div></div></div></blockquote></div><br></div> + +--089e013c7042742a4204df81b023-- + + |