<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <ahref="#rfc2119"id="id1"class="footnote_reference">1</a></p>
<p>The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <ahref="#zip-0200"id="id2"class="footnote_reference">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Overwinter</dt>
<dd>Code-name for the first Zcash network upgrade, also known as Network Upgrade Zero.</dd>
</dl>
</section>
<sectionid="abstract">
<h2>Abstract</h2>
<p>This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Activation Mechanism <ahref="#zip-0200"id="id3"class="footnote_reference">3</a>.</p>
<p>Related to:</p>
<ul>
<li>Transaction Signature Verification for Overwinter <ahref="#zip-0143"id="id4"class="footnote_reference">2</a>.</li>
<li>Version 3 Transaction Format for Overwinter <ahref="#zip-0202"id="id5"class="footnote_reference">4</a>.</li>
<p>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.</p>
</section>
<sectionid="specification">
<h2>Specification</h2>
<p>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.</p>
<p>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 <ahref="#bitcoin-version-handshake"id="id7"class="footnote_reference">8</a> involves "version" and "verack" messages being exchanged.:</p>
<pre>L -> R: Send version message with the local peer's version
<p>Currently, nodes will reject connections from peers with an advertised protocol version lower than the other node's minimum supported protocol version.</p>
<p>This value is defined as:</p>
<pre>//! disconnect from peers older than this proto version
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
// disconnect from old peers running protocol version we don't support.</pre>
<p>Activation of Overwinter will take place first on testnet, and if successful, followed by mainnet.</p>
<p>To prepare for testnet activation, Overwinter nodes will contain the following constants:</p>
<pre>static const int PROTOCOL_VERSION = 170003;
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
<p>Nodes running protocol version 170003 have a testnet activation height set, but do not have a mainnet activation height set.</p>
<p>On testnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170002.</p>
<p>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.</p>
<p>To prepare for mainnet activation, Overwinter nodes will contain the following constants:</p>
<pre>static const int PROTOCOL_VERSION = 170005;
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
<p>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 <code>NODE_BLOOM</code> service bit defined in <ahref="#bip-0111"id="id8"class="footnote_reference">6</a>.)</p>
<p>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.</p>
<p>As these constants cannot be changed at run-time, once Overwinter activates on testnet or mainnet, Overwinter nodes should take steps to:</p>
<ul>
<li>reject new connections from pre-Overwinter nodes;</li>
<li>disconnect any existing connections to pre-Overwinter nodes.</li>
</ul>
</section>
<sectionid="network-coalescence">
<h3>Network Coalescence</h3>
<p>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.</p>
<p>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. <ahref="#eclipse-attack"id="id9"class="footnote_reference">9</a></p>
<p>To assist network coalescence before the activation height, we update the eviction process to place a higher priority on evicting Sprout nodes.</p>
<p>Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers:</p>
<p>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:</p>
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
<p>The eviction candidates can be modified as so:</p>
<p>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.</p>
</section>
<sectionid="disconnecting-existing-connections">
<h3>Disconnecting Existing Connections</h3>
<p>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, <code>ProcessMessage</code> is modified so that once Overwinter activates, if necessary, the protocol version of an existing peer is validated when inbound messages arrive.</p>
<p>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.</p>
<p>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.</p>