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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BA0D1057
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Mar 2018 08:27:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0DB22C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Mar 2018 08:27:50 +0000 (UTC)
Received: by mail-wm0-f42.google.com with SMTP id n3so1473127wmd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Mar 2018 01:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=E6OJlD1otz2Qb6Cg348kqdw2v6k/fGfeXrjUqhDWy04=;
b=YYDaq3ImpljGMRRE9+u/b3eVHG3oqgqBUy0VWxgDEFDQ7zRcFFunp5mvfHLYKALt31
9XJ2VbMDujiEVgJMPe7UJA0j8TxqgCBEKUjZa2VMvf3QtdTKQZWhxPO4FSkCAz/KQzlj
IlF2y/0tVnSg6p2KLvN1zNBRXomo1JO9enXTfCcy4TU8sh8UkQv1kH5mDi9nf/FowgZx
W0l0NngpHHQsfeOXdK3PO72iYk+XOfHbidwrv8yJUgUo8lbSb5YLEgXC+YL1Mt4vqpYD
9nnHZkk42PbKdiizmww3aF0ob4heJlq3LqWt2s+G8+WPzvBwZdoWLAsFNsDSYY0qu1IQ
nmeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=E6OJlD1otz2Qb6Cg348kqdw2v6k/fGfeXrjUqhDWy04=;
b=rPzXL4wKg6uh9ONlb09eix4Ggdz9/4niRBAMdIq4Tbd4Wm0p5XUtvW9+GdUYFZUTk1
n/Bms49JxNZJmypAns8zCiCMt+H681k159fp46WiOlkZcI0SjH5TWhcWPuPQoNhyDKj0
g58bfNfeaE6bWg+Asi/v3dYAlpmPqCkj3+tuCO9g2pTSI22p5/VaWNcfusbhtDgTEU9+
7/CyJRv/92BcC3Ts/Ceqf9aDVZWz+MBRbNkRcWsVAvuB2FmSd46MepVcB451SpgB5SUL
m7YhRZEu1BJxBE2sI6ocOCVxnlom+qWpN7oXMM+zCvJbKf13V48N7TWtcgwDWYlM9PxD
NTTg==
X-Gm-Message-State: AElRT7GP5KR7uTwK1ZKK3czIId4ktJhUbHGrHGaLmotoZYTTpoWd7gkO
7GHfT+M3zfnVbGV9NF+h4MpRn1dZiOw=
X-Google-Smtp-Source: AG47ELsYaGN6SGrLofwNPE4mS8YdJHNESsRNFHo9UwE8tn3QPcaeUXdZ87OFzKrCFrPkVU2ibY53uA==
X-Received: by 10.80.166.211 with SMTP id f19mr1573239edc.266.1521188869171;
Fri, 16 Mar 2018 01:27:49 -0700 (PDT)
Received: from [172.29.7.121] ([89.27.175.124])
by smtp.gmail.com with ESMTPSA id s8sm3636916edk.28.2018.03.16.01.27.47
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 16 Mar 2018 01:27:48 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-2ACA7423-0E09-4ECC-8AC1-98AD18855652
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <1659f63f-5003-40d5-85a9-11e7a8f34edb@achow101.com>
Date: Fri, 16 Mar 2018 09:27:47 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <E756D0FC-F6E1-4DD8-8F96-E144E3D88E1D@voskuil.org>
References: <e2fd3226-91ff-d0ca-67c7-2c4a98c6628f@voskuil.org>
<620d4b5e-61c4-4501-9787-c73109908418@achow101.com>
<8C660724-A76D-44C1-9140-AD3215768CE1@voskuil.org>
<1659f63f-5003-40d5-85a9-11e7a8f34edb@achow101.com>
To: Andrew Chow <achow101-lists@achow101.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 16 Mar 2018 14:17:53 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] version.relay behavior change
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2018 08:27:51 -0000
--Apple-Mail-2ACA7423-0E09-4ECC-8AC1-98AD18855652
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Agree, thanks for the input Andrew.
e
> On Mar 15, 2018, at 16:44, Andrew Chow <achow101-lists@achow101.com> wrote=
:
>=20
> I don't think the nodes that you are connecting to that have this behavior=
are actually forked from Bitcoin Core. It seems more like fake nodes - node=
s that don't actually do any verification or follow the protocol. Such fake n=
odes can set whatever user agent they want, common ones being Bitcoin Core's=
user agents.
>=20
> IMO your best solution would be to drop peers for protocol noncompliance.
>=20
> Andrew
>=20
>> On 03/15/2018 05:17 AM, Eric Voskuil wrote:
>> Thanks for the reply Andrew. I=E2=80=99ve reviewed the relevant Core sour=
ces and I do not see any problem. We have also synced against a Core node lo=
cally and not seen the problem.
>>=20
>> The reason I suspected it was Core is that it is very common and all of t=
he User Agents are consistent (with an occasional exception for forked nodes=
). So there=E2=80=99s no easy way to determine what sort of nodes we are see=
ing.=20
>>=20
>> We tend to cycle through many more connections during sync than a Core no=
de, so may just be seeing it more frequently, but I assume Core would log th=
is behavior as well. Even so, seeing that wouldn=E2=80=99t help much. I=E2=80=
=99m as certain as I can be at this point that we are setting the flag and v=
ersion correctly (and that we do not set bip37 filters).
>>=20
>> This behavior started infrequently with 0.14.0 peers and has become more c=
ommon over time. Just wondering at this point what fork would report as Core=
and be that common? We used to drop peers that did this (for protocol nonco=
mpliance), and I=E2=80=99m considering reinstating that behavior.
>>=20
>> e
>>=20
>> On Mar 9, 2018, at 16:33, Andrew Chow via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>>=20
>>> Looking through the code, I don't think that this behavior has changed. A=
re you sure that you are actually connected to Satoshi:0.15.0 nodes and not a=
node that has simply set their user-agent to that (i.e. not a real Satoshi:=
0.15.0 node)?
>>>=20
>>> If what you are seeing is true, it is likely a bug and not an intentiona=
l change. In that case, can you provide specific details on how to reproduce=
?
>>>=20
>>> Andrew
>>>=20
>>>> On 03/09/2018 02:50 AM, Eric Voskuil via bitcoin-dev wrote:
>>>> /Satoshi:0.15.0/ and later nodes appear to be no longer honoring the
>>>> version.relay=3Dfalse flag (BIP37). Could someone familiar with the cha=
nge
>>>> please explain the rational?
>>>>=20
>>>> Thanks,
>>>>=20
>>>> e
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>=20
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
--Apple-Mail-2ACA7423-0E09-4ECC-8AC1-98AD18855652
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>Agree, thanks for the input=
Andrew.</div><div><br></div><div>e</div><div><br>On Mar 15, 2018, at 16:44,=
Andrew Chow <<a href=3D"mailto:achow101-lists@achow101.com">achow101-lis=
ts@achow101.com</a>> wrote:<br><br></div><blockquote type=3D"cite"><div>
=20
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"=
>
=20
=20
<p>I don't think the nodes that you are connecting to that have this
behavior are actually forked from Bitcoin Core. It seems more like
fake nodes - nodes that don't actually do any verification or
follow the protocol. Such fake nodes can set whatever user agent
they want, common ones being Bitcoin Core's user agents.</p>
<p>IMO your best solution would be to drop peers for protocol
noncompliance.</p>
<p>Andrew<br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 03/15/2018 05:17 AM, Eric Voskuil
wrote:<br>
</div>
<blockquote type=3D"cite" cite=3D"mid:8C660724-A76D-44C1-9140-AD3215768C=
E1@voskuil.org">
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-=
8">
<div>Thanks for the reply Andrew. I=E2=80=99ve reviewed the relevant C=
ore
sources and I do not see any problem. We have also synced
against a Core node locally and not seen the problem.</div>
<div><br>
</div>
<div>The reason I suspected it was Core is that it is very common
and all of the User Agents are consistent (with an occasional
exception for forked nodes). So there=E2=80=99s no easy way to deter=
mine
what sort of nodes we are seeing. </div>
<div><br>
</div>
<div>We tend to cycle through many more connections during sync
than a Core node, so may just be seeing it more frequently, but
I assume Core would log this behavior as well. Even so, seeing
that wouldn=E2=80=99t help much. I=E2=80=99m as certain as I can be a=
t this
point that we are setting the flag and version correctly (and
that we do not set bip37 filters).</div>
<div><br>
</div>
<div>This behavior started infrequently with 0.14.0 peers and has
become more common over time. Just wondering at this point what
fork would report as Core and be that common? We used to drop
peers that did this (for protocol noncompliance), and I=E2=80=99m
considering reinstating that behavior.</div>
<div><br>
</div>
<div>e</div>
<div><br>
On Mar 9, 2018, at 16:33, Andrew Chow via bitcoin-dev <<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" moz-do-not-send=3D"true">bitc=
oin-dev@lists.linuxfoundation.org</a>>
wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3Dutf-8">
<p>Looking through the code, I don't think that this behavior
has changed. Are you sure that you are actually connected to
Satoshi:0.15.0 nodes and not a node that has simply set
their user-agent to that (i.e. not a real Satoshi:0.15.0
node)?</p>
<p>If what you are seeing is true, it is likely a bug and not
an intentional change. In that case, can you provide
specific details on how to reproduce?</p>
<p>Andrew<br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 03/09/2018 02:50 AM, Eric
Voskuil via bitcoin-dev wrote:<br>
</div>
<blockquote type=3D"cite" cite=3D"mid:e2fd3226-91ff-d0ca-67c7-2c4a=
98c6628f@voskuil.org">
<pre wrap=3D"">/Satoshi:0.15.0/ and later nodes appear to be no l=
onger honoring the
version.relay=3Dfalse flag (BIP37). Could someone familiar with the change
please explain the rational?
Thanks,
e
</pre>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">_______________________________________________
bitcoin-dev mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" moz-do-not-send=3D"true">bitcoin-dev@lists.linuxfoundation.o=
rg</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev" moz-do-not-send=3D"true">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type=3D"cite">
<div><span>_______________________________________________</span><br=
>
<span>bitcoin-dev mailing list</span><br>
<span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" moz=
-do-not-send=3D"true">bitcoin-dev@lists.linuxfoundation.org</a></span><br>
<span><a href=3D"https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev" moz-do-not-send=3D"true">https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev</a></span><br>
</div>
</blockquote>
</blockquote>
<br>
=20
</div></blockquote></body></html>=
--Apple-Mail-2ACA7423-0E09-4ECC-8AC1-98AD18855652--
|
