Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5EDCD1533 for ; 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 ; Wed, 6 Mar 2019 03:03:04 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id a16so9066788edn.1 for ; 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 Date: Wed, 6 Mar 2019 03:02:51 +0000 Message-ID: To: "Wladimir J. van der Laan" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > Field addr 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. :)