From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 90BA5C0051 for ; Fri, 21 Aug 2020 14:15:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 74BB786BA5 for ; Fri, 21 Aug 2020 14:15:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTEIt79y1AkS for ; Fri, 21 Aug 2020 14:15:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by fraxinus.osuosl.org (Postfix) with ESMTPS id C2E9E86B81 for ; Fri, 21 Aug 2020 14:15:13 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 4FD312F09CA; Fri, 21 Aug 2020 14:15:11 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1598017264; t=1598019311; bh=D/kFa2yIIiEyqS2x9VoPc4mIhLFs0OCIR4qp0lql/sQ=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=YZeoJI3jTwlFB5DBfHxNcTAF1ho2Z6L0XBdgdmNMactlPxBXtEfZcJGsKtPeGVmIC CS+sdTMWvnD+GkCuwCZzdSDoYq68X/7tkOp6B3Ojz7Y48xQbpWh5TeYpNOhvdQua9m ztwZRj5jo8HGjM4rW4ToPP+ELtQJoaZOJdALsQGUMoITMlzppbyEteQ2fpk7XE7I1H 6bO6tA0l1Kz11XI8tEAFlTep7Gr5B3t3cN6cZdqTc8FmtuDZvO2t3PEZJhhA0NUkU6 TOWW6jgz3hno9mssTcaMMtTGU39MQ9yugBvevw/hJcKjjgnFpfN9Pksfwe0NlkFELo ruFjVW5mSoBRA== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: lf-lists@mattcorallo.com Mime-Version: 1.0 (1.0) Date: Fri, 21 Aug 2020 10:15:10 -0400 Message-Id: References: <20200821023647.7eat4goqqrtaqnna@erisian.com.au> In-Reply-To: <20200821023647.7eat4goqqrtaqnna@erisian.com.au> To: Anthony Towns , Bitcoin Protocol Discussion 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 14:15:14 -0000 Sure, we could do a new message for negotiation, but there doesn=E2=80=99t s= eem to be a lot of reason for it - using the same namespace for negotiation s= eems fine too. In any case, this is one of those things that doesn=E2=80=99t= matter in the slightest, and if one person volunteers to write a BIP and co= de, no reason they shouldn=E2=80=99t just decide and be allowed to run with i= t. Rough consensus and running code, as it were :) Matt > On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev wrote: >=20 > =EF=BB=BFOn Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitco= in-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 unkno= wn >> messages received before a VERACK. A draft of my proposal is available h= ere >> [2]. >=20 > Rather than allowing arbitrary messages, maybe it would make sense to > have a specific feature negotiation message, eg: >=20 > VERSION ... > FEATURE wtxidrelay > FEATURE packagerelay > VERACK >=20 > 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. >=20 > 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. >=20 > Cheers, > aj >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev