From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA5B1C0051 for ; Sun, 16 Aug 2020 20:47:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id A4502204DB for ; Sun, 16 Aug 2020 20:47:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuPj1YPVnvSW for ; Sun, 16 Aug 2020 20:47:54 +0000 (UTC) X-Greylist: delayed 00:45:48 by SQLgrey-1.7.6 Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com [209.85.219.66]) by silver.osuosl.org (Postfix) with ESMTPS id B156A20347 for ; Sun, 16 Aug 2020 20:47:54 +0000 (UTC) Received: by mail-qv1-f66.google.com with SMTP id v1so5030825qvn.3 for ; Sun, 16 Aug 2020 13:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=LYRWL/XVPo2vIoaDJ9XUcnDY3oPgoSvkRotGYd+Mfuw=; b=ty+uR4wFVw0fzoyNudhlmq2unT5eLr9U8TG5+jVwgJctgobE5gUVRlqP3rqpy1tgxl 1zx4k28m6BPNjDWkHEPXdczaHV/GziBZysIGkvgwanyIwSotdF1OcQbWk55FRmcVEvg6 w58bAMpiwOqIbtrlSUQ2f47YQQ63SEPHIY0FfzgEy6HyMqe/XNS8zIC0ks5pU0o+dB23 JmeJjOU1kHfJB8lf9ccjM9BuVyQYitjTV2YtWw5nM/L+JbdDva3JuPSVrtckdgxnz1Ix OU4voFvbATDw0zknlavADqa1L6IW9xkukplaXrRvVpj9+9XXI1aT4T9K5zU/0uJyRnkJ 3G9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:in-reply-to:to; bh=LYRWL/XVPo2vIoaDJ9XUcnDY3oPgoSvkRotGYd+Mfuw=; b=fj4bEpYJrGg9nncv/nyc1yU71h9sUQRcjj44iqFbeJGAvY1TmurPVo757WblzFcmCg 8GG5XZPcQ6KIIoIF75x9e5gHvas6IoJD/rg/wV1vWKy5j3wNqyC5mmGpdweoQGZEpoZG hVZ28vwag3AyYQ1Y0M3N2p1pI8Q3z1Ibi6Ndmj6XBNex34jNLcAvCu09xngSOMBxH+c5 LsYeTEyiIulXjRoAyzEI8CnS4vhUyp9Fhxrs53Wj94qhevOi9vzwXo6TOBAtJNydbn2j bxEs+yDYOrLoD/6xEDQgrb5hj93xzXIiDA2Gpu4m3MyijE/j+XcA4xHsx6Q8p6aMEsxj Z9JA== X-Gm-Message-State: AOAM531HYd0s7BL8aMEHG8mlC/eq1fX5GkZTCUN3JMtl1v2g8aGpHnNz je8lev7qA9GmyFuyQyHRnpSLSI7fRVpCZw== X-Google-Smtp-Source: ABdhPJxUGul8XWZjahXq/JKjAlJ3q9y2Y3FVnMIiVhHwSOrKDyeH5UIZDgZ/nZQqEGZFCKkMkaDzUA== X-Received: by 2002:a17:902:c206:: with SMTP id 6mr1479352pll.169.1597604817043; Sun, 16 Aug 2020 12:06:57 -0700 (PDT) Received: from ?IPv6:2600:380:7066:ce6e:c976:12fb:75f1:c075? ([2600:380:7066:ce6e:c976:12fb:75f1:c075]) by smtp.gmail.com with ESMTPSA id r28sm16193587pfg.158.2020.08.16.12.06.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Aug 2020 12:06:56 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796 Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Sun, 16 Aug 2020 12:06:55 -0700 Message-Id: References: In-Reply-To: To: Suhas Daftuar , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (17G68) X-Mailman-Approved-At: Sun, 16 Aug 2020 21:26:28 +0000 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: Sun, 16 Aug 2020 20:47:56 -0000 --Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A requirement to ignore unknown (invalid) messages is not only a protocol br= eaking change but poor protocol design. The purpose of version negotiation i= s to determine the set of valid messages. Changes to version negotiation its= elf are very problematic. The only limitation presented by versioning is that the system is sequential= . As such, clients that do not wish to implement (or operators who do not wi= sh to enable) them are faced with a problem when wanting to support later fe= atures. This is resolvable by making such features optional at the new proto= col level. This allows each client to limit its communication to the negotia= ted protocol, and allows ignoring of known but unsupported/disabled features= . Sorry I missed your earlier post. Been distracted for a while. e > On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev wrote: >=20 > =EF=BB=BF > Hi, >=20 > Back in February I posted a proposal for WTXID-based transaction relay[1] (= now known as BIP 339), which included a proposal for feature negotiation to t= ake place prior to the VERACK message being received by each side. In my em= ail to this list, I had asked for feedback as to whether that proposal was p= roblematic, and didn't receive any responses. >=20 > Since then, the implementation of BIP 339 has been merged into Bitcoin Cor= e, though it has not yet been released. >=20 > In thinking about the mechanism used there, I thought it would be helpful t= o codify in a BIP the idea that Bitcoin network clients should ignore unknow= n messages received before a VERACK. A draft of my proposal is available he= re[2]. >=20 > I presume that software upgrading past protocol version 70016 was already p= lanning to either implement BIP 339, or ignore the wtxidrelay message propos= ed in BIP 339 (if not, then this would create network split concerns in the f= uture -- so I hope that someone would speak up if this were a problem). Whe= n we propose future protocol upgrades that would benefit from feature negoti= ation at the time of connection, I think it would be nice to be able to use t= he same method as proposed in BIP 339, without even needing to bump the prot= ocol version. So having an understanding that this is the standard of how o= ther network clients operate would be helpful. >=20 > If, on the other hand, this is problematic for some reason, I look forward= to hearing that as well, so that we can be careful about how we deploy futu= re p2p changes to avoid disruption. >=20 > Thanks, > Suhas Daftuar >=20 > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/= 017648.html >=20 > [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-nego= tiation/bip-p2p-feature-negotiation.mediawiki > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
A require= ment to ignore unknown (invalid) messages is not only a protocol breaking ch= ange but poor protocol design. The purpose of version negotiation is to dete= rmine the set of valid messages. Changes to version negotiation itself are v= ery problematic.

