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
|
Return-Path: <dave@dtrt.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8B90EC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2020 14:14:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 7A926876CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2020 14:14:34 +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 O9T9GkYXH4xt
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2020 14:14:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by whitealder.osuosl.org (Postfix) with ESMTPS id 2B92487660
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2020 14:14:32 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1k8lKp-0003KJ-9M; Thu, 20 Aug 2020 10:14:31 -0400
Date: Thu, 20 Aug 2020 10:13:39 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200820141339.gbbr5rewi4yvoarl@ganymede>
References: <CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com>
<C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="br7d5rqh26itcatr"
Content-Disposition: inline
In-Reply-To: <C18E3371-C27A-41CD-B81F-6C96FA210494@voskuil.org>
User-Agent: NeoMutt/20180716
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: Thu, 20 Aug 2020 14:14:34 -0000
--br7d5rqh26itcatr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrot=
e:
> A requirement to ignore unknown (invalid) messages is [...] a protocol
> breaking change=20
I don't think it is. The proposed BIP, as currently written, only tells
nodes to ignore unknown messages during peer negotiation. The only case
where this will happen so far is BIP339, which says:
The wtxidrelay message must be sent in response to a VERSION message
from a peer whose protocol version is >=3D 70016, and prior to sending
a VERACK
So unless you signal support for version >=3D70016, you'll never receive an
unknown message. (And, if you do signal, you probably can't claim that
you were unaware of this new requirement, unless you were using a
non-BIP protocol like xthin[1]).
However, perhaps this new proposed BIP could be a bit clearer about its
expectations for future protocol upgrades by saying something like:
Nodes implementing this BIP MUST also not send new negotiation
message types to nodes whose protocol version is less than 70017.
That should promote backwards compatibility. If you don't want to
ignore unknown negotiation messages between `version` and `verack`, you
can just set your protocol version to a max of 70016.
> A requirement to ignore unknown (invalid) messages is [...] poor
> protocol design. The purpose of version negotiation is to determine
> the set of valid messages.=20
To be clear, the proposed requirement to ignore unknown messages is
limited in scope to the brief negotiation phase between `version` and
`verack`. If you want to terminate connections (or do whatever) on
receipt of an unknown message, you can do that at any other time.
> Changes to version negotiation itself are very problematic.
For whom?
> The only limitation presented by versioning is that the system is
> sequential.=20
That seems like a pretty significant limitation to decentralized
protocol development.
I think there are currently several people who want to run long-term
experiements for new protocol features using open source opt-in
codebases that anyone can run, and it would be advantageous to them to
have a flexible and lightweight feature negotiation system like this
proposed method.
> As such, clients that do not wish to implement (or operators who do
> not wish to enable) them are faced with a problem when wanting to
> support later features. This is resolvable by making such features
> optional at the new protocol level. This allows each client to limit
> its communication to the negotiated protocol, and allows ignoring of
> known but unsupported/disabled features.
I don't understand this. How do two peers negotiate a set of two or
more optional features using only the exchange of single numbers? For
example:
- Node A supports Feature X (implemented in protocol version 70998) and Fea=
ture Y (version 70999).
- Node B does not support X but does want to use Y; what does it use for its
protocol version number when establishing a connection with node A?
---
Overall, I like the proposed BIP and the negotiation method it
describes.
Cheers,
-Dave
[1] This is not a recommendation for xthin, but I do think it's an example
of the challenges of using a shared linear version number scheme for
protocol negotiation in a decentralized system where different teams
don't necessarily get along well with each other.
https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544=
173f03d45373b#diff-c61070c281aed6ded69036c08bd08addR12
--br7d5rqh26itcatr
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl8+hRMACgkQ2dtBqWwi
adMRDBAAm9Dim9S9a75qEoL8dRKDBDO+WMvLP2jqL3VktNjpc6amrftQURKBipiy
0FKNxSG0wKXxg7ZKrxUy8/NpJXqwp7BewG5atX4YwpNLJrhcGSQESIYcTVR5ssNs
tRsVCR0vYW2gsOt9Jc/43FEa5Ed5wxtnhk3uRn/+OyPCqk3zbCaRcXlaMbmrVezY
FHnYEYtRtsiQDkJKdY2liviIAv3R5Kgch3T7CMuSFvWDLRxFyYXTlwI1cNzRmWyR
/u78NwCyR0QhhJYyZmWgYUcODu/4+1bjVzW17CabdGlQ6Z32hfN69OyMHyqisNbv
IqN8fGsc44tr+wz7ZkIWTCshNbfUDd0FGwLYndhQLu4EUszpYHMuXPeVGq7zwpKv
pYH30KlyflFRnkFQtvtK5cxa8n5w+3dapXyK0H7TSDJUe2PU2uIw9qZkBlhBgdei
aWBfIZq4wEyHpAHmv954ZpEPZgRD/xU7FX2dm/ebwOTebIJM4ayVzmbdqa+qiMiQ
PlqiMfA9/rzA3cqarRJCLyJcyvXo4Q4CLfINWyZlw0Wk9liO+49L+cqKEKNwEwIz
iIr4U9UXY88Ttw+jn15eGaU/WJgU4gSwTgTn3vPcZ6UU+JkUjmj8IXZtJiN1zrFu
3wLhw1iMaPc2gmYy3b/KxgGj1on7iitYIZo54GwTemHi4PcrzT8=
=XgyK
-----END PGP SIGNATURE-----
--br7d5rqh26itcatr--
|
