Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 596D0C0051 for ; Mon, 24 Aug 2020 20:22:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 4644B87694 for ; Mon, 24 Aug 2020 20:22:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW94cj+hSK1J for ; Mon, 24 Aug 2020 20:22:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by whitealder.osuosl.org (Postfix) with ESMTPS id 6DDC5874E9 for ; Mon, 24 Aug 2020 20:22:06 +0000 (UTC) Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07OKM4Yc013698 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 24 Aug 2020 16:22:05 -0400 Received: by mail-ej1-f41.google.com with SMTP id dp2so8277247ejc.4 for ; Mon, 24 Aug 2020 13:22:05 -0700 (PDT) X-Gm-Message-State: AOAM531czm8KisVZerDezZPOd1dutgkbZrYLqka24S72HAx7A8T5vLcf 9+koime+TNzYyDHBzpxFWphAPlI/RTQhkAjhRxo= X-Google-Smtp-Source: ABdhPJyWgRGTzo3PT2y9KiXxNHMVD0xIAP50Vjec1tkyhJ1wXsHGWUiMbqF6s5+damkd5bV3/cLZw/GuVlD4CRmvJKk= X-Received: by 2002:a17:906:a3d6:: with SMTP id ca22mr7116141ejb.78.1598300524018; Mon, 24 Aug 2020 13:22:04 -0700 (PDT) MIME-Version: 1.0 References: <5B76307E-9810-49F1-8289-E0F0E84ACD72@voskuil.org> In-Reply-To: <5B76307E-9810-49F1-8289-E0F0E84ACD72@voskuil.org> From: Jeremy Date: Mon, 24 Aug 2020 13:21:52 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary="000000000000fa800c05ada55656" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 20:22:07 -0000 --000000000000fa800c05ada55656 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil wrote: > I said security, not privacy. You are in fact exposing the feature to any > node that wants to negotiate for it. if you don=E2=80=99t want to expose = the buggy > feature, then disable it. Otherwise you cannot prevent peers from accessi= ng > it. Presumably peers prefer the new feature if they support it, so there = is > no need for this complexity. > > > I interpreted* " This seems to imply a security benefit (I can=E2=80=99t di= scern any other rationale for this complexity). It should be clear that this is no more than trivially weak obfuscation and not worth complicating the protocol to achieve.", *to be about obfuscation and therefore privacy. The functionality that I'm mentioning might not be buggy, it might just not support peers who don't support another feature. You can always disconnect a peer who sends a message that you didn't handshake on (or maybe we should elbow bump given the times). --000000000000fa800c05ada55656 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil <eric@voskuil.org> wrote:
I s= aid security, not privacy. You are in fact exposing the feature to any node= that wants to negotiate for it. if you don=E2=80=99t want to expose the bu= ggy feature, then disable it. Otherwise you cannot prevent peers from acces= sing it. Presumably peers prefer the new feature if they support it, so the= re is no need for this complexity.



I interpr= eted " This seems to imply a security benefit (I can=E2=80=99t discern any other= =20 rationale for this complexity). It should be clear that this is no more=20 than trivially weak obfuscation and not worth complicating the protocol=20 to achieve.", to be about obfuscation and therefore privacy= .

The functionality that I'm mentioning might not be buggy,= it might just not support peers who don't support another feature. You= can always disconnect a peer who sends a message that you didn't hands= hake on (or maybe we should elbow bump given the times).
--000000000000fa800c05ada55656--