Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 21 Aug 2020 09:42:46 -0700
Message-Id: <B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org>
References: <A26FA2BC-50E5-4635-95E4-56AAA969C9DA@mattcorallo.com>
In-Reply-To: <A26FA2BC-50E5-4635-95E4-56AAA969C9DA@mattcorallo.com>
To: lf-lists@mattcorallo.com,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p
	connections are setup
Precedence: list

I=E2=80=99m pretty sure one can run whatever they want even without a BIP. T=
here is nobody here to do any =E2=80=9Callowing=E2=80=9D. On the other hand,=
 standards development is tedious for good reason.

Generally speaking, overloading is a primary source of complexity (creating m=
ore branches in code and human explanation). Nevertheless this is verack pay=
load, no additional messages are necessary or helpful.

e

> On Aug 21, 2020, at 07:15, Matt Corallo via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>=20
> =EF=BB=BFSure, we could do a new message for negotiation, but there doesn=E2=
=80=99t seem to be a lot of reason for it - using the same namespace for neg=
otiation seems 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 B=
IP and code, no reason they shouldn=E2=80=99t just decide and be allowed to r=
un with it. Rough consensus and running code, as it were :)
>=20
> Matt
>=20
>=20
>>> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>>>=20
>>> =EF=BB=BFOn Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bit=
coin-dev wrote:
>>> In thinking about the mechanism used there, I thought it would be helpfu=
l to
>>> codify in a BIP the idea that Bitcoin network clients should ignore unkn=
own
>>> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev