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 <jlru...@mit.edu> wrote: > >> On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil <e...@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).
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
