When a new inbound connection is received or an outbound connection created, a CNode object is instantiated with the version field set to INIT_PROTO_VERSION which has a value of 209. This value is not transmitted across the network, but for legacy reasons and technical debt beyond the scope of this ZIP, this value will not be changed.
Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake [#bitcoin-version-handshake]_ involves "version" and "verack" messages being exchanged.::
Currently, nodes will reject connections from peers with an advertised protocol version lower than the other node's minimum supported protocol version.
Nodes running protocol version 170003 have a testnet activation height set, but do not have a mainnet activation height set.
On testnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170002.
These constants allow pre-Overwinter nodes that support protocol version 170002, and Overwinter nodes (which support both protocol versions 170002 and 170003 before Overwinter activation) to remain connected until the activation.
To prepare for mainnet activation, Overwinter nodes will contain the following constants::
On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the ``NODE_BLOOM`` service bit defined in [#bip-0111]_.)
These constants allow pre-Overwinter nodes that support protocol versions 170002 to 170004 inclusive, and Overwinter nodes (which support protocol versions 170002 to 170005 inclusive before Overwinter activation) to remain connected until the activation.
Prior to the activation of Overwinter, nodes running a pre-Overwinter protocol version (e.g. 170002) and the Overwinter protocol version (170003 for testnet; 170005 for mainnet) remain connected with the same consensus rules, but it is desirable for nodes supporting Overwinter to connect preferentially to other nodes supporting Overwinter.
This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. [#eclipse-attack]_
Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers::
We update this process by adding behaviour so that the set of eviction candidates will prefer pre-Overwinter nodes, when the chain tip is in a period N blocks before the activation block height, where N is defined as::
The existing eviction process will classify and divide eviction candidates into buckets called netgroups. If a netgroup only has one peer, it will not be evicted. This means at least one pre-Overwinter node will remain connected upto the activation block height, barring any network issues or a high ban score.
At the activation block height, an Overwinter node may still remain connected to pre-Overwinter nodes. Currently, when connecting, a node can only perform the networking handshake once, where it sends the version message before any other messages are processed. To disconnect existing pre-Overwinter connections, ``ProcessMessage`` is modified so that once Overwinter activates, if necessary, the protocol version of an existing peer is validated when inbound messages arrive.
Prior to the network upgrade activating, Overwinter and pre-Overwinter nodes are compatible and can connect to each other. However, Overwinter nodes will have a preference for connecting to other Overwinter nodes, so pre-Overwinter nodes will gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Overwinter nodes can still accept the numerically larger protocol version used by Overwinter as being valid, Overwinter nodes will always disconnect peers using lower protocol versions.
..[#eclipse-attack]`Eclipse Attacks on Bitcoin’s Peer-to-Peer Network <https://eprint.iacr.org/2015/263>`_
..[#partition-discussion]`Partition nodes with old protocol version from network in advance of hard fork <https://github.com/zcash/zcash/issues/2775>`_