[bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Jeremy]

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. 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> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200821/2517650e/attachment.html>