References: <BLU404-EAS74077C5D43EACD319CCA3DA58D0@phx.gbl>
	<CANEZrP0Pr=_L7CA4hdt9esVCHqf-EOjfDjnVrw8rFxL1OtUw7A@mail.gmail.com>
Message-ID: <1371709237.57104.YahooMailNeo@web162701.mail.bf1.yahoo.com>
Date: Wed, 19 Jun 2013 23:20:37 -0700 (PDT)
From: Turkey Breast <turkeybreast@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CANEZrP0Pr=_L7CA4hdt9esVCHqf-EOjfDjnVrw8rFxL1OtUw7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="-350752386-1724672238-1371709237=:57104"
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
Precedence: list
Reply-To: Turkey Breast <turkeybreast@yahoo.com>

---350752386-1724672238-1371709237=:57104
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I never said that Bitcoin message field lengths should always be the same. =
But before this change they certainly were constant per protocol version. A=
ll I'm saying is that optional lengths shouldn't be used (a field exists or=
 not) and for every field change, the protocol version should be upgraded.=
=0A=0ANow that fRelayTxes is part of the protocol, the version number shoul=
d be upgraded to reflect this fact.=0A=0A=0A=0A____________________________=
____=0A From: Mike Hearn <mike@plan99.net>=0ATo: Paul Lyon <pmlyon@hotmail.=
ca> =0ACc: Turkey Breast <turkeybreast@yahoo.com>; "bitcoin-development@lis=
ts.sourceforge.net" <bitcoin-development@lists.sourceforge.net> =0ASent: We=
dnesday, June 19, 2013 3:20 PM=0ASubject: Re: [Bitcoin-development] Missing=
 fRelayTxes in version message=0A =0A=0A=0AIf you want to criticise the Bit=
coin protocol for sloppyness, the variable length of some messages isn't wh=
ere I'd start.=0A=0ANote that ping has the same issue, its length has chang=
ed over time to include the nonce.=0A=0AIf your parser can't handle that ki=
nd of thing, you need to fix it. The protocol has always worked that way.=
=0A=0A=0A=0A=0AOn Wed, Jun 19, 2013 at 3:03 PM, Paul Lyon <pmlyon@hotmail.c=
a> wrote:=0A=0AI=E2=80=99m also running into this exact same issue with my =
parser, now I understand why the relay field behavior I was seeing=C2=A0doe=
sn=E2=80=99t match the wiki.=0A>=C2=A0=0A>So to parse a version message, yo=
u can=E2=80=99t rely on the protocol version? You have to know how long the=
 payload is, and then parse the message accordingly? I agree with Turkey Br=
east, this seems a bit sloppy to me.=0A>=C2=A0=0A>Paul=0A>=C2=A0=0A>P.S. I=
=E2=80=99ve never used a dev mailing list before and I want to get involved=
 with the Bitcoin dev community, so let me know if I=E2=80=99m horribly vio=
lating any=C2=A0mailing list etiquette. =F0=9F=98=8A=0A>=C2=A0=0A>From:=C2=
=A0Mike Hearn=0A>Sent:=C2=A0=E2=80=8EWednesday=E2=80=8E, =E2=80=8EJune=E2=
=80=8E =E2=80=8E19=E2=80=8E, =E2=80=8E2013 =E2=80=8E7=E2=80=8E:=E2=80=8E43=
=E2=80=8E =E2=80=8EAM=0A>To:=C2=A0Turkey Breast=0A>Cc:=C2=A0bitcoin-develop=
ment@lists.sourceforge.net=0A>=C2=A0=0A>Bitcoin-Qt on master does send it n=
ow although it doesn't affect anything, but as old pre-filtering versions w=
ill continue to exist, you'll always have to be able to deserialize version=
 messages without it.=0A>=0A>=0A>Bitcoin version messages have always had v=
