Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Upa3N-0002yS-Ho for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 08:17:13 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Upa3L-0003bl-LC for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 08:17:13 +0000 Received: from [37.143.74.116] (helo=[192.168.1.5]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1Upa3E-0002Z8-V1; Thu, 20 Jun 2013 10:17:05 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_89C91DFB-D4A3-4955-A2B1-97BF686F7F4F" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tamas Blummer In-Reply-To: Date: Thu, 20 Jun 2013 10:17:04 +0200 Message-Id: References: <4DE0E45E-BB48-4DFF-9C86-ACBE312B3049@bitsofproof.com> To: Mike Hearn X-Mailer: Apple Mail (2.1503) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1371716231; c85edd7f; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Upa3L-0003bl-LC Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Missing fRelayTxes in version X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 08:17:14 -0000 --Apple-Mail=_89C91DFB-D4A3-4955-A2B1-97BF686F7F4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree that this can be deferred until there is an actual new field = without any harm. But then remember to update the BIP37 too saying that = it is optional only if flag added in BIPXX is not present. Your argument is that this complexity is already there so why not = preserve it. I think eliminating complexity (that has no benefit) = strengthens the system. Tam=E1s Blummer http://bitsofproof.com On 20.06.2013, at 09:36, Mike Hearn wrote: > Sure but why not do that when there's an actual new field to add? Does = anyone have a proposal for a feature that needs a new version field at = the moment? There's no point changing the protocol now unless there's = actually a new field to add. >=20 > Anyway I still don't see why anyone cares about this issue. The = Bitcoin protocol does not and never has required that all messages have = a fixed number of fields per version. Any parser written on the = assumption it did was just buggy. Look at how tx messages are relayed = for the most obvious example of that pattern in action - it's actually = the raw byte stream that's stored and relayed to ensure that fields = added in new versions aren't dropped during round-tripping. Old versions = are supposed to preserve fields from the future. >=20 >=20 >=20 > On Thu, Jun 20, 2013 at 9:30 AM, Tamas Blummer = wrote: > Hi Mike, >=20 > The issue with the current parser is that those fields are = conditionally optional on that there will be no subsequent fields added. > If there will be further fields they will become manadory.=20 > =20 > Why not bump the version and parse the fields as mandatory from then = on? This would be backward compatible and cleaner > going forward. >=20 > Tamas Blummer > http://bitsofproof.com >=20 >=20 > = --------------------------------------------------------------------------= ---- > This SF.net email is sponsored by Windows: >=20 > Build for Windows Store. >=20 > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 >=20 --Apple-Mail=_89C91DFB-D4A3-4955-A2B1-97BF686F7F4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I agree that this can be deferred until there is an = actual new field without any harm. But then remember to update the BIP37 = too saying that it is optional only if flag added in BIPXX is not = present.

Your argument is that this complexity is already = there so why not preserve it. I think eliminating complexity (that = has no benefit) strengthens the system.

http://bitsofproof.com

On 20.06.2013, at 09:36, Mike Hearn <mike@plan99.net> wrote:

Sure but why not do that when there's an actual new field to = add? Does anyone have a proposal for a feature that needs a new version = field at the moment? There's no point changing the protocol now unless = there's actually a new field to add.

Anyway I still don't see why anyone cares = about this issue. The Bitcoin protocol does not and never has required = that all messages have a fixed number of fields per version. Any parser = written on the assumption it did was just buggy. Look at how tx messages = are relayed for the most obvious example of that pattern in action - = it's actually the raw byte stream that's stored and relayed to ensure = that fields added in new versions aren't dropped during round-tripping. = Old versions are supposed to preserve fields from the future.



On Thu, Jun 20, 2013 at 9:30 AM, Tamas Blummer = <tamas@bitsofproof.com> wrote:
Hi Mike,

The issue with the current parser is that those fields are conditionally = optional on that there will be no subsequent fields added.
If there will be further fields they will become = manadory. 
 
Why not bump the version and parse the fields as mandatory from = then on? This would be backward compatible and cleaner
going forward.

Tamas Blummer
=


--------------------------------------------------= ----------------------------
This SF.net email is sponsored by = Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_____________= __________________________________
Bitcoin-development mailing list
Bitcoin-developm= ent@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-dev= elopment



= --Apple-Mail=_89C91DFB-D4A3-4955-A2B1-97BF686F7F4F--