Skip to content
Vasil Dimov edited this page Apr 16, 2020 · 1 revision

BIP155 signalling

New node capabilities

decode

Ability to understand addrv2 messages if received. The node can parse an addrv2 message and check if it is valid. This also implies that the node prefers to receive addrv2 messages over addr ones.

encode

Ability to create addrv2 messages. The node can encode IP addresses as addrv2 messages. This does not imply that the node will relay addresses to its peers. But if it does, then it can create addrv2 messages. If the other node has signaled decode, then an addrv2 message will be created and sent to him, otherwise the old addr will be used.

gossip

The node would relay some of the addresses to some of its peers (same distribution logic as now). The addresses will be encoded either as addr or addrv2 messages. This is unrelated to the encode and decode capabilities. This may help with https://github.com/bitcoin/bitcoin/pull/17194.

getaddr

The node can reply to getaddr messages. This implies that it maintains some sort of addresses database. This may help with https://github.com/bitcoin/bitcoin/pull/17194.

Ways to signal capabilities

protocol version

Bump the protocol version. If a node announces protocol version X or higher then it supports a given feature.

  • (pro) simple to implement
  • (con) not flexible as it implies that a node supports all features prior to X too, i.e. the protocol version is monotonically increasing number, not a bit map
  • (con) not gossiped, so if a node seeks to connect to nodes that have capability X, he is out of luck

messages

Send an explicit message "I have capability X" after initiating each P2P connection.

  • (pro) gives the most flexibility as the node can choose whether to enable a capability on a per-connection basis
  • (con) not gossiped, so if a node seeks to connect to nodes that have capability X, he is out of luck

service bits

Set a given service bit to indicate support for capability X.

  • (pro) simple to implement
  • (pro) is gossiped, thus a node can choose the nodes it connects to based on their capabilities
  • (con) a node cannot choose to enable it for some of its peers and disable it for others
  • (con) service bits are not unlimited - so far 5 of 64 have been used (but yes, the field can be extended past 64 bits should this ever be necessary)