ariable length, look at how the code is written in main.cpp. If you didn't =
experience issues until now all it means is that no sufficiently old nodes =
were talking to yours.=0A>=0A>=0A>The standard does not say it should appea=
r. Read it again - BIP 37 says about the new version message field:=0A>If f=
alse then broadcast transactions will not be announced until a filter{load,=
add,clear} command is received. If missing or true, no change in protocol b=
ehaviour occurs.=0A> =0A>=0A>=0A>=0A>On Wed, Jun 19, 2013 at 12:33 PM, Turk=
ey Breast <turkeybreast@yahoo.com> wrote:=0A>=0A>It's a problem if you work=
 with iterators to deserialize the byte stream. Even failing that, it's jus=
t sloppy programming. What happens in the future when new fields are added =
to the version message? It's not a big deal to say that this protocol versi=
on has X number of fields, that (higher) protocol version message has X + N=
 number of fields. Deterministic number of fields per protocol version is s=
ensical and how Bitcoin has been for a long time.=0A>>=0A>>=0A>>And yes, it=
 was a problem for me that caused a lot of confusion why this byte didn't e=
xist in many version messages despite the standard saying it should and the=
 code in bitcoind indicating it should. Nowhere was this written. It doesn'=
t help other implementations to have an unclear behaviour that depends on s=
ome magic from one implementation.=0A>>=0A>>=0A>>=0A>>=0A>>________________=
________________=0A>> From: Mike Hearn <mike@plan99.net>=0A>>To: Turkey Bre=
ast <turkeybreast@yahoo.com> =0A>>Cc: "bitcoin-development@lists.sourceforg=
e.net" <bitcoin-development@lists.sourceforge.net> =0A>>Sent: Wednesday, Ju=
ne 19, 2013 11:39 AM=0A>>=0A>>Subject: Re: [Bitcoin-development] Missing fR=
elayTxes in version message=0A>> =0A>>=0A>>=0A>>It has to be optional becau=
se old clients don't send it, obviously.=0A>>=0A>>=0A>>Why is this even an =
issue? There's no problem with variable length messages in any codebase tha=
t I'm aware of. Is this solving some actual problem?=0A>>=0A>>=0A>>=0A>>On =
Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast <turkeybreast@yahoo.com> wrote=
:=0A>>=0A>>That's me. I never said to make all messages fixed length. I sai=
d to make a fixed number of fields per protocol. So given a protocol versio=
n number, you know the number of fields in a message. This is not only easi=
er for parsing messages, but just good practice. I don't see why a 1 byte f=
lag needs to be optional anyway.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>_____________=
___________________=0A>>> From: Mike Hearn <mike@plan99.net>=0A>>>To: Turke=
y Breast <turkeybreast@yahoo.com> =0A>>>Cc: Bitcoin Dev <bitcoin-developmen=
t@lists.sourceforge.net> =0A>>>Sent: Tuesday, June 18, 2013 9:48 PM=0A>>>Su=
bject: Re: [Bitcoin-development] Missing fRelayTxes in version message=0A>>=
> =0A>>>=0A>>>=0A>>>It's not a bug (although there was recently a change to=
 make bitcoind/qt always send this field anyway).=C2=A0=0A>>>=0A>>>=0A>>>I =
