<div dir="ltr">There&#39;s no problem, but there&#39;s no benefit either. It also locks us in to a potentially problematic guarantee - what if in future we want to have, say, two optional new pieces of data in two different messages. We don&#39;t want to require that if version &gt; X then you have to implement all features up to and including that point.<div>
<br></div><div>Essentially the number of fields in a message is like a little version number, just for that message. It adds flexibility to keep it that way, and there&#39;s no downside, seeing as that bridge was already crossed and people with parsers that can&#39;t handle it need to fix their code anyway.</div>
<div><br></div><div>So I have a slight preference for keeping things the way they are, it keeps things flexible for future and costs nothing.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Jun 20, 2013 at 11:06 AM, Pieter Wuille <span dir="ltr">&lt;<a href="mailto:pieter.wuille@gmail.com" target="_blank">pieter.wuille@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:<br>
&gt; Sure but why not do that when there&#39;s an actual new field to add? Does<br>
&gt; anyone have a proposal for a feature that needs a new version field at the<br>
&gt; moment? There&#39;s no point changing the protocol now unless there&#39;s actually<br>
&gt; a new field to add.<br>
&gt;<br>
&gt; Anyway I still don&#39;t see why anyone cares about this issue. The Bitcoin<br>
&gt; protocol does not and never has required that all messages have a fixed<br>
&gt; number of fields per version. Any parser written on the assumption it did<br>
&gt; was just buggy. Look at how tx messages are relayed for the most obvious<br>
&gt; example of that pattern in action - it&#39;s actually the raw byte stream<br>
&gt; that&#39;s stored and relayed to ensure that fields added in new versions<br>
&gt; aren&#39;t dropped during round-tripping. Old versions are supposed to preserve<br>
&gt; fields from the future.<br>
<br>
</div>Actually, that is not the same issue. What is being argued for here is that<br>
the version in the version message itself should indicate which fields are<br>
present, so a parser doesn&#39;t need to look at the length of the message. That<br>
seems like a minor but very reasonable request to me, and it&#39;s trivial to do.<br>
That doesn&#39;t mean that you may receive versions higher than what you know of,<br>
and thus messages with fields you don&#39;t know about. That doesn&#39;t matter, you<br>
can just ignore them.<br>
<br>
I see no problem with raising the protocol version number to indicate<br>
&quot;all fields up to fRelayTxes are required, if the announced nVersion is above N&quot;.<br>
In fact, I believe (though haven&#39;t checked) all previous additions to the version<br>
message were accompanied with a protocol version (then: client version) increase<br>
as well.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Pieter<br>
<br>
</font></span></blockquote></div><br></div>