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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5EDCD1533
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Mar 2019 03:03:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com
[209.85.208.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 158445E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Mar 2019 03:03:04 +0000 (UTC)
Received: by mail-ed1-f51.google.com with SMTP id a16so9066788edn.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 05 Mar 2019 19:03:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=rvkp1cECrJ9XO1xR/iAWT/+GLotNz9BB+s4Sl43rBY0=;
b=fPMXb9jKwLJoBItUR/SnFQbirlE8/J8D10FX/eukhHMC939qc/lo3dqsJfshF73GQs
FYL8EA7Rn3SssgR3XhcJ3ID44s8IE2ZCqLJmLYkxNGwaLK2utEJGCCRM0gTdQFIs2TKO
ndUtAuoo1kaQf7fjDC4Ip+7Js/KAZDH6iQZ31yTWG6tLVQDqkxQmMFcGVklhLKcl1vwE
FMte/YGrXykPHwfmSHkDFJt9W/v/4WJD0Q+4uVYeyzjxx5l+2v1u9qnXRWSclnqxLwal
p6ge4h/ynQ1VomaMo4FuPgmKFJiLMYbRthg+TrCsHvwCc7LFhQCO9Jkxx7pbH0AQcHdR
JRpg==
X-Gm-Message-State: APjAAAUtnunZXh6OGt9xDdkPo9bpnTzE6NmmoFc6V+OagrTbSUZTfs5z
U/ir7dd10Fq81N9lRd+GgJ/yByVg6C1xGn9r7P8=
X-Google-Smtp-Source: APXvYqyrG1t7tcnipTmyoBZ3smENiiXXfjZiUZEPyF+i4ayilWWMAod38R2eOJgGrB50nUAaWINmCcX020IIKVQKo7s=
X-Received: by 2002:a50:eb82:: with SMTP id y2mr21565277edr.38.1551841383706;
Tue, 05 Mar 2019 19:03:03 -0800 (PST)
MIME-Version: 1.0
References: <20190218075632.byec6ka7cat3rbiz@aurora.visucore.com>
In-Reply-To: <20190218075632.byec6ka7cat3rbiz@aurora.visucore.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 6 Mar 2019 03:02:51 +0000
Message-ID: <CAAS2fgT-KFCx3Z+tv9f9Y=8LSN+0PbO7B2ugGrmgtbkaoSnC9g@mail.gmail.com>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
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, 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 03:03:06 -0000
On Wed, Mar 6, 2019 at 12:22 AM Wladimir J. van der Laan via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> Field <code>addr</code> has a variable length, with a maximum of 32 bytes=
(256 bits). Clients SHOULD reject
> longer addresses.
Is 32 bytes long enough for I2P? It seems like there are two formats,
is there a reason we might want to use the longer one?
https://geti2p.net/en/docs/naming
Probably the spec should define the limit per address type (e.g.
sending a 32 byte IPv4 makes no sense). And either a maximum for ANY
type (so that 1000*largest size is reasonable), or a maximum size for
the message (e.g. regardless of the included size, an add message
should never be over, say 100k).
> * ''Client MAY store and gossip address formats that they do not know abo=
ut'': 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 int=
ernet at all.
I think clients should be discouraged from gossiping stuff they cannot
test but not forbidden from doing so. Separately, they should be
strongly discouraged from gossiping types they don't understand at
all. We don't really want to see people doing file xfer over invalid
addr types. :)
|
