With scheduled network upgrades, at the activation height, nodes on each branch should disconnect from nodes on other branches and only accept new incoming connections from nodes on the same branch.
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 involves "version" and "verack" messages being exchanged.::
This allows pre-Overwinter nodes (which only supports protocol version 170002) and Overwinter nodes (which support both 170002 and 170003) to remain connected prior to activation.
Prior to the activation of Overwinter, nodes running pre-Overwinter protocol version 170002 and the Overwinter protocol version 170003 remain connected with the same consensus rules, but it would be preferable for nodes supporting Overwinter to connect to other nodes supporting Overwinter.
This would 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 legacy nodes droppedsuddenly at the activation height, potentiallyleaving them isolated and susceptible to eclipse attacks. [link]
Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers::
// No connection to evict, disconnect the new connection
LogPrint("net", "failed to find an eviction candidate - connection dropped (full)\n");
CloseSocket(hSocket);
return;
}
}
We update this process by adding behaviour so that the set of eviction candidates will prefer pre-Overwinter node, when the chain tip is in a period N blocks before the activation block height, where N is defined as::
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1000.
The existing method of disconnecting a candidate remains:
vEvictionCandidates[0]->fDisconnect = true;
The existing eviction process also classifies and divides eviction candidates into groups. If a group only has one peer, it will not be evicted. This means at least one pre-Overwinter node should 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, the protocol version of a peer is always checked when processing inbound messages.
This proposal intentionally creates what is known as a hard fork where Overwinter nodes disconnect from pre-Overwinter nodes.
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.
