From: Eric Voskuil <eric@voskuil•org>
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
Date: Fri, 21 Aug 2020 09:42:46 -0700 [thread overview]
Message-ID: <B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org> (raw)
In-Reply-To: <A26FA2BC-50E5-4635-95E4-56AAA969C9DA@mattcorallo.com>
I’m pretty sure one can run whatever they want even without a BIP. There is nobody here to do any “allowing”. On the other hand, standards development is tedious for good reason.
Generally speaking, overloading is a primary source of complexity (creating more branches in code and human explanation). Nevertheless this is verack payload, 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:
>
> Sure, we could do a new message for negotiation, but there doesn’t seem to be a lot of reason for it - using the same namespace for negotiation seems fine too. In any case, this is one of those things that doesn’t matter in the slightest, and if one person volunteers to write a BIP and code, no reason they shouldn’t just decide and be allowed to run with it. Rough consensus and running code, as it were :)
>
> Matt
>
>
>>> On Aug 20, 2020, at 22:37, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> 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
>>
>> _______________________________________________
>> 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
next prev parent reply other threads:[~2020-08-21 17:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 19:28 Suhas Daftuar
2020-08-16 17:24 ` Jeremy
2020-08-16 19:06 ` Eric Voskuil
2020-08-17 20:40 ` Suhas Daftuar
2020-08-17 21:21 ` Eric Voskuil
2020-08-20 14:13 ` David A. Harding
2020-08-18 14:59 ` Matt Corallo
2020-08-18 16:54 ` Eric Voskuil
2020-08-18 17:26 ` Matt Corallo
2020-08-18 18:11 ` Eric Voskuil
2020-08-18 18:25 ` Matt Corallo
2020-08-18 18:56 ` Eric Voskuil
2020-08-21 2:36 ` Anthony Towns
2020-08-21 4:25 ` Eric Voskuil
2020-08-21 14:15 ` lf-lists
2020-08-21 16:42 ` Eric Voskuil [this message]
2020-08-21 19:50 ` Jeremy
2020-08-21 20:45 ` Matt Corallo
2020-08-21 21:08 ` Jeremy
2020-08-21 21:17 ` Jeremy
2020-08-21 22:16 ` Matt Corallo
2020-08-23 17:49 ` Eric Voskuil
2020-08-24 9:44 ` Suhas Daftuar
2020-08-24 13:59 ` G. Andrew Stone
2020-08-24 19:58 ` Jeremy
2020-08-24 20:17 ` Eric Voskuil
2020-08-24 20:21 ` Jeremy
2020-08-24 20:33 ` Eric Voskuil
2020-08-21 21:17 ` Eric Voskuil
2020-08-23 17:45 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox