summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEric Voskuil <eric@voskuil.org>2018-03-16 09:27:47 +0100
committerbitcoindev <bitcoindev@gnusha.org>2018-03-16 08:27:51 +0000
commitf532ce669ad21b46a683c5d9ee2cfbf5d38856e6 (patch)
tree99016060ceb8242823e7d5d7479901198755399e
parent3b801a91dd73034dff9ce07da3583b8340d15d40 (diff)
downloadpi-bitcoindev-f532ce669ad21b46a683c5d9ee2cfbf5d38856e6.tar.gz
pi-bitcoindev-f532ce669ad21b46a683c5d9ee2cfbf5d38856e6.zip
Re: [bitcoin-dev] version.relay behavior change
-rw-r--r--35/a10351e21c0d9563dc0a75cbd5da40e3a5112f297
1 files changed, 297 insertions, 0 deletions
diff --git a/35/a10351e21c0d9563dc0a75cbd5da40e3a5112f b/35/a10351e21c0d9563dc0a75cbd5da40e3a5112f
new file mode 100644
index 000000000..66bc75a37
--- /dev/null
+++ b/35/a10351e21c0d9563dc0a75cbd5da40e3a5112f
@@ -0,0 +1,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 &lt;<a href=3D"mailto:achow101-lists@achow101.com">achow101-lis=
+ts@achow101.com</a>&gt; 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.&nbsp;</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 &lt;<a href=3D=
+"mailto:bitcoin-dev@lists.linuxfoundation.org" moz-do-not-send=3D"true">bitc=
+oin-dev@lists.linuxfoundation.org</a>&gt;
+ 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--
+