Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil <eric@voskuil.org>]

[-- 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 --]