1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
Return-Path: <aj@erisian.com.au>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1B551C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 02:36:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 1042D886A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 02:36:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id agcj6bbSVXX3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 02:36:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by whitealder.osuosl.org (Postfix) with ESMTPS id 2876C886A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 02:36:57 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1k8wvE-0005cX-Fv; Fri, 21 Aug 2020 12:36:54 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 21 Aug 2020 12:36:47 +1000
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)
X-Spam-Score-int: -18
X-Spam-Bar: -
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2020 02:36:59 -0000
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
|
