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

Jeremy jlrubin at mit.edu
Sun Aug 16 17:24:09 UTC 2020

Concept ack!

It might be nice to include a few negotiation utility functions either in
this bip or at the same time in a separate bip. An example we might want to
include is a "polite disconnect", whereby a node can register that you
don't want to connect in the future due to incompatibility.

It also might be nice to standardize some naming convention or negotiation
message type so that we don't end up with different negotiation systems.
Then we can also limit the bip so that we're only defining negotiation
message types as ignorable v.s. some other message type (which can also be
ignored, but maybe we want to do something else in the future).

This also makes it easier for old (but newer than this bip) nodes to apply
some generic rules around reporting/rejecting/responding to unknown feature
negotiation v.s. an untagged message which might be a negotiation or
something else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200816/6fb078d1/attachment.html>

More information about the bitcoin-dev mailing list