summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Hearn <mike@plan99.net>2013-06-19 15:20:10 +0200
committerbitcoindev <bitcoindev@gnusha.org>2013-06-19 13:20:18 +0000
commitd88330df25b1ec8b75621510497f2f36c87b1386 (patch)
tree6d21698ff31a6dab2845bdb5bb2a9e7b15704c7d
parent9efd4126f662ec3dea67b7f9e95e405dfaa8b9e6 (diff)
downloadpi-bitcoindev-d88330df25b1ec8b75621510497f2f36c87b1386.tar.gz
pi-bitcoindev-d88330df25b1ec8b75621510497f2f36c87b1386.zip
Re: [Bitcoin-development] Missing fRelayTxes in version message
-rw-r--r--be/97f00a7813b2416e22a7f0412526675363afaa518
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&#39;t where I&#39;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&#39;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">&lt;<a href=3D=
+"mailto:pmlyon@hotmail.ca" target=3D"_blank">pmlyon@hotmail.ca</a>&gt;</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,&#39;Segoe UI&#39;,Meiry=
+o,&#39;Microsoft YaHei UI&#39;,&#39;Microsoft JhengHei UI&#39;,&#39;Malgun =
+Gothic&#39;,&#39;Khmer UI&#39;,&#39;Nirmala UI&#39;,Tunga,&#39;Lao UI&#39;,=
+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:&quot;Segoe UI Symbol=
+&quot;,&quot;Apple Color Emoji&quot;">=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, &#39;Segoe UI&#39;, Meiryo, &#39;Microsoft YaHei UI&#39;, &#39;Microsof=
+t JhengHei UI&#39;, &#39;Malgun Gothic&#39;, &#39;Khmer UI&#39;, &#39;Nirma=
+la UI&#39;, Tunga, &#39;Lao UI&#39;, Ebrima, sans-serif" style=3D"line-heig=
+ht:15pt;letter-spacing:0.02em;font-family:Calibri,&quot;Segoe UI&quot;,Meir=
+yo,&quot;Microsoft YaHei UI&quot;,&quot;Microsoft JhengHei UI&quot;,&quot;M=
+algun Gothic&quot;,&quot;Khmer UI&quot;,&quot;Nirmala UI&quot;,Tunga,&quot;=
+Lao UI&quot;,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&#39;t affect anything, but as o=
+ld pre-filtering versions will continue to exist, you&#39;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&#39;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">&lt;<a title=3D"mailto:turkeybreast@yahoo.com" href=3D"mail=
+to:turkeybreast@yahoo.com" target=3D"_blank">turkeybreast@yahoo.com</a>&gt;=
+</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&#39;s a problem if you work with iterators to deserialize the=
+ byte stream. Even failing that, it&#39;s just sloppy programming. What hap=
+pens in the future when new fields are added to the version message? It&#39=
+;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&#39;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&#39;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 &lt;<a tit=
+le=3D"mailto:mike@plan99.net" href=3D"mailto:mike@plan99.net" target=3D"_bl=
+ank">mike@plan99.net</a>&gt;<br> <b><span style=3D"font-weight:bold">To:</s=
+pan></b> Turkey Breast &lt;<a title=3D"mailto:turkeybreast@yahoo.com" href=
+=3D"mailto:turkeybreast@yahoo.com" target=3D"_blank">turkeybreast@yahoo.com=
+</a>&gt; <br>
+
+</div><b><span style=3D"font-weight:bold">Cc:</span></b> &quot;<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>&quot; &lt;<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>&gt; <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&#39;t s=
+end it, obviously.<div><br></div><div>Why is this even an issue? There&#39;=
+s no problem with variable length messages in any codebase that I&#39;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">&lt;<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>&gt;</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&#39;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&#39;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 &lt;<a title=3D"mailto:=
+mike@plan99.net" href=3D"mailto:mike@plan99.net" rel=3D"nofollow" target=3D=
+"_blank">mike@plan99.net</a>&gt;<br>
+ <b><span style=3D"font-weight:bold">To:</span></b> Turkey Breast &lt;<a ti=
+tle=3D"mailto:turkeybreast@yahoo.com" href=3D"mailto:turkeybreast@yahoo.com=
+" rel=3D"nofollow" target=3D"_blank">turkeybreast@yahoo.com</a>&gt; <br>
+
+<b><span style=3D"font-weight:bold">Cc:</span></b>
+ Bitcoin Dev &lt;<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>&gt; <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&#39;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&#39;t know where Amir is going with BIP 60. Version messages ha=
+ve always been variable length. There&#39;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">&lt;<a title=3D"mailto:turkeybreast@yahoo.com" href=3D"mailto=
+:turkeybreast@yahoo.com" rel=3D"nofollow" target=3D"_blank">turkeybreast@ya=
+hoo.com</a>&gt;</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&#39;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--
+
+