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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0D218C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 20:45:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id EF9518885F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 20:45:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id eFJ4f1IcmdiX
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 20:45:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by hemlock.osuosl.org (Postfix) with ESMTPS id 2F50A8885B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 20:45:31 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id E59E32F1596;
Fri, 21 Aug 2020 20:45:27 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1598041263; t=1598042728;
bh=l+6wjYx6siilo2HPKicYo63ec4LVyYnesackX3fMQ20=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=E4mOKp5JKLttAITVpy3xb/927IsMOZJGouc9HWPBYBH1vZCEdS6AE5bb/sed8kS0A
DwgQt+jaJcJ7S6z1TX40Fhfm9J1fQ4uWvL7YTl7AWz1yeRu5H9dnIWkQWqRlUMoH8t
BHL7aI4r+904D2XdLN2CX2rsFRAS8mYdKBQR6IlwpwkM4FaBB2KXVQO2jezMvTO2ZZ
9qUnQZPfnBkmne4fRVyHLgme5HQQYDcLbxjemJHg9SjB7yQn+5kIyEcs8HIKTgHcn0
DyWrTDnK7ML2ESZa/lXFj06kGqBfOlcWsdX4GBB7dN2T+uP13JnakttwThJRyLLBMm
5OMMmj3VTDJ1A==
To: Jeremy <jlrubin@mit.edu>, Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <A26FA2BC-50E5-4635-95E4-56AAA969C9DA@mattcorallo.com>
<B514142F-382B-4D49-B68D-0115ECBD1D79@voskuil.org>
<CAD5xwhi9zVp3nOhFy3Hia_Md++Gdz+F5Kat_bbbZwBcmPhMGZA@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <b6198e1a-c30b-358a-9673-247a7c305913@mattcorallo.com>
Date: Fri, 21 Aug 2020 16:45:26 -0400
MIME-Version: 1.0
In-Reply-To: <CAD5xwhi9zVp3nOhFy3Hia_Md++Gdz+F5Kat_bbbZwBcmPhMGZA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 20:45:32 -0000
This seems to be pretty overengineered. Do you have a specific use-case in mind for anything more than simply continuing
the pattern we've been using of sending a message indicating support for a given feature? If we find some in the future,
we could deploy something like this, though the current proposal makes it possible to do it on a per-feature case.
The great thing about Suhas' proposal is the diff is about -1/+1 (not including tests), while still getting all the
flexibility we need. Even better, the code already exists.
Matt
On 8/21/20 3:50 PM, Jeremy wrote:
> I have a proposal:
>
> Protocol >= 70016 cease to send or process VERACK, and instead use HANDSHAKEACK, 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 Eric that verack should come before feature negotiation, as we want to divorce the idea
> that protocol number and feature support are tied.
>
> But once this is done, we can supplant Verack with HANDSHAKENACK or HANDSHAKEACK 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. Implicit 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 suggested, 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 names, but first-class support would be nice) for
> ACKing that a feature is enabled. 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, or 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 unknown. C has 0 support, B Node 0 should support
> inbound messages but knows not to 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 explicit 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 are followed by a SYNC). This allows multi-round negotiation where based on the presence
> of other features, I may expand the set of features I am offering. I think you could do without SYNC, but there are more
> edge cases and the explicitness is nice given that this already introduces future complexity.
>
> This multi-round makes it an actual negotiation rather than a pure announcement system. I don't think it would be used
> much in the near term, but it makes sense to define it correctly now. Build for the future and all...
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
|
