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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
Return-Path: <eric@voskuil.org>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 24FF2C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2020 17:45:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 1C22585A9E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2020 17:45:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 6SkHqr97aJy0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2020 17:45:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com
[209.85.214.178])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 283E1854D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2020 17:45:48 +0000 (UTC)
Received: by mail-pl1-f178.google.com with SMTP id f5so3103116plr.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2020 10:45:48 -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:cc:in-reply-to:to;
bh=YH/ZPQjB3HI5v2fSCv0x09gke8TdcOAtgjOOuI/Bmio=;
b=C3GPDia8W9zXT+przKlD4daNlAf/gSIqpLuZxkIXNleNJ2NkvmJT4pvnR/zKduyJx5
2fXLr9v+vxPfssxH6Z2M9McujHWfQgjasjfZQIf75IUeM+C//UW1v8tI8eJ2wMc2k/Cm
YTfTvf8TaiRWICDsHi2KMsIrLNyw1sF7dj9RqaPPfr4aGq79IwDxBF9ItTZTYfPieDb0
wk4u5NOiEldadWM5kTfM9FXuKypZJjbbETkfqqh+siLbU6c/rnAzlHtTnExmL+m4I4Db
dJWMlgkVPRChDtJlNxzk7NRpgm3AZcGMJrxcwruIYAHwCopRxr/y59crm7Z5J7/sOcEq
Fgew==
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:cc:in-reply-to:to;
bh=YH/ZPQjB3HI5v2fSCv0x09gke8TdcOAtgjOOuI/Bmio=;
b=jfaw42+nq3mRp+JBghCKpXRSPGvGHhEUXEvn3dzaOHsg5jsQPEzK5z6dNwJTeTHCDs
QLRKcnpay0SBjEU3ymOxUFbwU5ORQ0C7QLRe6At+N7XSUnYJwpUsp1Of/wwfrP9mOkQD
cBlec8b69DQURukLaii9iJ4V96ECGpOZNOqk63+v72iWfFsT0yFKpnXuQCRwUtth+mC4
V0yCnRnXwbTrp6Fuo8mJiPe59wze/QGd3KYM1RqO/hb4MpoL1LIpWyiwEYm7vE4BYEAd
zxIIBTIfhToGmHg/h/RjixswaD5NoggrwUersxnhRBvdjVZixyZpTDtKojpG2nh3FWBZ
JF4g==
X-Gm-Message-State: AOAM532Ju6gNI0C0E20stnr0rDn1DNUOGZ1YVt3l5obbbCgx69CBML5Q
UKnQrKX8usw/SUVmZ1oPhdmsOA==
X-Google-Smtp-Source: ABdhPJxYr64tSlxq4bo0ijechadQUWGWeLWGU30ILHJH0QLK5iTJ0TH81FZTOiBOiTTEpwtFNw3cgg==
X-Received: by 2002:a17:90b:3284:: with SMTP id
ks4mr1562474pjb.116.1598204747536;
Sun, 23 Aug 2020 10:45:47 -0700 (PDT)
Received: from ?IPv6:2600:380:7045:ddda:2dc5:cf82:3470:54a0?
([2600:380:7045:ddda:2dc5:cf82:3470:54a0])
by smtp.gmail.com with ESMTPSA id n18sm7485702pgd.91.2020.08.23.10.45.46
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 23 Aug 2020 10:45:46 -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: Sun, 23 Aug 2020 10:45:45 -0700
Message-Id: <1DE500EE-BDC7-4B36-AB12-45885D20C226@voskuil.org>
References: <b6198e1a-c30b-358a-9673-247a7c305913@mattcorallo.com>
In-Reply-To: <b6198e1a-c30b-358a-9673-247a7c305913@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: iPhone Mail (17G80)
X-Mailman-Approved-At: Sun, 23 Aug 2020 17:51:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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, 23 Aug 2020 17:45:50 -0000
> On Aug 21, 2020, at 13:45, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>=20
> =EF=BB=BFThis seems to be pretty overengineered.
I agree. In fact all proposals I=E2=80=99ve seen on this are over engineered=
.
> Do you have a specific use-case in mind for anything more than simply cont=
inuing the pattern we've been using of sending a message indicating support f=
or a given feature?
Correct me if I=E2=80=99m wrong, but this pattern is what the proposal aims t=
o eliminate. There is no reason whatsoever for a message per indication. The=
appropriate pattern is already established in the implementation of service=
bits. In fact in this discussion it has been pointed out that the problem w=
ith service bits is simply too few bits.
> If we find some in the future,
> we could deploy something like this, though the current proposal makes it p=
ossible to do it on a per-feature case.
As does any other proposal, including passage of the full set of optional su=
b-protocols in the verack.
> The great thing about Suhas' proposal is the diff is about -1/+1 (not incl=
uding tests), while still getting all the flexibility we need.
> Even better, the code already exists.
This is neither true nor relevant. Maybe the Segwit 2X guys should have used=
this argument.
e
> Matt
>=20
>> On 8/21/20 3:50 PM, Jeremy wrote:
>> I have a proposal:
>> Protocol >=3D 70016 cease to send or process VERACK, and instead use HAND=
SHAKEACK, which is completed after feature negotiation.
>> This should make everyone happy/unhappy, as in a new protocol number it's=
fair game to change these semantics to be clear that we're acking more than=
version.
>> I don't care about when or where these messages are sequenced overall, it=
seems to have minimal impact. If I had free choice, I slightly agree with E=
ric that verack should come before feature negotiation, as we want to divorc=
e the idea that protocol number and feature support are tied.
>> But once this is done, we can supplant Verack with HANDSHAKENACK or HANDS=
HAKEACK to signal success or failure to agree on a connection. A NACK reason=
(version too high/low or an important feature missing) could be optional. I=
mplicit NACK would be disconnecting, but is discouraged because a peer doesn=
't know if it should reconnect or the failure was intentional.
>> ------
>> AJ: I think I generally do prefer to have a FEATURE wrapper as you sugges=
ted, or a rule that all messages in this period are interpreted as features (=
and may be redundant with p2p message types -- so you can literally just use=
the p2p message name w/o any data).
>> I think we would want a semantic (which could be based just on message na=
mes, but first-class support would be nice) for ACKing that a feature is ena=
bled. This is because a transcript of:
>> NODE0:
>> FEATURE A
>> FEATURE B
>> VERACK
>> NODE1:
>> FEATURE A
>> VERACK
>> It remains unclear if Node 1 ignored B because it's an unknown feature, o=
r because it is disabled. A transcript like:
>> NODE0:
>> FEATURE A
>> FEATURE B
>> FEATURE C
>> ACK A
>> VERACK
>> NODE1:
>> FEATURE A
>> ACK A
>> NACK B
>> VERACK
>> would make it clear that A and B are known, B is disabled, and C is unkno=
wn. C has 0 support, B Node 0 should support inbound messages but knows not t=
o send to Node 1, and A has full bilateral support. Maybe instead it could a=
message FEATURE SEND A and FEATURE RECV A, so we can make the split explici=
t rather than inferred from ACK/NACK.
>> ------
>> I'd also propose that we add a message which is SYNC, which indicates the=
end of a list of FEATURES and a request to send ACKS or NACKS back (which a=
re followed by a SYNC). This allows multi-round negotiation where based on t=
he presence of other features, I may expand the set of features I am offerin=
g. I think you could do without SYNC, but there are more edge cases and the e=
xplicitness is nice given that this already introduces future complexity.
>> This multi-round makes it an actual negotiation rather than a pure announ=
cement system. I don't think it would be used much in the near term, but it m=
akes sense to define it correctly now. Build for the future and all...
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/Jeremy=
Rubin>
|
