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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
|
Return-Path: <naumenko.gs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D2241D12
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Oct 2019 21:52:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com
[209.85.222.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB84A8A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Oct 2019 21:52:57 +0000 (UTC)
Received: by mail-qk1-f174.google.com with SMTP id p10so21354828qkg.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Oct 2019 14:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=date:from:to:message-id:in-reply-to:references:subject:mime-version;
bh=uRu9SzeupuCFUAb6OBSVtGlTGJuHQFy40Aspl0SNsoY=;
b=hRi9CtGn5xlEzKd5QNOQRC8rtn5j8fGd2nqO2HBmze6Z1MmcAG0be+deGWL3XL1O5X
VsSaxlI2J7VOZC2eLomm6W3nW0pAHmReQk1KsLwPqcggzTU0YT7GQFRumkzzDrJ0EURc
EmTXEoCjOl0c/MXeqgE51Q3Kd09Q3vnMP3knJyTXMFV939mOteG0VR8z5D3KmyqgcBaM
h/Y2qez7U8SMq7pVlJTsLWLZzZhMLaJvDvI0H2gXb4qh2MVQdhjWlq87/9J08cQ+gC5f
KmUjn+acRp148hlqaSO4/6DT0IrJyBID+w4beHFV+fgeda/oUxmXWGh0eu9hMZW2JpwM
1a0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:message-id:in-reply-to:references
:subject:mime-version;
bh=uRu9SzeupuCFUAb6OBSVtGlTGJuHQFy40Aspl0SNsoY=;
b=jECmYwCx7A7ac+QNIt5xxDEDglIUnvrcinokd5qLz509CA9Boj5F4OYIDbV+MXsM2R
7w2LWhbaWi9R+98UDLKhXw7n9jjHSK/poLko/ysn1+y7STaxCMLUkckZ9j0cnPRmQIA/
5SF99yGEu8AYBgwkWgM84wWOqt+Hsw9tQByCPWsO/Pu6VtNKcNngmvTBEGl9XM7R/dbd
sMZ9/0ktEaunZq5SHvGcPZiIsI4p1UQzJjBmbKivOxIZqHfIOO60BTm5YZWH4eq8y1z2
6UVJ6zXrtfQ1Ii8LL0coL0oMLQwccm094W3gztosh43OtNQBF2T2x/Bi7KQmEmKMdPGK
9/sA==
X-Gm-Message-State: APjAAAXGBCXYvtcfMZ5j8xDUHyFqSlrZvosrOLf2k0dI3tVsVRNGw1zc
DGBQ7imxb/7mDU5MdSdg+t45a3vJQiYcsw==
X-Google-Smtp-Source: APXvYqxy6NlZe5IVo//jRSP7AnZVmlTpLLG1PKk8IXpaRwbrJuTTeT18kG45eT/nAMq6XNo80gEaBQ==
X-Received: by 2002:a37:8dc2:: with SMTP id p185mr11173819qkd.7.1571867576185;
Wed, 23 Oct 2019 14:52:56 -0700 (PDT)
Received: from [10.93.141.158] ([4.53.92.114])
by smtp.gmail.com with ESMTPSA id
a15sm3217342qtp.77.2019.10.23.14.52.55
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 23 Oct 2019 14:52:55 -0700 (PDT)
Date: Wed, 23 Oct 2019 17:52:49 -0400
From: Gleb Naumenko <naumenko.gs@gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <485c6620-4927-4f44-b060-a3be1c31f135@Spark>
In-Reply-To: <fd174eb5-3699-4eed-b11e-e0370da63598@Spark>
References: <fd174eb5-3699-4eed-b11e-e0370da63598@Spark>
X-Readdle-Message-ID: 485c6620-4927-4f44-b060-a3be1c31f135@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5db0cbb6_74de0ee3_4fe"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 23 Oct 2019 21:54:46 +0000
Subject: [bitcoin-dev] Signaling support for addr relay (revision #1)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 23 Oct 2019 21:52:58 -0000
--5db0cbb6_74de0ee3_4fe
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi,
=23=23=23 Introduction
I was recently looking into AddrMan and I realized that unlike with block=
s (BIP152) and transactions (a node can opt-out via various mechanisms su=
ch as blocks-only or block-only-relay), address relay is under-specified.=
=46or example, we had a discussion =5B1=5D on whether SPV nodes store/rel=
ay IP addresses. While it seems they don=E2=80=99t do it currently in pra=
ctice, in some cases they should if they want to be secure and reliable.
=23=23=23 Motivation
This change would decouple addr relay considerations from light/full node=
/block-relay-only.
This would also allow us to easier analyze (in a scientific sense, not in=
a spying sense) and adjust address relay, which currently seems to have =
understudied properties and guarantees.
In practice, this may allow more efficient address relay (fewer messages =
and less time to relay a new address across all nodes) both immediately a=
nd potentially long-term.
=23=23=23 Solution
I want to suggest making explicit whether a node promises to participate =
in address relay by a) forwarding unsolicited messages (I work on a somew=
hat related issue in this PR =5B2=5D) , and, b) responding to GETADDR.
In my opinion, these 2 signals (a and b) should be viewed independently.
Obviously, these signals should not be relied upon and future protocol ch=
anges should assume they may represent lies.
However, explicitly opting-out of relay addresses will help to improve no=
n-adversarial address relay.
=23=23=23 Implementation
I see 2 ways to implement this:
- 2 new service bits
- per-link-direction negotiation: e.g., use BIP-155 (a new message sendad=
drv2 is discussed here =5B3=5D and can be used to signal this)
Both of them can allow decoupling addr relay from node type, but they do =
have different trade-offs.
=23=23=23=23 Service bits
Having service bits makes sense only if nodes are going to make peering d=
ecisions based on it. (everything else might be achieved without introduc=
ing a service bit). It is not clear to me whether this makes sense in thi=
s context.
The fundamental problem with service bits is that they make a uniform =E2=
=80=9Cpromise=E2=80=9D for all connections to a given node. E.g., if node=
X announces NODE=5FADDR=5F=46ORWARD, all nodes in the network expect nod=
e X to forward addresses. (If the =E2=80=9Cpromise=E2=80=9D is not strong=
, then additional negotiation is required anyway, so service bits do not =
solve the problem).
It=E2=80=99s worth keeping in mind that all of the honest reachable full =
nodes nodes DO relay addresses, and we already won=E2=80=99t connect to t=
hose nodes which don=E2=80=99t (light clients). Service bits won=E2=80=99=
t help here because the problem of connecting to non-addr-relaying full n=
odes does not exist.
Maybe, if we think that a large fraction of reachable nodes might start c=
ompletely disabling addr relay to all in the future, then it makes sense =
to have this service bit, to prevent nodes from accidentally connecting t=
o these peers only and not learning addrs.
Intuitively, it=E2=80=99s also easier to shoot in the leg with the deploy=
ment of service bits (might make it easier for attacker to accumulate con=
nections comparing to the case of victims choosing their peers uniformly =
at random without considering new service bit).
=23=23=23=23 Per-link-direction negotiation
This approach does not have the shortcomings mentioned above.
In addition, I think that having more flexibility (Per-link-direction neg=
otiation) is better for the future of the protocol, where some nodes migh=
t want to opt-out of addr relay for a subset of their links.
(A node might want to opt-out from addr relay for particular links due to=
privacy reasons because addr-relay currently leaks information and maybe=
we shouldn=E2=80=99t relay transactions through the same links).
And I think this future is much more likely to happen than a future where=
a significant fraction of reachable nodes disable addr relay to *everyon=
e* and need to announce this to the network. Also, even if needed, this c=
an be done with per-link-direction negotiation too, and handled by the pe=
ers accordingly.
Per-link-direction negotiation also allows to decouple the behaviour from=
inbound/outbound type of connection (currently we do not respond to GETA=
DDR from outbound). This logic seems not fundamental to me, but rather a =
temporary heuristic to prevent attacks, which might be changed in future.=
=23=23=23 Conclusion
I think the solution fundamentally depends on the answer to:
=E2=80=9CDo we believe that some of the future security advices for node =
operators would be to disable address relay to all (or most) of the links=
=E2=80=9D.
If yes, I think we should use service bits.
If no, I think we should use per-link-direction negotiation.
If the answer will change, we can also add a service bit later.
Anyway, according to the current considerations I explained in this email=
, I=E2=80=99d suggest extending BIP-155 with per-link-direction negotiati=
on, but I=E2=80=99m interested in the opinion of the community.
=23=23=23 References
1. Bitcoin core dev IRC meeting (http://www.erisian.com.au/bitcoin-core-d=
ev/log-2019-10-17.html)
2. p2p: Avoid forwarding ADDR messages to SPV nodes (https://github.com/b=
itcoin/bitcoin/pull/17194)
3. BIP 155: addrv2 BIP proposal (https://github.com/bitcoin/bips/pull/766=
)
=E2=80=93 gleb
--5db0cbb6_74de0ee3_4fe
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>
<div dir=3D=22auto=22>Hi,<br />
<br />
=23=23=23 Introduction<br />
<br />
I was recently looking into AddrMan and I realized that unlike with block=
s (BIP152) and transactions (a node can opt-out via various mechanisms su=
ch as blocks-only or block-only-relay), address relay is under-specified.=
<br />
<br />
=46or example, we had a discussion =5B1=5D on whether SPV nodes store/rel=
ay IP addresses. While it seems they don=E2=80=99t do it currently in pra=
ctice, in some cases they should if they want to be secure and reliable.<=
br />
<br />
=23=23=23 Motivation<br />
<br />
This change would decouple addr relay considerations from light/full node=
/block-relay-only.<br />
This would also allow us to easier analyze (in a scientific sense, not in=
a spying sense) and adjust address relay, which currently seems to have =
understudied properties and guarantees.<br />
In practice, this may allow more efficient address relay (fewer messages =
and less time to relay a new address across all nodes) both immediately a=
nd potentially long-term.<br />
<br />
=23=23=23 Solution<br />
<br />
I want to suggest making explicit whether a node promises to participate =
in address relay by a) forwarding unsolicited messages (I work on a somew=
hat related issue in this PR =5B2=5D) , and, b) responding to GETADDR.<br=
/>
<br />
In my opinion, these 2 signals (a and b) should be viewed independently.<=
br />
<br />
Obviously, these signals should not be relied upon and future protocol ch=
anges should assume they may represent lies.<br />
However, explicitly opting-out of relay addresses will help to improve no=
n-adversarial address relay.<br />
<br />
=23=23=23 Implementation<br />
<br />
I see 2 ways to implement this:<br />
- 2 new service bits<br />
- per-link-direction negotiation: e.g., use BIP-155 (a new message sendad=
drv2 is discussed here =5B3=5D and can be used to signal this)<br />
<br />
Both of them can allow decoupling addr relay from node type, but they do =
have different trade-offs.<br />
<br />
=23=23=23=23 Service bits<br />
<br />
Having service bits makes sense only if nodes are going to make peering d=
ecisions based on it. (everything else might be achieved without introduc=
ing a service bit). It is not clear to me whether this makes sense in thi=
s context.<br />
<br />
The fundamental problem with service bits is that they make a uniform =E2=
=80=9Cpromise=E2=80=9D for all connections to a given node. E.g., if node=
X announces NODE=5FADDR=5F=46ORWARD, all nodes in the network expect nod=
e X to forward addresses. (If the =E2=80=9Cpromise=E2=80=9D is not strong=
, then additional negotiation is required anyway, so service bits do not =
solve the problem).<br />
<br />
It=E2=80=99s worth keeping in mind that all of the honest reachable full =
nodes nodes DO relay addresses, and we already won=E2=80=99t connect to t=
hose nodes which don=E2=80=99t (light clients). Service bits won=E2=80=99=
t help here because the problem of connecting to non-addr-relaying full n=
odes does not exist.<br />
Maybe, if we think that a large fraction of reachable nodes might start c=
ompletely disabling addr relay to all in the future, then it makes sense =
to have this service bit, to prevent nodes from accidentally connecting t=
o these peers only and not learning addrs.<br />
<br />
Intuitively, it=E2=80=99s also easier to shoot in the leg with the deploy=
ment of service bits (might make it easier for attacker to accumulate con=
nections comparing to the case of victims choosing their peers uniformly =
at random without considering new service bit).<br />
<br />
=23=23=23=23 Per-link-direction negotiation<br />
<br />
This approach does not have the shortcomings mentioned above.<br />
<br />
In addition, I think that having more flexibility (Per-link-direction neg=
otiation) is better for the future of the protocol, where some nodes migh=
t want to opt-out of addr relay for a subset of their links.<br />
(A node might want to opt-out from addr relay for particular links due to=
privacy reasons because addr-relay currently leaks information and maybe=
we shouldn=E2=80=99t relay transactions through the same links).<br />
<br />
And I think this future is much more likely to happen than a future where=
a significant fraction of reachable nodes disable addr relay to *everyon=
e* and need to announce this to the network. Also, even if needed, this c=
an be done with per-link-direction negotiation too, and handled by the pe=
ers accordingly.<br />
<br />
Per-link-direction negotiation also allows to decouple the behaviour from=
inbound/outbound type of connection (currently we do not respond to GETA=
DDR from outbound). This logic seems not fundamental to me, but rather a =
temporary heuristic to prevent attacks, which might be changed in future.=
<br />
<br />
=23=23=23 Conclusion<br />
<br />
I think the solution fundamentally depends on the answer to:<br />
=E2=80=9CDo we believe that some of the future security advices for node =
operators would be to disable address relay to all (or most) of the links=
=E2=80=9D.<br />
<br />
If yes, I think we should use service bits.<br />
If no, I think we should use per-link-direction negotiation.
<div dir=3D=22auto=22><br /></div>
<div dir=3D=22auto=22>If the answer will change, we can also add a servic=
e bit later.<br />
<br />
Anyway, according to the current considerations I explained in this email=
, I=E2=80=99d suggest extending BIP-155 with per-link-direction negotiati=
on, but I=E2=80=99m interested in the opinion of the community.
<div dir=3D=22auto=22><br />
=23=23=23 References<br />
<br />
1. Bitcoin core dev IRC meeting (<a href=3D=22http://www.erisian.com.au/b=
itcoin-core-dev/log-2019-10-17.html=22>http://www.erisian.com.au/bitcoin-=
core-dev/log-2019-10-17.html</a>)<br />
2. p2p: Avoid forwarding ADDR messages to SPV nodes (<a href=3D=22https:/=
/github.com/bitcoin/bitcoin/pull/17194=22>https://github.com/bitcoin/bitc=
oin/pull/17194</a>)<br />
3. BIP 155: addrv2 BIP proposal (<a href=3D=22https://github.com/bitcoin/=
bips/pull/766=22>https://github.com/bitcoin/bips/pull/766</a>)<br />
<br />
=E2=80=93 gleb<br /></div>
</div>
</div>
</div>
</body>
</html>
--5db0cbb6_74de0ee3_4fe--
|