From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BA0D1057 for ; 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 ; Fri, 16 Mar 2018 08:27:50 +0000 (UTC) Received: by mail-wm0-f42.google.com with SMTP id n3so1473127wmd.1 for ; 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 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: References: <620d4b5e-61c4-4501-9787-c73109908418@achow101.com> <8C660724-A76D-44C1-9140-AD3215768CE1@voskuil.org> <1659f63f-5003-40d5-85a9-11e7a8f34edb@achow101.com> To: Andrew Chow 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
Agree, thanks for the input= Andrew.

e

On Mar 15, 2018, at 16:44,= Andrew Chow <achow101-lis= ts@achow101.com> wrote:

=20 =20 =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 - 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.

IMO your best solution would be to drop peers for protocol noncompliance.

Andrew


On 03/15/2018 05:17 AM, Eric Voskuil wrote:
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.

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. 

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

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.

e

On Mar 9, 2018, at 16:33, Andrew Chow via bitcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:

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

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?

Andrew


On 03/09/2018 02:50 AM, Eric Voskuil via bitcoin-dev wrote:
/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




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.o=
rg
https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________ bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/bitcoin-dev

=20
= --Apple-Mail-2ACA7423-0E09-4ECC-8AC1-98AD18855652--