From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1B551C0051 for ; Fri, 21 Aug 2020 02:36:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 1042D886A3 for ; Fri, 21 Aug 2020 02:36:59 +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 agcj6bbSVXX3 for ; Fri, 21 Aug 2020 02:36:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by whitealder.osuosl.org (Postfix) with ESMTPS id 2876C886A0 for ; Fri, 21 Aug 2020 02:36:57 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1k8wvE-0005cX-Fv; Fri, 21 Aug 2020 12:36:54 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 21 Aug 2020 12:36:47 +1000 Date: Fri, 21 Aug 2020 12:36:47 +1000 From: Anthony Towns To: Suhas Daftuar , Bitcoin Protocol Discussion Message-ID: <20200821023647.7eat4goqqrtaqnna@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - 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: Fri, 21 Aug 2020 02:36:59 -0000 On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev wrote: > In thinking about the mechanism used there, I thought it would be helpful to > codify in a BIP the idea that Bitcoin network clients should ignore unknown > messages received before a VERACK.  A draft of my proposal is available here > [2]. Rather than allowing arbitrary messages, maybe it would make sense to have a specific feature negotiation message, eg: VERSION ... FEATURE wtxidrelay FEATURE packagerelay VERACK with the behaviour being that it's valid only between VERSION and VERACK, and it takes a length-prefixed-string giving the feature name, optional additional data, and if the feature name isn't recognised the message is ignored. If we were to support a "polite disconnect" feature like Jeremy suggested, it might be easier to do that for a generic FEATURE message, than reimplement it for the message proposed by each new feature. Cheers, aj