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 647A392B for ; Mon, 13 Feb 2017 10:30:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7B6412F for ; Mon, 13 Feb 2017 10:30:11 +0000 (UTC) Received: by mail-pg0-f41.google.com with SMTP id v184so31688627pgv.3 for ; Mon, 13 Feb 2017 02:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=qvlG9t3JE8G+CIn+Z6Rhmfzg0P+tfgpymJSfxjY8H5Y=; b=Pjri4XlMwMI7INu37b47lbd6oyDVbk7xpdAhOmXUF/GW4bUclhPodMUj48kM7iQGO6 KRLuOq+mOJcZyVGSNrhUsQfsY5lbieK2OoqoMSzH8npvi3XNh/cpEbVX2eYiDVyMkJXl FvYTweQjHBGF79dRfGeT0R8e+mcInkwOKTjkYQX3lGgCOnNy+5TWfLn39f1qHKiBpcRq Z6TQEtI5l/2nqU/N8X2H5pIub5f/cmwUJ8Q6uofraPXqzZbNsoSrEr90XuCQwcE976tt m/mKA1K7Ng7GsDLobX4lnYe1kx3yc79OBnRDrmoCAKzaomkrRDvmLnTO2zbtINUSmRO8 rWvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=qvlG9t3JE8G+CIn+Z6Rhmfzg0P+tfgpymJSfxjY8H5Y=; b=mRBHrSNmCsb+HWbR30ZNDimAN3TimSlJrDeDQYI+jLBeJKc+aJt0AfTOEeo5qScrB1 v8R9dzUrGYhIESALc8uq6afx0mhPttZB/YHWCbasIHoP2CQ8Uy85EVb5Qdoclj0i8XFH E29kYrfgwWkYHm5eu0VRmjdVq1s60ZlOOw1PmHFyEGn32/u+VsLJMeuIAKstdMEwBeoR EZm3fK8mSxfqQNV18BH8y2TEsKlhV46kLqP/ptLkA677ho7PoFAEpeDQ568r9BF5fWdo 4/ejXFs/PRJD+e8ggLbs0gIyZZpbqG1o1TZkRWrLopxs5JRgVObWp10YiyAL9tvUqEWN FrfA== X-Gm-Message-State: AMke39nNG0BVy7zg6uXOJvDJdDJI7h1AiBW1aFV7dbEpkPnQ8tR2xefq5jdSG/DDEoLYmA== X-Received: by 10.98.5.2 with SMTP id 2mr25632527pff.77.1486981811114; Mon, 13 Feb 2017 02:30:11 -0800 (PST) Received: from ?IPv6:2601:600:9000:d69e:29fe:db3d:631d:9499? ([2601:600:9000:d69e:29fe:db3d:631d:9499]) by smtp.gmail.com with ESMTPSA id j78sm20023705pfk.39.2017.02.13.02.30.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 02:30:10 -0800 (PST) To: Jonas Schnelli , Bitcoin Protocol Discussion References: From: Eric Voskuil X-Enigmail-Draft-Status: N0110 Message-ID: <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org> Date: Mon, 13 Feb 2017 02:30:14 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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: Mon, 13 Feb 2017 11:43:24 +0000 Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility 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: Mon, 13 Feb 2017 10:30:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/13/2017 02:07 AM, Jonas Schnelli via bitcoin-dev wrote: >> All adopted BIPs to date have followed this >> pattern. This is not the same and it is not helpful to imply that it i= s >> just following that pattern. >=20 > Look at feefilter BIP 133 > (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backwar= d-compatibility) > or sendheaders BIP130 > (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backwar= d-compatibility) > Isn't it the same there? No. This is what I was referring to. These messages are enabled by protocol version. If they are received by a node below the version at which they are activated, they are unknown messages, implying an invalid peer. The above messages cannot be sent until *after* the version is negotiated. BIP151 violates this rule by allowing the new control message to be sent *before* the version handshake. > Once BIP151 is implemented, it would make sense to bump the protocol > version, but this needs to be done once this has been > implemented/deployed. There are already nodes out there breaking connections based on the BIP. > Or do I make a mistake somewhere? Yes, the ordering of the messages. New messages can only be added after the handshake negotiates the higher version. Otherwise the handshake is both irrelevant (as Pieter is implying) and broken (for all existing protocol versions). >> As for DOS, waste of bandwidth is not something to be ignored. If a pe= er >> is flooding a node with addr message the node can manage it because it= >> understands the semantics of addr messages. If a node is required to >> allow any message that it cannot understand it has no recourse. It >> cannot determine whether it is under attack or if the behavior is >> correct and for proper continued operation must be ignored. > How do you threat any other not known message types? You may be more familiar with non-validating peers. If a message type is not known it is an invalid message and the peer is immediately dropped. We started seeing early drops in handshakes with bcoin nodes because of this issue. > Any peer can send you any type of message anytime. Sure, a peer can do what it wants. It can send photos. But I'm not sure what makes you think it would be correct to maintain the connection when an *invalid* message is received. > Why would your implementation how you threat unknown messages be different for messages specified in BIP151? Because it properly validates the protocol. More than that it supports a configurable protocol range. So by setting the min protocol (below which the node won't connect) and the max protocol (at which it desires to connect) we can observe the behavior of the network at any protocol levels (currently between 31402 and 70013). This is very helpful for a development stack as it allows one to easily test against each protocol level that one wishes to support. e --2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJYoYq2AAoJEDzYwH8LXOFOCx0H/38Fl4DL861CEE6cZXE84Aom qMhuSBiiNEnfZSdHPKLyxbGBb9Wl7rHbqomeM1y2B9fHwgg3ErIGewo1YmJvUAMF h9JmM566a8CQ7FT4RenZ04esYRTu7VuJZ5Ps2gLEMyWZZAf8mAdIJdTwqId0U7zA RV7Pd1xfVBjLx3xCcCrnODUebkk7QB/S2DtlFILxe9lild23L/nvurqpC2yk5UU6 9LltFe+zU/rzUaghEMdmHuh1MNqJNIKE2JnB7V+hqMF2f+SPDQALFGRxUfOx7I16 wAxfbHVSwoCMkxwyMTrUIGhk6PmOsKlLkSOWNvgNccFyzlMznLbf7IOqbiRljpE= =qpCv -----END PGP SIGNATURE----- --2TI1rbMW2hk2VmT0mJ2vqCVI7xvJqp2Pu--