don't know where Amir is going with BIP 60. Version messages have always be=
en variable length. There's nothing inherent in the Bitcoin protocol that s=
ays all messages are fixed length, indeed, tx messages are allowed to have =
arbitrary data appended after them that gets relayed.=0A>>>=0A>>>=0A>>>=0A>=
>>On Tue, Jun 18, 2013 at 7:45 PM, Turkey Breast <turkeybreast@yahoo.com> w=
rote:=0A>>>=0A>>>See this BIP. I'm not sure if this is a bug or what, but i=
t would be good if messages always had a fixed number of fields per protoco=
l version.=0A>>>>=0A>>>>=0A>>>>https://en.bitcoin.it/wiki/BIP_0060#Code_Upd=
ates=0A>>>>=0A>>>>=0A>>>>This BIP details everything that needs to be done =
and proposes a protocol upgrade.=0A>>>>=0A>>>>-----------------------------=
-------------------------------------------------=0A>>>>This SF.net email i=
s 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-develop=
ment@lists.sourceforge.net=0A>>>>https://lists.sourceforge.net/lists/listin=
fo/bitcoin-development=0A>>>>=0A>>>>=0A>>>=0A>>>=0A>>>=0A>>>---------------=
---------------------------------------------------------------=0A>>>This S=
F.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/l=
istinfo/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-developm=
ent@lists.sourceforge.net=0A>>https://lists.sourceforge.net/lists/listinfo/=
bitcoin-development=0A>>=0A>>=0A>
---350752386-1724672238-1371709237=:57104
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt">I never said that Bit=
coin message field lengths should always be the same. But before this chang=
e they certainly were constant per protocol version. All I'm saying is that=
 optional lengths shouldn't be used (a field exists or not) and for every f=
ield change, the protocol version should be upgraded.<br><br>Now that fRela=
yTxes is part of the protocol, the version number should be upgraded to ref=
lect this fact.<br><div><br></div>  <div style=3D"font-family: times new ro=
man, new york, times, serif; font-size: 12pt;"> <div style=3D"font-family: =
times new roman, new york, times, serif; font-size: 12pt;"> <div dir=3D"ltr=
"> <hr size=3D"1">  <font face=3D"Arial" size=3D"2"> <b><span style=3D"font=
-weight:bold;">From:</span></b> Mike Hearn &lt;mike@plan99.net&gt;<br> <b><=
span style=3D"font-weight: bold;">To:</span></b> Paul Lyon &lt;pmlyon@hotma=
il.ca&gt;
 <br><b><span style=3D"font-weight: bold;">Cc:</span></b> Turkey Breast &lt=
;turkeybreast@yahoo.com&gt;; "bitcoin-development@lists.sourceforge.net" &l=
t;bitcoin-development@lists.sourceforge.net&gt; <br> <b><span style=3D"font=
-weight: bold;">Sent:</span></b> Wednesday, June 19, 2013 3:20 PM<br> <b><s=
pan style=3D"font-weight: bold;">Subject:</span></b> Re: [Bitcoin-developme=
nt] Missing fRelayTxes in version message<br> </font> </div> <div class=3D"=
y_msg_container"><br><div id=3D"yiv6839677818"><div dir=3D"ltr">If you want=
 to criticise the Bitcoin protocol for sloppyness, the variable length of s=
ome messages isn't where I'd start.<div><br></div><div>Note that ping has t=
he same issue, its length has changed over time to include the nonce.</div>=
=0A<div><br></div><div style=3D"">If your parser can't handle that kind of =
thing, you need to fix it. The protocol has always worked that way.</div><d=
iv style=3D""><br></div></div><div class=3D"yiv6839677818gmail_extra"><br><=
br><div class=3D"yiv6839677818gmail_quote">=0AOn Wed, Jun 19, 2013 at 3:03 =
PM, Paul Lyon <span dir=3D"ltr">&lt;<a rel=3D"nofollow" ymailto=3D"mailto:p=
mlyon@hotmail.ca" target=3D"_blank" href=3D"mailto:pmlyon@hotmail.ca">pmlyo=
n@hotmail.ca</a>&gt;</span> wrote:<br><blockquote class=3D"yiv6839677818gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">=0A<div><div dir=3D"ltr" style=3D"font-family:Calibri,;font-size:12=
pt;">=0A<div>I=E2=80=99m also running into this exact same issue with my pa=
rser, now I understand why the relay field behavior I was seeing&nbsp;doesn=
=E2=80=99t match the wiki.</div><div>&nbsp;</div><div>So to parse a version=
 message, you can=E2=80=99t rely on the protocol version? You have to know =
