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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
Return-Path: <eric@voskuil.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8D0D0C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 17:07:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 797868831A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 17:07:54 +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 B1WGh4pBQApt
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 17:07:53 +0000 (UTC)
X-Greylist: delayed 00:16:57 by SQLgrey-1.7.6
Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com
[209.85.215.177])
by whitealder.osuosl.org (Postfix) with ESMTPS id BEC268830D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 17:07:53 +0000 (UTC)
Received: by mail-pg1-f177.google.com with SMTP id v15so1289438pgh.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 10:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=content-transfer-encoding:from:mime-version:subject:date:message-id
:references:in-reply-to:to;
bh=yQW5w2OgMMMc2/AKyoIXTOxtnfLwb/qT6MZsI1XJp0E=;
b=hL4LlGaD/dEhrKYqIUFijEZ5fYYyO9XFpo+8FjQSR21GAhMQJUVZ67PVqDEGEWj/yG
BZH8gpBIiLUc3BBNfxxg2W/9W6iaSzmHFsCPtUIBXqg8obnyjx5DzICovH/58bYWlyYc
Do86GMWE7Bv99qQ4PZ8qIbcKdWrjjgNSq2lwq6BGOaOS78kifFiIsGCLzWSRd6cPzBxe
QQnHeOaa+ZlMcABl9tprKnAma5R4AOKgdA6MKhNWqUYryFd4Dz2mXL8tG3NxAv9UCtH0
JqDeMmH9Sc9GgjUmYaHzBtoOLzBhvbvFgK7rUlZOMYy5yRWS1OICrq8Wz1wDDtKmWK8/
9bBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:date:message-id:references:in-reply-to:to;
bh=yQW5w2OgMMMc2/AKyoIXTOxtnfLwb/qT6MZsI1XJp0E=;
b=G63y9VfJ0Fi5YAI/uGRZrkV3PYnVuNhZ0F7E7dJWjI3/o3SiyWw9Jug63qQHBmzc/M
rhxNMGEg60+a1nzo94SmPim3xtft+L7i4FQZeocTBiT7OtTYK7Jr06qe9hYCamssLPv7
EeMm3VUysMk9D/K2zdLsooyhlwBHUrS6zTMn//HdtJkpLlLUz8kWE+6VN1FcciRonwaq
a0VmVibgrPdUB2xoySA5VnOGQPkTpweSG/sUO+5LTyOy9Df0nkiKSCA28LMLtWtJMYuE
qmuXuh5Er2r7jQCr8bTroPRXK/Nt2/6DtUeqcIijpDTl+xZ0d++kg0ntXbsp+EJ7iO6l
zD/Q==
X-Gm-Message-State: AOAM530KjspP7tJ6brKh6rQK8HQfHUm4Z4tjU8riZohWEb9ikPh+wLq3
b30wJyyJ3YJINHjHhycZrbH+Qn/lCimSF3Ug
X-Google-Smtp-Source: ABdhPJwf6Agj2UjeCCOMDjHcy8LHIsh99pw2xLbXrPaUI2pUy7L1gF4NRNdlcX4VsoNKoCEVsfWBaA==
X-Received: by 2002:a63:741b:: with SMTP id p27mr2800814pgc.194.1598028168221;
Fri, 21 Aug 2020 09:42:48 -0700 (PDT)
Received: from ?IPv6:2601:602:9a00:370e:f4ae:5f8d:2cd4:9084?
([2601:602:9a00:370e:f4ae:5f8d:2cd4:9084])
by smtp.gmail.com with ESMTPSA id v128sm3036922pfc.14.2020.08.21.09.42.47
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 21 Aug 2020 09:42:47 -0700 (PDT)
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>
X-Mailer: iPhone Mail (17G68)
X-Mailman-Approved-At: Fri, 21 Aug 2020 17:18:05 +0000
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 17:07:54 -0000
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
|
