đź“… 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>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 18:26:32
in reply to nevent1q…ts9n
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 18:26:32Event JSON
{
"id": "6ead163f43d718f10930ff1c883aa858fc21be237356476e494ee93811c33087",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686162392,
"kind": 1,
"tags": [
[
"e",
"43edfd73733fa9cb455dfd9022ab700e39020c27283a7e2f0343a8c6fb631001",
"",
"root"
],
[
"e",
"4b133fc8a896510bcece189ebf4a99ec69c6fb7f6701916ce29197f4f4e0fa76",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2020-08-24\n📝 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.\n\ne\n\n\u003e On Aug 24, 2020, at 13:22, Jeremy \u003cjlrubin at mit.edu\u003e wrote:\n\u003e \n\u003e\u003e On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\u003e\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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).\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/e5e1facc/attachment-0001.html\u003e",
"sig": "3f512ccb62902947afaceca2879e327001278a65e27fb7c0cba8856106f1e323b3ef7ba90318df123ce142a01f4ec9c1820e40e5ce2b8f27de789f3de4b6aa3f"
}