how long the payload is, and then parse the message accordingly? I agree wi=
th Turkey Breast, this seems a bit sloppy to me.</div>=0A<div>&nbsp;</div><=
div>Paul</div><div>&nbsp;</div><div>P.S. I=E2=80=99ve never used a dev mail=
ing list before and I want to get involved with the Bitcoin dev community, =
so let me know if I=E2=80=99m horribly violating any&nbsp;mailing list etiq=
uette. <span style=3D"">=F0=9F=98=8A</span></div>=0A<div>&nbsp;</div><div s=
tyle=3D"padding-top:5px;border-top-color:rgb(229,229,229);border-top-width:=
1px;border-top-style:solid;"><div><font style=3D"line-height:15pt;letter-sp=
acing:0.02em;font-family:Calibri,;font-size:11pt;" face=3D"Calibri, 'Segoe =
UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic'=
, 'Khmer UI', 'Nirmala UI', Tunga, 'Lao UI', Ebrima, sans-serif"><b>From:</=
b>&nbsp;Mike Hearn<br>=0A<b>Sent:</b>&nbsp;=E2=80=8EWednesday=E2=80=8E, =E2=
=80=8EJune=E2=80=8E =E2=80=8E19=E2=80=8E, =E2=80=8E2013 =E2=80=8E7=E2=80=8E=
:=E2=80=8E43=E2=80=8E =E2=80=8EAM<br><b>To:</b>&nbsp;Turkey Breast<br><b>Cc=
:</b>&nbsp;<a rel=3D"nofollow" ymailto=3D"mailto:bitcoin-development@lists.=
sourceforge.net" target=3D"_blank" href=3D"mailto:bitcoin-development@lists=
.sourceforge.net">bitcoin-development@lists.sourceforge.net</a></font></div=
>=0A</div><div><div class=3D"yiv6839677818h5"><div>&nbsp;</div><div dir=3D"=
ltr">Bitcoin-Qt on master does send it now although it doesn't affect anyth=
ing, but as old pre-filtering versions will continue to exist, you'll alway=
s have to be able to deserialize version messages without it.<div>=0A=0A<br=
></div><div>Bitcoin version messages have always had variable length, look =
at how the code is written in main.cpp. If you didn't experience issues unt=
il now all it means is that no sufficiently old nodes were talking to yours=
.</div>=0A=0A<div><br></div><div>The standard does not say it should appear=
. Read it again - BIP 37 says about the new version message field:</div><di=
v><table style=3D"line-height:19.2px;border-collapse:collapse;font-size:12.=
8px;background-color:rgb(249,249,249);font-family:sans-serif;margin:1em 0px=
;border:1px solid rgb(170,170,170);">=0A=0A<tbody><tr><td style=3D"padding:=
0.2em;border:1px solid rgb(170,170,170);">If false then broadcast transacti=
ons will not be announced until a filter{load,add,clear} command is receive=
d. <b>If missing or true</b>, no change in protocol behaviour occurs.<br>=
=0A=0A</td></tr></tbody></table></div></div><div class=3D"yiv6839677818gmai=
l_extra"><br><br><div class=3D"yiv6839677818gmail_quote">On Wed, Jun 19, 20=
13 at 12:33 PM, Turkey Breast <span dir=3D"ltr">&lt;<a rel=3D"nofollow" tit=
le=3D"mailto:turkeybreast@yahoo.com" ymailto=3D"mailto:turkeybreast@yahoo.c=
om" target=3D"_blank" href=3D"mailto:turkeybreast@yahoo.com">turkeybreast@y=
ahoo.com</a>&gt;</span> wrote:<br>=0A=0A<blockquote class=3D"yiv6839677818g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid;"><div=
><div style=3D"font-family:times new roman, new york, times, serif;font-siz=
e:12pt;">=0A<div><span>It's a problem if you work with iterators to deseria=
lize the byte stream. Even 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 say that this protocol version has X number of fields,=
 that (higher) protocol version message has X + N number of fields. Determi=
