Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8B90EC0051 for ; Thu, 20 Aug 2020 14:14:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 7A926876CF for ; Thu, 20 Aug 2020 14:14:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9T9GkYXH4xt for ; Thu, 20 Aug 2020 14:14:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by whitealder.osuosl.org (Postfix) with ESMTPS id 2B92487660 for ; Thu, 20 Aug 2020 14:14:32 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1k8lKp-0003KJ-9M; Thu, 20 Aug 2020 10:14:31 -0400 Date: Thu, 20 Aug 2020 10:13:39 -0400 From: "David A. Harding" To: Eric Voskuil , Bitcoin Protocol Discussion Message-ID: <20200820141339.gbbr5rewi4yvoarl@ganymede> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="br7d5rqh26itcatr" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 14:14:34 -0000 --br7d5rqh26itcatr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrot= e: > A requirement to ignore unknown (invalid) messages is [...] a protocol > breaking change=20 I don't think it is. The proposed BIP, as currently written, only tells nodes to ignore unknown messages during peer negotiation. The only case where this will happen so far is BIP339, which says: The wtxidrelay message must be sent in response to a VERSION message from a peer whose protocol version is >=3D 70016, and prior to sending a VERACK So unless you signal support for version >=3D70016, you'll never receive an unknown message. (And, if you do signal, you probably can't claim that you were unaware of this new requirement, unless you were using a non-BIP protocol like xthin[1]). However, perhaps this new proposed BIP could be a bit clearer about its expectations for future protocol upgrades by saying something like: Nodes implementing this BIP MUST also not send new negotiation message types to nodes whose protocol version is less than 70017. That should promote backwards compatibility. If you don't want to ignore unknown negotiation messages between `version` and `verack`, you can just set your protocol version to a max of 70016. > A requirement to ignore unknown (invalid) messages is [...] poor > protocol design. The purpose of version negotiation is to determine > the set of valid messages.=20 To be clear, the proposed requirement to ignore unknown messages is limited in scope to the brief negotiation phase between `version` and `verack`. If you want to terminate connections (or do whatever) on receipt of an unknown message, you can do that at any other time. > Changes to version negotiation itself are very problematic. For whom? > The only limitation presented by versioning is that the system is > sequential.=20 That seems like a pretty significant limitation to decentralized protocol development. I think there are currently several people who want to run long-term experiements for new protocol features using open source opt-in codebases that anyone can run, and it would be advantageous to them to have a flexible and lightweight feature negotiation system like this proposed method. > As such, clients that do not wish to implement (or operators who do > not wish to enable) them are faced with a problem when wanting to > support later features. This is resolvable by making such features > optional at the new protocol level. This allows each client to limit > its communication to the negotiated protocol, and allows ignoring of > known but unsupported/disabled features. I don't understand this. How do two peers negotiate a set of two or more optional features using only the exchange of single numbers? For example: - Node A supports Feature X (implemented in protocol version 70998) and Fea= ture Y (version 70999). - Node B does not support X but does want to use Y; what does it use for its protocol version number when establishing a connection with node A? --- Overall, I like the proposed BIP and the negotiation method it describes. Cheers, -Dave [1] This is not a recommendation for xthin, but I do think it's an example of the challenges of using a shared linear version number scheme for protocol negotiation in a decentralized system where different teams don't necessarily get along well with each other. https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544= 173f03d45373b#diff-c61070c281aed6ded69036c08bd08addR12 --br7d5rqh26itcatr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl8+hRMACgkQ2dtBqWwi adMRDBAAm9Dim9S9a75qEoL8dRKDBDO+WMvLP2jqL3VktNjpc6amrftQURKBipiy 0FKNxSG0wKXxg7ZKrxUy8/NpJXqwp7BewG5atX4YwpNLJrhcGSQESIYcTVR5ssNs tRsVCR0vYW2gsOt9Jc/43FEa5Ed5wxtnhk3uRn/+OyPCqk3zbCaRcXlaMbmrVezY FHnYEYtRtsiQDkJKdY2liviIAv3R5Kgch3T7CMuSFvWDLRxFyYXTlwI1cNzRmWyR /u78NwCyR0QhhJYyZmWgYUcODu/4+1bjVzW17CabdGlQ6Z32hfN69OyMHyqisNbv IqN8fGsc44tr+wz7ZkIWTCshNbfUDd0FGwLYndhQLu4EUszpYHMuXPeVGq7zwpKv pYH30KlyflFRnkFQtvtK5cxa8n5w+3dapXyK0H7TSDJUe2PU2uIw9qZkBlhBgdei aWBfIZq4wEyHpAHmv954ZpEPZgRD/xU7FX2dm/ebwOTebIJM4ayVzmbdqa+qiMiQ PlqiMfA9/rzA3cqarRJCLyJcyvXo4Q4CLfINWyZlw0Wk9liO+49L+cqKEKNwEwIz iIr4U9UXY88Ttw+jn15eGaU/WJgU4gSwTgTn3vPcZ6UU+JkUjmj8IXZtJiN1zrFu 3wLhw1iMaPc2gmYy3b/KxgGj1on7iitYIZo54GwTemHi4PcrzT8= =XgyK -----END PGP SIGNATURE----- --br7d5rqh26itcatr--