The only l= imitation presented by versioning is that the system is sequential. As such,= clients that do not wish to implement (or operators who do not wish to enab= le) them are faced with a problem when wanting to support later features. Th= is is resolvable by making such features optional at the new protocol level.= This allows each client to limit its communication to the negotiated protoc= ol, and allows ignoring of known but unsupported/disabled features.

Sorry I missed your earlier post. B= een distracted for a while.

e


On Aug 14, 2020, at 12:28, Suhas Daftuar v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

<= /blockquote>
=EF=BB=BF
Hi,

Back in February I posted a proposal for W= TXID-based transaction relay[1] (now known as BIP 339), which included a pro= posal for feature negotiation to take place prior to the VERACK message bein= g received by each side.  In my email to this list, I had asked for fee= dback as to whether that proposal was problematic, and didn't receive any re= sponses.

Since then, the implementation of BIP= 339 has been merged into Bitcoin Core, though it has not yet been released.=

In thinking about the mechanism used there, I thou= ght it would be helpful to codify in a BIP the idea that Bitcoin networ= k clients should ignore unknown messages received before a VERACK.  A d= raft of my proposal is available here[2].

I presume= that software upgrading past protocol version 70016 was already planning to= either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 3= 39 (if not, then this would create network split concerns in the future -- s= o I hope that someone would speak up if this were a problem).  When we p= ropose future protocol upgrades that would benefit from feature negotiation a= t the time of connection, I think it would be nice to be able to use the sam= e method as proposed in BIP 339, without even needing to bump the protocol v= ersion.  So having an understanding that this is the standard of how ot= her network clients operate would be helpful.

If, o= n the other hand, this is problematic for some reason, I look forward to hea= ring that as well, so that we can be careful about how we deploy future p2p c= hanges to avoid disruption.

Thanks,
Suhas= Daftuar

_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /span>
= --Apple-Mail-40DE678E-9C02-47D1-B05C-CB2F19EF6796--