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
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B978360F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Mar 2019 09:15:02 +0000 (UTC)
X-Greylist: delayed 00:09:48 by SQLgrey-1.7.6
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com
[64.147.123.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9D042D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Mar 2019 09:15:01 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.west.internal (Postfix) with ESMTP id 0867C31E1;
Wed, 6 Mar 2019 04:05:12 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute1.internal (MEProxy); Wed, 06 Mar 2019 04:05:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
from:content-type:content-transfer-encoding:mime-version:subject
:date:references:to:in-reply-to:message-id; s=fm2; bh=Gx3/9IVaT0
a14KPpmxPGg5uaoTlMSXzBOlpWRaKnbek=; b=m0u1jpRtAj+DZ4SeSu9r928q8y
Wpp92EOi5y39Mh/+VHhcX0ClUP6iPOEYsCIoWaDq7j9M0wQb5Vxi4iZ+tGtxrOwk
GgwraNvCfNPZXVPDsV7zl3KP99S/PKaRyrGWevhwXiPlBQIfRaIfgYa7TPDU5lmk
33kSMkTH92ZOVWzNDNyXJyYdp2NzNeTNoypVScWIqbzGAokQWKRX8aw823DfED+q
O27Lfpgs90Rv+RCSUlZh7jnNMr80P14/3la+DPYlh4bN/8mUk5ibQjQ2kL0Nvh3E
0oybRFYFqTjJelL/kvQpvT3kkiIVmYP8yNjQBPlg/dqsT71eb0JZMovnHwnA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm2; bh=Gx3/9IVaT0a14KPpmxPGg5uaoTlMSXzBOlpWRaKnb
ek=; b=qqAo8qXV4lLlhMRXR7yTMcmpWsCua9A3FYFa944w+7/q+6FpxUzPM9tXf
JDFCF495eBwMTXkQdVE8XJ0x+VvuWdTVrcce/YjV4jZsdbiI9k8cGYGmPoC7xmRM
E3aPJg+5J4BIKZuSOokoeoYivxn3jkLuDMm7e2jiF+T65Ki2q7m/rJHl6EnZUJgY
zkJzQ81ZZD29NsX/4xMGKWrP7d9SZinyRqHqBECulGrBwoibQCmbnmcoGq/jWreJ
obCkj+SeSif10R6a7ZCC4nb8X9LvPwddqZSpQfOQ/0F35jgchr58lez6+RA4d1H0
RGQN45zXUK0zlwYpDQ67ZzLJbZ05g==
X-ME-Sender: <xms:SI1_XDTFhQUnKC5UdDFMTbEUqyEKbV5WFwkcuv9iYBDXhzMFuedvNA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeeggddufedtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephfgtgfgguffffhfvjgfkofesthhqmhdthhdtvdenucfhrhhomhepufhjohhr
shcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucfkph
epkeegrddutdehrdeiuddrudehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsjhhorhhs
sehsphhrohhvohhoshhtrdhnlhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:SI1_XJxMN7ORWGi6Q__Suxu_goFCIwoUFgUXnFIB-2iQ2OCDP-6r-w>
<xmx:SI1_XJuNnACZeYr3jKctntnkZSO294ENbUkZqRfVQdeG0qp0zN08Ug>
<xmx:SI1_XIzQg7NG8aJyWj0nLDlFzwEwxlWh6j9jAehNn0O3QnHs17c2Rg>
<xmx:SI1_XGQOQJSrcULwmgjSdRUAkqgCTtksOol1qt1ChvZXnEaShGKckw>
Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl
[84.105.61.15])
by mail.messagingengine.com (Postfix) with ESMTPA id B6F7FE4121;
Wed, 6 Mar 2019 04:05:11 -0500 (EST)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 6 Mar 2019 10:05:09 +0100
References: <20190218075632.byec6ka7cat3rbiz@aurora.visucore.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"Wladimir J. van der Laan" <laanwj@gmail.com>
In-Reply-To: <20190218075632.byec6ka7cat3rbiz@aurora.visucore.com>
Message-Id: <00F86707-27B3-4153-8944-F71B4EF8AE95@sprovoost.nl>
X-Mailer: Apple Mail (2.3445.102.3)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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, 06 Mar 2019 14:41:17 +0000
Subject: Re: [bitcoin-dev] BIP proposal - addrv2 message
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, 06 Mar 2019 09:15:02 -0000
Concept ACK.
> =3D=3DConsiderations=3D=3D
>=20
> (to be discussed)
>=20
> * ''Client MAY store and gossip address formats that they do not know =
about'': does it ever make sense to gossip addresses outside a certain =
overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for =
networks that have no exit nodes as there is no overlap with the =
globally routed internet at all.
What exactly do you mean by "do not know about"? It could mean:
1. A new Network ID was recently introduced which an older node doesn't =
about.
In that case the node won't even know the address length, so it can't =
parse the entry.
In fact it can't parse the entire address message if a single address =
has an unknown format. Maybe require a single address type per ADDR2 =
message?
2. The Network ID doesn't match the network the node received this =
message on
The node should probably be agnostic about where it received this =
information from.
3. The node currently doesn't support a Network ID
But what does that mean? No connection? An explicitly disabled setting? =
A missing dependency? The operating system doesn't support it?
I think "MAY" is the correct choice for storing for (2).
For (3) I think it makes sense for nodes to store information even if =
they're disconnected, but not if they have a setting disabled or no =
driver. Though that implementation detail doesn't seem relevant to the =
standard.
I don't think it's a good idea to gossip information you can't at least =
in theory verify, but we already do that with Tor V2. It's useful to =
gossip information about other networks to help e.g. IPv4 nodes =
bootstrap Tor connections. On the other hand, that could also help an =
attacker link them. We could recommend that with addrv2 the node should =
make sure gossip messages were received on the correct interface, but =
that may not be practical.
> * Lower precision of <code>time</code> field? seconds precision seems =
overkill, and can even be harmful, there have been attacks that =
exploited high precision timestamps for mapping the current network =
topology.
>=20
> ** (gmaxwell) If you care about space time field could be reduced to =
16 bits easily. Turn it into a "time ago seen" quantized to 1 hour =
precision. (IIRC we quantize times to 2hrs regardless).
That seems like a good idea.
> * (gmaxwell) Optional (per-service) data could be useful for various =
things:
> [...]
> ** If we want optional flags. I guess the best thing would just be a =
byte to include the count of them, then a byte "type" for each one where =
the type also encodes if the payload is 0/8/16/32 bits. (using the two =
MSB of the type to encode the length). And then bound the count of them =
so that the total is still reasonably sized.
Adding more information seems useful, though also creates more topology =
mapping opportunities.
- Sjors
|
