From: Eric Voskuil <eric@voskuil•org>
To: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup
Date: Mon, 24 Aug 2020 13:33:46 -0700 [thread overview]
Message-ID: <B5077EB6-64CB-4067-96F0-5E11C074FE8C@voskuil.org> (raw)
In-Reply-To: <CAD5xwhiSf3isoMsVJiv5KQ3n5ymcS+StigkX_eDe5hmAGra-0Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
I see no requirement for anything here apart from exchanging a list of supported “features”. Conditionally hiding a feature provides no benefit. Any peer that wants it can get it (obfuscation being weak security), and otherwise it’s a non-issue.
e
> On Aug 24, 2020, at 13:22, Jeremy <jlrubin@mit•edu> wrote:
>
>> On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil <eric@voskuil•org> 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’t want to expose the buggy feature, then disable it. Otherwise you cannot prevent peers from accessing 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’t discern 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).
[-- Attachment #2: Type: text/html, Size: 2438 bytes --]
next prev parent reply other threads:[~2020-08-24 20:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 19:28 Suhas Daftuar
2020-08-16 17:24 ` Jeremy
2020-08-16 19:06 ` Eric Voskuil
2020-08-17 20:40 ` Suhas Daftuar
2020-08-17 21:21 ` Eric Voskuil
2020-08-20 14:13 ` David A. Harding
2020-08-18 14:59 ` Matt Corallo
2020-08-18 16:54 ` Eric Voskuil
2020-08-18 17:26 ` Matt Corallo
2020-08-18 18:11 ` Eric Voskuil
2020-08-18 18:25 ` Matt Corallo
2020-08-18 18:56 ` Eric Voskuil
2020-08-21 2:36 ` Anthony Towns
2020-08-21 4:25 ` Eric Voskuil
2020-08-21 14:15 ` lf-lists
2020-08-21 16:42 ` Eric Voskuil
2020-08-21 19:50 ` Jeremy
2020-08-21 20:45 ` Matt Corallo
2020-08-21 21:08 ` Jeremy
2020-08-21 21:17 ` Jeremy
2020-08-21 22:16 ` Matt Corallo
2020-08-23 17:49 ` Eric Voskuil
2020-08-24 9:44 ` Suhas Daftuar
2020-08-24 13:59 ` G. Andrew Stone
2020-08-24 19:58 ` Jeremy
2020-08-24 20:17 ` Eric Voskuil
2020-08-24 20:21 ` Jeremy
2020-08-24 20:33 ` Eric Voskuil [this message]
2020-08-21 21:17 ` Eric Voskuil
2020-08-23 17:45 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B5077EB6-64CB-4067-96F0-5E11C074FE8C@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox