diff options
author | Eric Voskuil <eric@voskuil.org> | 2018-03-16 09:27:47 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-03-16 08:27:51 +0000 |
commit | f532ce669ad21b46a683c5d9ee2cfbf5d38856e6 (patch) | |
tree | 99016060ceb8242823e7d5d7479901198755399e | |
parent | 3b801a91dd73034dff9ce07da3583b8340d15d40 (diff) | |
download | pi-bitcoindev-f532ce669ad21b46a683c5d9ee2cfbf5d38856e6.tar.gz pi-bitcoindev-f532ce669ad21b46a683c5d9ee2cfbf5d38856e6.zip |
Re: [bitcoin-dev] version.relay behavior change
-rw-r--r-- | 35/a10351e21c0d9563dc0a75cbd5da40e3a5112f | 297 |
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 <<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-- + |