Eric Voskuil [ARCHIVE] on Nostr: đź“… Original date posted:2020-08-24 đź“ť Original message:I see no requirement for ...
đź“… Original date posted:2020-08-24
📝 Original message: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 at mit.edu> wrote:
>
>> On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil <eric at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/e5e1facc/attachment-0001.html>;
📝 Original message: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 at mit.edu> wrote:
>
>> On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil <eric at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/e5e1facc/attachment-0001.html>;