Suhas Daftuar [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-24 📝 Original message:Hi all, Thanks for the ...
📅 Original date posted:2020-08-24
📝 Original message:Hi all,
Thanks for the helpful discussion.
My primary motivation in starting this thread was to establish what the
expectations are for new feature deployment (particularly whether the
protocol version should continue to be bumped or not), and I think I have
that answer -- different from what I proposed when I started this thread,
but not in a way that I think meaningfully hinders future work. So I'm
happy to leave it at that and withdraw my suggestion.
Cheers,
Suhas
On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Aug 21, 2020, at 15:16, Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
> >
> > Hmm, could that not be accomplished by simply building this into new
> messages? eg, send "betterprotocol", if you see a verack and no
> "betterprotocol" from your peer, send "worseprotocol" before you send a
> "verack".
> >
> > Matt
> >
> >> 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.
>
> >> An example of this would be (were it not already out without a feature
> negotiation existing) WTXID/TXID relay.
> >> The SYNC primitve simply codifies what order messages should be in and
> when you're done for a phase of negotiation offering something. It can be
> done without, but then you have to be more careful to broadcast in the
> correct order and it's not clear when/if you should wait for more time
> before responding.
> >> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <jlrubin at mit.edu <mailto:
> jlrubin at mit.edu>> wrote:
> >> Actually we already have service bits (which are sadly limited)
> which allow negotiation of non bilateral feature
> >> support, so this would supercede that.
> >> --
> >> @JeremyRubin <https://twitter.com/JeremyRubin><;
> https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/895e4c0a/attachment-0001.html>;
📝 Original message:Hi all,
Thanks for the helpful discussion.
My primary motivation in starting this thread was to establish what the
expectations are for new feature deployment (particularly whether the
protocol version should continue to be bumped or not), and I think I have
that answer -- different from what I proposed when I started this thread,
but not in a way that I think meaningfully hinders future work. So I'm
happy to leave it at that and withdraw my suggestion.
Cheers,
Suhas
On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Aug 21, 2020, at 15:16, Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
> >
> > Hmm, could that not be accomplished by simply building this into new
> messages? eg, send "betterprotocol", if you see a verack and no
> "betterprotocol" from your peer, send "worseprotocol" before you send a
> "verack".
> >
> > Matt
> >
> >> 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.
>
> >> An example of this would be (were it not already out without a feature
> negotiation existing) WTXID/TXID relay.
> >> The SYNC primitve simply codifies what order messages should be in and
> when you're done for a phase of negotiation offering something. It can be
> done without, but then you have to be more careful to broadcast in the
> correct order and it's not clear when/if you should wait for more time
> before responding.
> >> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <jlrubin at mit.edu <mailto:
> jlrubin at mit.edu>> wrote:
> >> Actually we already have service bits (which are sadly limited)
> which allow negotiation of non bilateral feature
> >> support, so this would supercede that.
> >> --
> >> @JeremyRubin <https://twitter.com/JeremyRubin><;
> https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/895e4c0a/attachment-0001.html>;