From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B978360F for ; 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeeggddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffffhfvjgfkofesthhqmhdthhdtvdenucfhrhhomhepufhjohhr shcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucfkph epkeegrddutdehrdeiuddrudehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsjhhorhhs sehsphhrohhvohhoshhtrdhnlhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: 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 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 , "Wladimir J. van der Laan" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 time 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