nistic number of fields per protocol version is sensical and how Bitcoin ha=
s been for a long time.</span></div>=0A=0A<div style=3D"font-family:times n=
ew roman, new york, times, serif;font-size:16px;font-style:normal;backgroun=
d-color:transparent;"><br><span></span></div><div style=3D"font-family:time=
s new roman, new york, times, serif;font-size:16px;font-style:normal;backgr=
ound-color:transparent;">=0A=0A<span>And yes, it was a problem for me=0A th=
at caused a lot of confusion why this byte didn't exist in many version mes=
sages despite the standard saying it should and the code in bitcoind indica=
ting it should. Nowhere was this written. It doesn't help other implementat=
ions to have an unclear behaviour that depends on some magic from one imple=
mentation.<br>=0A=0A</span></div><div><br></div>  <div style=3D"font-family=
:times new roman, new york, times, serif;font-size:12pt;"> <div style=3D"fo=
nt-family:times new roman, new york, times, serif;font-size:12pt;"> <div di=
r=3D"ltr"> <hr size=3D"1">  <font face=3D"Arial"><div>=0A=0A <b><span style=
=3D"font-weight:bold;">From:</span></b> Mike Hearn &lt;<a rel=3D"nofollow" =
title=3D"mailto:mike@plan99.net" ymailto=3D"mailto:mike@plan99.net" target=
=3D"_blank" href=3D"mailto:mike@plan99.net">mike@plan99.net</a>&gt;<br> <b>=
<span style=3D"font-weight:bold;">To:</span></b> Turkey Breast &lt;<a rel=
=3D"nofollow" title=3D"mailto:turkeybreast@yahoo.com" ymailto=3D"mailto:tur=
keybreast@yahoo.com" target=3D"_blank" href=3D"mailto:turkeybreast@yahoo.co=
m">turkeybreast@yahoo.com</a>&gt; <br>=0A=0A</div><b><span style=3D"font-we=
ight:bold;">Cc:</span></b> "<a rel=3D"nofollow" title=3D"mailto:bitcoin-dev=
elopment@lists.sourceforge.net" ymailto=3D"mailto:bitcoin-development@lists=
.sourceforge.net" target=3D"_blank" href=3D"mailto:bitcoin-development@list=
s.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>" &lt;<a re=
l=3D"nofollow" title=3D"mailto:bitcoin-development@lists.sourceforge.net" y=
mailto=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_blan=
k" href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-develo=
pment@lists.sourceforge.net</a>&gt; <br>=0A=0A <b><span style=3D"font-weigh=
t:bold;">Sent:</span></b> Wednesday, June 19, 2013 11:39 AM<div><div><br> <=
b><span style=3D"font-weight:bold;">Subject:</span></b> Re: [Bitcoin-develo=
pment] Missing fRelayTxes in version message<br>=0A=0A </div></div></font> =
</div><div><div> <div><br>=0A<div><div dir=3D"ltr">It has to be optional be=
cause old clients don't send it, obviously.<div><br></div><div>Why is this =
even an issue? There's no problem with variable length messages in any code=
base that I'm aware of. Is this solving some actual problem?</div>=0A=0A=0A=
</div><div><br><br><div>On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast <sp=
an dir=3D"ltr">&lt;<a rel=3D"nofollow" title=3D"mailto:turkeybreast@yahoo.c=
om" ymailto=3D"mailto:turkeybreast@yahoo.com" target=3D"_blank" href=3D"mai=
lto:turkeybreast@yahoo.com">turkeybreast@yahoo.com</a>&gt;</span> wrote:<br=
>=0A=0A<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;borde=
r-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid=
;"><div><div style=3D"font-family:times new roman, new york, times, serif;f=
ont-size:12pt;">=0A<div><span>That's me. I never said to make all messages =
fixed length. I said to make a fixed number of fields per protocol. So give=
n a protocol version number, you know the number of fields in a message. Th=
is is not only easier for parsing messages, but just good practice. I don't=
 see why a 1 byte flag needs to be optional anyway.<br>=0A=0A=0A</span></di=
v><div><div><br></div>  </div><div style=3D"font-family:times new roman, ne=
w york, times, serif;font-size:12pt;"><div> </div><div style=3D"font-family=
:times new roman, new york, times, serif;font-size:12pt;">=0A<div> <div dir=
=3D"ltr"> <hr size=3D"1">  <font face=3D"Arial"> <b><span style=3D"font-wei=
ght:bold;">From:</span></b> Mike Hearn &lt;<a rel=3D"nofollow" title=3D"mai=
lto:mike@plan99.net" ymailto=3D"mailto:mike@plan99.net" target=3D"_blank" h=
ref=3D"mailto:mike@plan99.net">mike@plan99.net</a>&gt;<br>=0A <b><span styl=
e=3D"font-weight:bold;">To:</span></b> Turkey Breast &lt;<a rel=3D"nofollow=
" title=3D"mailto:turkeybreast@yahoo.com" ymailto=3D"mailto:turkeybreast@ya=
hoo.com" target=3D"_blank" href=3D"mailto:turkeybreast@yahoo.com">turkeybre=
ast@yahoo.com</a>&gt; <br>=0A=0A<b><span style=3D"font-weight:bold;">Cc:</s=
pan></b>=0A Bitcoin Dev &lt;<a rel=3D"nofollow" title=3D"mailto:bitcoin-dev=
elopment@lists.sourceforge.net" ymailto=3D"mailto:bitcoin-development@lists=
.sourceforge.net" target=3D"_blank" href=3D"mailto:bitcoin-development@list=
s.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>&gt; <br> <=
b><span style=3D"font-weight:bold;">Sent:</span></b> Tuesday, June 18, 2013=
 9:48 PM<br>=0A=0A=0A <b><span style=3D"font-weight:bold;">Subject:</span><=
/b> Re: [Bitcoin-development] Missing fRelayTxes in version message<br> </f=
ont> </div></div><div><div> <div><br>=0A<div><div dir=3D"ltr">It's not a bu=
g (although there was recently a change to make bitcoind/qt always send thi=
s field anyway).&nbsp;<div><br></div><div>I don't know where Amir is going =
with BIP 60. Version messages have always been variable length. There's not=
hing inherent in the Bitcoin protocol that says all messages are fixed leng=
th, indeed, tx messages are allowed to have arbitrary data appended after t=
hem that gets relayed.</div>=0A=0A=0A=0A</div><div><br><br><div>On Tue, Jun=
 18, 2013 at 7:45 PM, Turkey Breast <span dir=3D"ltr">&lt;<a rel=3D"nofollo=
w" title=3D"mailto:turkeybreast@yahoo.com" ymailto=3D"mailto:turkeybreast@y=
ahoo.com" target=3D"_blank" href=3D"mailto:turkeybreast@yahoo.com">turkeybr=
east@yahoo.com</a>&gt;</span> wrote:<br>=0A=0A<blockquote style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid;"><div><div style=3D"font-family:ti=
mes new roman, new york, times, serif;font-size:12pt;">=0A<div>See this BIP=
. I'm not sure if this is a bug or what, but it would be good if messages a=
lways had a fixed number of fields per protocol version.</div>=0A=0A=0A<div=
><br></div><div style=3D"font-family:times new roman, new york, times, seri=
f;font-size:16px;font-style:normal;background-color:transparent;"><a rel=3D=
"nofollow" title=3D"https://en.bitcoin.it/wiki/BIP_0060#Code_Updates" targe=
t=3D"_blank" href=3D"https://en.bitcoin.it/wiki/BIP_0060#Code_Updates">http=
s://en.bitcoin.it/wiki/BIP_0060#Code_Updates</a></div>=0A=0A=0A=0A<div styl=
e=3D"font-family:times new roman, new york, times, serif;font-size:16px;fon=
t-style:normal;background-color:transparent;"><br></div><div style=3D"font-=
family:times new roman, new york, times, serif;font-size:16px;font-style:no=
rmal;background-color:transparent;">=0A=0A=0A=0AThis BIP details everything=
 that needs to be done and proposes a protocol upgrade.<br></div></div></di=
