Date: Fri, 21 Aug 2020 12:36:47 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Suhas Daftuar <sdaftuar@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200821023647.7eat4goqqrtaqnna@erisian.com.au>
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
 connections are setup
Precedence: list

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