summaryrefslogtreecommitdiff
path: root/f7/5a7e2031fdde2f713224247ad5abed3722e5b5
blob: f9a52273d5c8ed30773655acf67eda259c0ebfd5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <turkeybreast@yahoo.com>) id 1UpYEh-0001Z3-Hs
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Jun 2013 06:20:47 +0000
X-ACL-Warn: 
Received: from nm37-vm0.bullet.mail.bf1.yahoo.com ([72.30.238.200])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1UpYEd-0005mb-Jp
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Jun 2013 06:20:47 +0000
Received: from [98.139.212.150] by nm37.bullet.mail.bf1.yahoo.com with NNFMP;
	20 Jun 2013 06:20:38 -0000
Received: from [98.139.212.224] by tm7.bullet.mail.bf1.yahoo.com with NNFMP;
	20 Jun 2013 06:20:38 -0000
Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP;
	20 Jun 2013 06:20:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 20455.959.bm@omp1033.mail.bf1.yahoo.com
Received: (qmail 57913 invoked by uid 60001); 20 Jun 2013 06:20:37 -0000
X-YMail-OSG: ejngBSQVM1lG5._ms2oyJ0MQZ0t7pTfAQQrS1N3BvcGutfc
	KtCKJHaYjWMw1BoBjRTUFyR.d_BvYjo8JIlQFje.b4mTB37a8BsBDDOqfNV2
	hXxlaDDsrxhOkHaJkevbP42n_tdH0k_n8j6DSd_l3tsWTL3HHc1NYF9OtSew
	tPlOPJptDtKlGsF7gy2Aw04orIYvKUkBE6moPfc7YY_1PFqu..VQWNA_h1No
	ZVAenCB7asMbY2LXVPGLxPPo7zYMY55k5WELNSXlQOoi7XudSOnpN9iFgqhg
	dtEGoSwX6EF2lujnZjEF.J4dNrOdo0eW911BL53hLBG88PzRg1dA2NzDbk3n
	LItU5wiLgivrVrWDO9e2yY0R_vCgWyM.URKKaA3DQMaCJppxPJ6qirqLz3IB
	q2H6wVNjRrehnYcajvO9dOj6GMx.U7ZulYBcNTTj3rHx43yTczONpx8EcoHc
	X_C7JdK6oeB4heOBtNaqkPf7Wxl4eQU_uk93JIMPDeLkaljBl3TZm3T98D92
	QeNZ_l1PvYsM0JDCdQYhwwZmOZoz9X9.LvFVa2D99DmQsI4EKX4e9mg9A5uE
	6S2BkMf7Nt2ohq1SwXIKgmHFxD_67k1K_nczipUBUgaX_WVH92DrHXYBM9q8 d
Received: from [87.160.177.196] by web162701.mail.bf1.yahoo.com via HTTP;
	Wed, 19 Jun 2013 23:20:37 PDT
X-Rocket-MIMEInfo: 002.001,
	SSBuZXZlciBzYWlkIHRoYXQgQml0Y29pbiBtZXNzYWdlIGZpZWxkIGxlbmd0aHMgc2hvdWxkIGFsd2F5cyBiZSB0aGUgc2FtZS4gQnV0IGJlZm9yZSB0aGlzIGNoYW5nZSB0aGV5IGNlcnRhaW5seSB3ZXJlIGNvbnN0YW50IHBlciBwcm90b2NvbCB2ZXJzaW9uLiBBbGwgSSdtIHNheWluZyBpcyB0aGF0IG9wdGlvbmFsIGxlbmd0aHMgc2hvdWxkbid0IGJlIHVzZWQgKGEgZmllbGQgZXhpc3RzIG9yIG5vdCkgYW5kIGZvciBldmVyeSBmaWVsZCBjaGFuZ2UsIHRoZSBwcm90b2NvbCB2ZXJzaW9uIHNob3VsZCBiZSABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.147.553
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"
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(turkeybreast[at]yahoo.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [72.30.238.200 listed in list.dnswl.org]
	-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 1.0 HTML_MESSAGE           BODY: HTML included in message
	0.3 HTML_FONT_FACE_BAD     BODY: HTML font face is not a word
	-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: 1UpYEd-0005mb-Jp
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 <turkeybreast@yahoo.com>
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 06:20:47 -0000

---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--