MIME-Version: 1.0
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
In-Reply-To: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 16 Aug 2020 10:24:09 -0700
Message-ID: <CAD5xwhg-k1+0R8g4kn4fjvdqmsh0rS_44r4JOPFOCWDGqNLUFA@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000abe59b05ad01ec4d"
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
 connections are setup
Precedence: list

--000000000000abe59b05ad01ec4d
Content-Type: text/plain; charset="UTF-8"

Concept ack!

It might be nice to include a few negotiation utility functions either in
this bip or at the same time in a separate bip. An example we might want to
include is a "polite disconnect", whereby a node can register that you
don't want to connect in the future due to incompatibility.

It also might be nice to standardize some naming convention or negotiation
message type so that we don't end up with different negotiation systems.
Then we can also limit the bip so that we're only defining negotiation
message types as ignorable v.s. some other message type (which can also be
ignored, but maybe we want to do something else in the future).

This also makes it easier for old (but newer than this bip) nodes to apply
some generic rules around reporting/rejecting/responding to unknown feature
negotiation v.s. an untagged message which might be a negotiation or
something else.

--000000000000abe59b05ad01ec4d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Concept ack!=C2=A0<div dir=3D"auto"><br></div><div dir=3D=
"auto">It might be nice to include a few negotiation utility functions eith=
er in this bip or at the same time in a separate bip. An example we might w=
ant to include is a &quot;polite disconnect&quot;, whereby a node can regis=
ter that you don&#39;t want to connect in the future due to incompatibility=
.</div><div dir=3D"auto"><br></div><div dir=3D"auto">It also might be nice =
to standardize some naming convention or negotiation message type so that w=
e don&#39;t end up with different negotiation systems. Then we can also lim=
it the bip so that we&#39;re only defining negotiation message types as ign=
orable v.s. some other message type (which can also be ignored, but maybe w=
e want to do something else in the future).</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">This also makes it easier for old (but newer than this =
bip) nodes to apply some generic rules around reporting/rejecting/respondin=
g to unknown feature negotiation v.s. an untagged message which might be a =
negotiation or something else.=C2=A0</div></div>

--000000000000abe59b05ad01ec4d--