Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Up4Q9-0005md-3v for bitcoin-development@lists.sourceforge.net; Tue, 18 Jun 2013 22:30:37 +0000 X-ACL-Warn: Received: from nm42-vm10.bullet.mail.bf1.yahoo.com ([216.109.114.155]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Up4Q7-0001lY-Rm for bitcoin-development@lists.sourceforge.net; Tue, 18 Jun 2013 22:30:36 +0000 Received: from [98.139.212.152] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2013 22:30:30 -0000 Received: from [98.139.212.216] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2013 22:30:30 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 18 Jun 2013 22:30:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 297737.99472.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 29881 invoked by uid 60001); 18 Jun 2013 22:30:30 -0000 X-YMail-OSG: C10amPEVM1k8T8mGoD7F1niUr5O9OA.gM290XOz41eBA0MM jSXiRl8NEAkKcTFSyqVQ72it3EzWPEDEMiH0gVYyvr71PlE9xvoVneVal7yV bsfB.rqucMoUHasrIEkms4oeQ7p7MCFWQtYb8JGpjwzuqVI21SwbFmixDp91 0y7Y1Njcnxf5ABhFyTaWSEoGBhFVauXul0EkEq9Gn856JsjHBwDQP2rS1WhB AqzVv_DAdvLTxdGpQur5Y37TENos_1z.FqLciddBbU8qIlFFyy59LGmyogFM 9zSts4J_4U5sy8CAr7jPBmfIP5SGw5rWVVqwz7QUTt7ZuoMYTmJSSQci9ohh fWHcvdKn1cE6jt9Bl88c0Jhqcs7E7dtb3uyBHuyAFOr1tiWoYUKzC1L08wNf 4afD7rrR86lNHACLVevLOKOEW6eBCWe0r_7kaSvpCYBEDTsFd4d6D4C.VPMa _ThUqF0ko1gOWm5cguAmqNSxxj_np4nCftwsAjdGUicz3QKfyPh9TVJ4S_O6 DsG8kEt4GKtHCd6tAEGNzXGbMVUg_SDnnNdyKJDdtF3GlJXLjEpDd_2Ef.kr 0ePcbtN0JuIAtXgW5SrQGBVdlez6moq2W0Rei7xsUXfg.Hik8JxygOU83Kbg - Received: from [87.160.180.101] by web162703.mail.bf1.yahoo.com via HTTP; Tue, 18 Jun 2013 15:30:30 PDT X-Rocket-MIMEInfo: 002.001, VGhhdCdzIG1lLiBJIG5ldmVyIHNhaWQgdG8gbWFrZSBhbGwgbWVzc2FnZXMgZml4ZWQgbGVuZ3RoLiBJIHNhaWQgdG8gbWFrZSBhIGZpeGVkIG51bWJlciBvZiBmaWVsZHMgcGVyIHByb3RvY29sLiBTbyBnaXZlbiBhIHByb3RvY29sIHZlcnNpb24gbnVtYmVyLCB5b3Uga25vdyB0aGUgbnVtYmVyIG9mIGZpZWxkcyBpbiBhIG1lc3NhZ2UuIFRoaXMgaXMgbm90IG9ubHkgZWFzaWVyIGZvciBwYXJzaW5nIG1lc3NhZ2VzLCBidXQganVzdCBnb29kIHByYWN0aWNlLiBJIGRvbid0IHNlZSB3aHkgYSAxIGJ5dGUgZmwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.147.553 References: <1371577555.61696.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <1371594630.18036.YahooMailNeo@web162703.mail.bf1.yahoo.com> Date: Tue, 18 Jun 2013 15:30:30 -0700 (PDT) From: Turkey Breast To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395274837-803414910-1371594630=:18036" X-Spam-Score: -0.3 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [216.109.114.155 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (turkeybreast[at]yahoo.com) -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1Up4Q7-0001lY-Rm Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Turkey Breast List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:30:37 -0000 ---1395274837-803414910-1371594630=:18036 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 version number, y= ou know the number of fields in a message. This is not only easier for pars= ing messages, but just good practice. I don't see why a 1 byte flag needs t= o be optional anyway.=0A=0A=0A=0A________________________________=0A From: = Mike Hearn =0ATo: Turkey Breast = =0ACc: Bitcoin Dev =0ASent: Tue= sday, June 18, 2013 9:48 PM=0ASubject: Re: [Bitcoin-development] Missing fR= elayTxes in version message=0A =0A=0A=0AIt's not a bug (although there was = recently a change to make bitcoind/qt always send this field anyway).=A0=0A= =0AI don't know where Amir is going with BIP 60. Version messages have alwa= ys been variable length. There's nothing inherent in the Bitcoin protocol t= hat says all messages are fixed length, indeed, tx messages are allowed to = have arbitrary data appended after them that gets relayed.=0A=0A=0A=0AOn Tu= e, Jun 18, 2013 at 7:45 PM, Turkey Breast wrote:= =0A=0ASee 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 version.= =0A>=0A>=0A>https://en.bitcoin.it/wiki/BIP_0060#Code_Updates=0A>=0A>=0A>Thi= s BIP details everything that needs to be done and proposes a protocol upgr= ade.=0A>=0A>---------------------------------------------------------------= ---------------=0A>This SF.net email is sponsored by Windows:=0A>=0A>Build = for Windows Store.=0A>=0A>http://p.sf.net/sfu/windows-dev2dev=0A>__________= _____________________________________=0A>Bitcoin-development mailing list= =0A>Bitcoin-development@lists.sourceforge.net=0A>https://lists.sourceforge.= net/lists/listinfo/bitcoin-development=0A>=0A> ---1395274837-803414910-1371594630=:18036 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That's me.= I never said to make all messages fixed length. I said to make a fixed num= ber of fields per protocol. So given a protocol version number, you know th= e number of fields in a message. This is not only easier for parsing messag= es, but just good practice. I don't see why a 1 byte flag needs to be optio= nal 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: [Bitc= oin-development] Missing fRelayTxes in version message
<= div class=3D"y_msg_container">
=0A
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 lengt= h. There's nothing inherent in the Bitcoin protocol that says all messages = are fixed length, indeed, tx messages are allowed to have arbitrary data ap= pended after them that gets relayed.
=0A


On Tue, Jun= 18, 2013 at 7:45 PM, Turkey Breast <turkeybreast@yahoo.com> wrote:
= =0A
See this = BIP. I'm not sure if this is a bug or what, but it would be good if message= s always had a fixed number of fields per protocol version.
=0A
=0A

=0AThis BIP details everything that= needs to be done and proposes a protocol upgrade.
--------------------------------------------------------------------------= ----
=0AThis SF.net ema= il is sponsored by Windows:
=0A
=0ABuild for Windows Store.
=0A=0Ahttp://p.sf.net/sfu/windows-dev2dev
________________________________= _______________
=0ABitcoin-development mailing list
=0ABitco= in-development@lists.sourceforge.net
=0Ahttps://lists.sourceforge.net/lists/listinfo/bitcoin-development=
=0A

=0A


---1395274837-803414910-1371594630=:18036--