v><br>---------------------------------------------------------------------=
---------<br>=0AThis <a rel=3D"nofollow" title=3D"http://sf.net/" target=3D=
"_blank" href=3D"http://sf.net/">SF.net</a> email is sponsored by Windows:<=
br>=0A<br>=0ABuild for Windows Store.<br>=0A<br>=0A<a rel=3D"nofollow" titl=
e=3D"http://p.sf.net/sfu/windows-dev2dev" target=3D"_blank" href=3D"http://=
p.sf.net/sfu/windows-dev2dev">http://p.sf.net/sfu/windows-dev2dev</a><br>__=
_____________________________________________<br>=0ABitcoin-development mai=
ling list<br>=0A<a rel=3D"nofollow" title=3D"mailto:Bitcoin-development@lis=
ts.sourceforge.net" ymailto=3D"mailto:Bitcoin-development@lists.sourceforge=
.net" target=3D"_blank" href=3D"mailto:Bitcoin-development@lists.sourceforg=
e.net">Bitcoin-development@lists.sourceforge.net</a><br>=0A<a rel=3D"nofoll=
ow" title=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-developme=
nt" target=3D"_blank" href=3D"https://lists.sourceforge.net/lists/listinfo/=
bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-d=
evelopment</a><br>=0A=0A<br></blockquote></div><br></div>=0A</div><br><br><=
/div> </div></div></div> </div>  </div></div><br>--------------------------=
----------------------------------------------------<br>=0AThis SF.net emai=
l is sponsored by Windows:<br>=0A<br>=0ABuild for Windows Store.<br>=0A<br>=
=0A<a rel=3D"nofollow" title=3D"http://p.sf.net/sfu/windows-dev2dev" target=
=3D"_blank" href=3D"http://p.sf.net/sfu/windows-dev2dev">http://p.sf.net/sf=
u/windows-dev2dev</a><br>_______________________________________________<br=
>=0ABitcoin-development mailing list<br>=0A<a rel=3D"nofollow" title=3D"mai=
lto:Bitcoin-development@lists.sourceforge.net" ymailto=3D"mailto:Bitcoin-de=
velopment@lists.sourceforge.net" target=3D"_blank" href=3D"mailto:Bitcoin-d=
evelopment@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net=
</a><br>=0A<a rel=3D"nofollow" title=3D"https://lists.sourceforge.net/lists=
/listinfo/bitcoin-development" target=3D"_blank" href=3D"https://lists.sour=
ceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.n=
et/lists/listinfo/bitcoin-development</a><br>=0A=0A<br></blockquote></div><=
br></div>=0A</div><br><br></div> </div></div></div> </div>  </div></div><br=
>--------------------------------------------------------------------------=
----<br>=0AThis SF.net email is sponsored by Windows:<br>=0A<br>=0ABuild fo=
r Windows Store.<br>=0A<br>=0A<a rel=3D"nofollow" title=3D"http://p.sf.net/=
sfu/windows-dev2dev" target=3D"_blank" href=3D"http://p.sf.net/sfu/windows-=
dev2dev">http://p.sf.net/sfu/windows-dev2dev</a><br>_______________________=
________________________<br>=0ABitcoin-development mailing list<br>=0A<a re=
l=3D"nofollow" title=3D"mailto:Bitcoin-development@lists.sourceforge.net" y=
mailto=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_blan=
k" href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>=0A<a rel=3D"nofollow" title=3D"https://=
lists.sourceforge.net/lists/listinfo/bitcoin-development" target=3D"_blank"=
 href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development">=
https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>=0A=
=0A<br></blockquote></div><br></div>=0A</div></div></div></div></blockquote=
></div><br></div></div><br><br></div> </div> </div>  </div></body></html>
---350752386-1724672238-1371709237=:57104--