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:17:17 -0700 [thread overview]
Message-ID: <5B76307E-9810-49F1-8289-E0F0E84ACD72@voskuil.org> (raw)
In-Reply-To: <CAD5xwhgDWpaavk3R5gjUwMU37bRTmKC+o5hHoWVeaiW8WFQNjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
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.
e
> On Aug 24, 2020, at 12:59, Jeremy <jlrubin@mit.edu> wrote:
>
>
>>
>> >> On 8/21/20 5:17 PM, Jeremy wrote:
>> >> As for an example of where you'd want multi-round, you could imagine a scenario where you have a feature A which gets bugfixed by the introduction of feature B, and you don't want to expose that you support A unless you first negotiate B. Or if you can negotiate B you should never expose A, but for old nodes you'll still do it if B is unknown to them.
>>
>> 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.
>
>
> The benefit is not privacy oriented and I didn't intend to imply as such. The benefit is that you may only wish to expose functionality to peers which support some other set of features. For example, with wtxid relay, I might want to expose some additional functionality after establishing my peer supports it, that peers which do not have wtxid relay should not be allowed to use. The benefit over just exposing all functions is then a node might be programmed to support the new feature but not wtxid relay, which can lead to some incompatibilities.
>
> You cannot implement this logic as a purely post-hoc "advertise all and then figure out what is allowed" because then you require strict consistency between peers of that post-hoc feature availability implication map.
[-- Attachment #2: Type: text/html, Size: 2554 bytes --]
next prev parent reply other threads:[~2020-08-24 20:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 19:28 [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup 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 [this message]
2020-08-24 20:21 ` Jeremy
2020-08-24 20:33 ` Eric Voskuil
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=5B76307E-9810-49F1-8289-E0F0E84ACD72@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jlrubin@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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