Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-24 📝 Original message:> > > > > > > * >> On ...
📅 Original date posted:2020-08-24
📝 Original message:>
>
>
>
>
>
> * >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/f26112b9/attachment.html>;
📝 Original message:>
>
>
>
>
>
> * >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/f26112b9/attachment.html>;