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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Return-Path: <jlrubin@mit.edu>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 741CEC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 17:24:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 633A2876CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 17:24:24 +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 1VaoSvfzlVob
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 17:24:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by whitealder.osuosl.org (Postfix) with ESMTPS id 7EAF3876A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 17:24:23 +0000 (UTC)
Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com
[209.85.208.49]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07GHOLeM032234
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 16 Aug 2020 13:24:22 -0400
Received: by mail-ed1-f49.google.com with SMTP id v22so10521524edy.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 10:24:21 -0700 (PDT)
X-Gm-Message-State: AOAM531izp4NTemt6tcDVJqF+zVHdgg6F75vwLt+PsBUl7dCAqyNYdHf
zByT9gTzm5Q9rD0wiS9arPOJEy1PDWy2vTvpAlw=
X-Google-Smtp-Source: ABdhPJxroqlrJi14rhVQus7q3oVWOtaC/h2y0VOAvbGKb31TGtadHcV5Lb5o7vWDkZaJoJrZmeF3QY43U8rjDvF/eaI=
X-Received: by 2002:a05:6402:1a23:: with SMTP id
be3mr11926209edb.138.1597598660811;
Sun, 16 Aug 2020 10:24:20 -0700 (PDT)
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
X-Gmail-Original-Message-ID: <CAD5xwhg-k1+0R8g4kn4fjvdqmsh0rS_44r4JOPFOCWDGqNLUFA@mail.gmail.com>
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
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: Sun, 16 Aug 2020 17:24:24 -0000
--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 "polite disconnect", whereby a node can regis=
ter that you don'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't end up with different negotiation systems. Then we can also lim=
it the bip so that we'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--
|
