Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UpFhY-0004F8-QF for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 10:33:20 +0000 X-ACL-Warn: Received: from nm45-vm4.bullet.mail.bf1.yahoo.com ([216.109.115.63]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UpFhX-0000rk-Hf for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 10:33:20 +0000 Received: from [66.196.81.172] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2013 10:33:14 -0000 Received: from [98.139.212.237] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2013 10:33:14 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 19 Jun 2013 10:33:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 22105.71101.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 20631 invoked by uid 60001); 19 Jun 2013 10:33:13 -0000 X-YMail-OSG: VVQFTFkVM1kFS39kgSZIs8v9SRLre1ipYjPrCz_orpa.t76 EUO_R6VWmlA2MkGSWnUYk9bLkSkF7LrRgo2IJXOgjIJ2i0FgOaieYDlwgcfq 2XgZn5MwMC.UVz8y4uwIvyl8gRM1h6XehkZSyvb2U4mgI0hPj8NVgj1R0pyx 9KmjmiNghzv.MMCsf2qsld.42pfNMJjP3wBdA9oVprgJhkEbC5nGPIkmaAqr yV8hS9INENuj3W8XnwgcobhYe4sUr_Utmb7DJ8ITWWQjq3KOMxsuR_xuYKX_ Gy1oRqq17O_jWcJ1d.A1kXapJQDlp4P941uEKGB7k14LYADUNI_tZnKEfSnC trqjWkT0C0gS6vyQBw4E9s5CK2RSxj39YgDqQ1li29slvaauzpzIKFIT7HJi cE8jZDljxyaqeGUOjAsJlccov5M1QVzD7Ww_KbuvssmbcSud3k82EvUNJpqL 0AIzU4z._4GpcYp85HXVY7zlxfzgMZTYtLkUSq9rcUv92AILl2XWxv78_Il_ P5tRivut2JU1tZsDKi.45Ali7WpREdLOSGbVjW.2iLuHoyiA..QR4vnkFbzu nKEaDacqQjZk3s47oMrX.NE3dT86sB2iJAZqdTSHQoSCguud58eBGqeAo0A- - Received: from [87.160.130.27] by web162701.mail.bf1.yahoo.com via HTTP; Wed, 19 Jun 2013 03:33:13 PDT X-Rocket-MIMEInfo: 002.001, SXQncyBhIHByb2JsZW0gaWYgeW91IHdvcmsgd2l0aCBpdGVyYXRvcnMgdG8gZGVzZXJpYWxpemUgdGhlIGJ5dGUgc3RyZWFtLiBFdmVuIGZhaWxpbmcgdGhhdCwgaXQncyBqdXN0IHNsb3BweSBwcm9ncmFtbWluZy4gV2hhdCBoYXBwZW5zIGluIHRoZSBmdXR1cmUgd2hlbiBuZXcgZmllbGRzIGFyZSBhZGRlZCB0byB0aGUgdmVyc2lvbiBtZXNzYWdlPyBJdCdzIG5vdCBhIGJpZyBkZWFsIHRvIHNheSB0aGF0IHRoaXMgcHJvdG9jb2wgdmVyc2lvbiBoYXMgWCBudW1iZXIgb2YgZmllbGRzLCB0aGF0IChoaWdoZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.147.553 References: <1371577555.61696.YahooMailNeo@web162703.mail.bf1.yahoo.com> <1371594630.18036.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <1371637993.17115.YahooMailNeo@web162701.mail.bf1.yahoo.com> Date: Wed, 19 Jun 2013 03:33:13 -0700 (PDT) From: Turkey Breast To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-350752386-1044354069-1371637993=:17115" X-Spam-Score: -0.4 (/) 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.115.63 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (turkeybreast[at]yahoo.com) -1.3 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: 1UpFhX-0000rk-Hf 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: Wed, 19 Jun 2013 10:33:21 -0000 ---350752386-1044354069-1371637993=:17115 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It's a problem if you work with iterators to deserialize the byte stream. E= ven failing that, it's just sloppy programming. What happens in the future = when new fields are added to the version message? It's not a big deal to sa= y that this protocol version has X number of fields, that (higher) protocol= version message has X + N number of fields. Deterministic number of fields= per protocol version is sensical and how Bitcoin has been for a long time.= =0A=0AAnd yes, it was a problem for me that caused a lot of confusion why t= his byte didn't exist in many version messages despite the standard saying = it should and the code in bitcoind indicating it should. Nowhere was this w= ritten. It doesn't help other implementations to have an unclear behaviour = that depends on some magic from one implementation.=0A=0A=0A=0A____________= ____________________=0A From: Mike Hearn =0ATo: Turkey Bre= ast =0ACc: "bitcoin-development@lists.sourceforge.= net" =0ASent: Wednesday, June 1= 9, 2013 11:39 AM=0ASubject: Re: [Bitcoin-development] Missing fRelayTxes in= version message=0A =0A=0A=0AIt has to be optional because old clients don'= t send it, obviously.=0A=0AWhy is this even an issue? There's no problem wi= th variable length messages in any codebase that I'm aware of. Is this solv= ing some actual problem?=0A=0A=0A=0AOn Wed, Jun 19, 2013 at 12:30 AM, Turke= y Breast wrote:=0A=0AThat's me. I never said to ma= ke all messages fixed length. I said to make a fixed number of fields per p= rotocol. So given a protocol version number, you know the number of fields = in a message. This is not only easier for parsing messages, but just good p= ractice. I don't see why a 1 byte flag needs to be optional anyway.=0A>=0A>= =0A>=0A>=0A>________________________________=0A> From: Mike Hearn =0A>To: Turkey Breast =0A>Cc: Bitcoin Dev = =0A>Sent: Tuesday, June 18, 201= 3 9:48 PM=0A>Subject: Re: [Bitcoin-development] Missing fRelayTxes in versi= on message=0A> =0A>=0A>=0A>It's not a bug (although there was recently a ch= ange to make bitcoind/qt always send this field anyway).=A0=0A>=0A>=0A>I do= n'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 say= s all messages are fixed length, indeed, tx messages are allowed to have ar= bitrary data appended after them that gets relayed.=0A>=0A>=0A>=0A>On Tue, = Jun 18, 2013 at 7:45 PM, Turkey Breast wrote:=0A>= =0A>See this BIP. I'm not sure if this is a bug or what, but it would be go= od 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>>= This BIP details everything that needs to be done and proposes a protocol u= pgrade.=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 ma= iling list=0A>>Bitcoin-development@lists.sourceforge.net=0A>>https://lists.= sourceforge.net/lists/listinfo/bitcoin-development=0A>>=0A>>=0A>=0A>=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-d= evelopment@lists.sourceforge.net=0A>https://lists.sourceforge.net/lists/lis= tinfo/bitcoin-development=0A>=0A> ---350752386-1044354069-1371637993=:17115 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It's a pro= blem if you work with iterators to deserialize the byte stream. Even failin= g that, it's just sloppy programming. What happens in the future when new f= ields are added to the version message? It's not a big deal to say that thi= s protocol version has X number of fields, that (higher) protocol version m= essage has X + N number of fields. Deterministic number of fields per proto= col 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 it should and the code in bitcoind ind= icating it should. Nowhere was this written. It doesn't help other implemen= tations to have an unclear behaviour that depends on some magic from one im= plementation.

From: Mike Hearn <mike@plan99.net&g= t;
To: Turkey Breast &= lt;turkeybreast@yahoo.com>
Cc:= "bitcoin-development@lists.sourceforge.net" <bitcoin-develop= ment@lists.sourceforge.net>
Sent: Wednesday, June 19, 2013 11:39 AM
Subject: Re: [Bitcoin-development] Mis= sing fRelayTxes in version message

=0A
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?
=0A<= /div>


On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast <turkeybreast@yahoo= .com> wrote:
=0A
That's me. I never said to make all messages fix= ed length. I said to make a fixed number of fields per protocol. So given a= protocol version 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 se= e why a 1 byte flag needs to be optional anyway.
=0A

=
=0A
From: Mike Hearn <mike@plan99.net>=
To: Turkey Breast <= turkeybreast@yahoo.com> =
=0ACc:=0A Bitcoin Dev &= lt;bitcoin-development@lists.sourceforge.net>
Sent: Tuesday, June 18, 2013 9:48 PM<= br>=0A Subject: Re: [Bitcoi= n-development] Missing fRelayTxes in version message

=0A
It= 's not a bug (although there was recently a change to make bitcoind/qt alwa= ys send this field anyway). 

I don't know where Ami= r 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 are allowed to have arbitrary data appen= ded after them that gets relayed.
=0A=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 messages always had a fixed number of= fields per protocol version.
=0A=0A

=0A=0A

=0A=0AThis BIP details everything that needs to be done and= proposes a protocol upgrade.

--------------------= ----------------------------------------------------------
=0AThis SF.net email i= s sponsored by Windows:
=0A
=0ABuild for Windows Store.
=0A
=0A= http://p.sf.net/sfu/windows-dev2dev
____________________________________= ___________
=0ABitcoin-development mailing list
=0ABitcoin-dev= elopment@lists.sourceforge.net
=0Ahttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
= =0A

=0A



-----------------------------------------------= -------------------------------
=0AThis SF.net email is sponsored by Win= dows:
=0A
=0ABuild for Windows Store.
=0A
=0Ahttp://p.s= f.net/sfu/windows-dev2dev
__________________________________________= _____
=0ABitcoin-development mailing list
=0ABitcoin-developme= nt@lists.sourceforge.net
=0Ahtt= ps://lists.sourceforge.net/lists/listinfo/bitcoin-development
=0A

=0A


---350752386-1044354069-1371637993=:17115--