Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UpaOl-000603-BT for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 08:39:19 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UpaOj-0006D1-Ek for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 08:39:19 +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 1UpaOc-0000nF-L3; Thu, 20 Jun 2013 10:39:10 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_4A2B3B2A-66B7-49FC-947F-47A201BD0F89" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tamas Blummer In-Reply-To: Date: Thu, 20 Jun 2013 10:39:10 +0200 Message-Id: <84938F7F-B75C-434B-9B7A-EC406CE42385@bitsofproof.com> 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; 1371717557; 08621cee; 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: 1UpaOj-0006D1-Ek 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:39:19 -0000 --Apple-Mail=_4A2B3B2A-66B7-49FC-947F-47A201BD0F89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes it is trivial. I do not think greater complexity in the system = should keep us from addressing low complexity issues. You can't blame me or others not trying to simplify scripts, if there is = such a headwind simplifying a version message. You are right there is too much fuss about this. Tam=E1s Blummer Founder, CEO http://bitsofproof.com On 20.06.2013, at 10:31, Mike Hearn wrote: > You can't eliminate the complexity (yet), otherwise you wouldn't be = able to talk to old nodes. You'll have to wait until versions prior to a = particular version are hard-forked off and can be safely dropped at = connect time. >=20 > That said the reason I'm being so grumpy about this is that compared = to the complexity in the rest of the system, this is such a trivial and = minor detail. It's hardly even worth thinking about. I mean, we have a = scripting language full of opcodes nobody ever figured out how to use = and the protocol uses a mixture of byte orders, so an optional field in = the version message is really not such a big deal :) >=20 >=20 > On Thu, Jun 20, 2013 at 10:17 AM, Tamas Blummer = wrote: > 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. >=20 > 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. >=20 > Tam=E1s Blummer > http://bitsofproof.com >=20 > On 20.06.2013, at 09:36, Mike Hearn wrote: >=20 >> 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 >=20 >=20 --Apple-Mail=_4A2B3B2A-66B7-49FC-947F-47A201BD0F89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Yes it is trivial. I do not think greater complexity = in the system should keep us from addressing low complexity = issues.
You can't blame me = or others not trying to simplify scripts, if there is such a headwind = simplifying a version message.
You are right there is too much fuss about = this.

Tam=E1s Blummer
Founder, CEO
http://bitsofproof.com

On 20.06.2013, at 10:31, Mike Hearn <mike@plan99.net> wrote:

You can't eliminate the complexity (yet), otherwise you = wouldn't be able to talk to old nodes. You'll have to wait until = versions prior to a particular version are hard-forked off and can be = safely dropped at connect time.

That said the reason I'm being so grumpy about this is = that compared to the complexity in the rest of the system, this is such = a trivial and minor detail. It's hardly even worth thinking about. I = mean, we have a scripting language full of opcodes nobody ever figured = out how to use and the protocol uses a mixture of byte orders, so an = optional field in the version message is really not such a big deal = :)


On = Thu, Jun 20, 2013 at 10:17 AM, Tamas Blummer <tamas@bitsofproof.com> wrote:
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

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-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-dev= elopment





= --Apple-Mail=_4A2B3B2A-66B7-49FC-947F-47A201BD0F89--