<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <aid="footnote-reference-1"class="footnote_reference"href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <aid="footnote-reference-2"class="footnote_reference"href="#zip-0200">6</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <aid="footnote-reference-3"class="footnote_reference"href="#protocol-networks">3</a>.</p>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <aid="footnote-reference-14"class="footnote_reference"href="#zip-0201">7</a> also apply to this upgrade.</p>
<p>Unified addresses and viewing keys are described in ZIP 316 <aid="footnote-reference-15"class="footnote_reference"href="#zip-0316">18</a>.</p>
<p>The following network upgrade constants <aid="footnote-reference-23"class="footnote_reference"href="#zip-0200">6</a> are defined for the NU5 upgrade:</p>
<p>Note: A first activation of NU5, with a previous version of the Orchard circuit and other NU5 consensus rules, occurred on Testnet at block height 1599200 with consensus branch ID 0x37519621 and peer protocol version 170015. With the release of <cite>zcashd</cite> v4.7.0, Testnet is being rolled back to another chain that forks from the block immediately preceding that activation, at height 1599199. This chain had been continuously mined by <cite>zcashd</cite> v4.0.0 nodes modified to disable End-of-Service halt.</p>
<p>For each network (Testnet and Mainnet), nodes compatible with NU5 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU5) for that activation.</p>
<p>For each network, pre-NU5 nodes are defined as nodes advertising a protocol version less than that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).</p>
<p>The change to the peer-to-peer protocol described in ZIP 239 took effect from peer protocol version 170014 onward, on both Testnet and Mainnet. <aid="footnote-reference-24"class="footnote_reference"href="#zip-0239">16</a></p>
<p>Prior to the network upgrade activating on each network, NU5 and pre-NU5 nodes are compatible and can connect to each other. (In the case of Testnet, there was a prolonged period of network fracturing due to a consensus bug, but this is expected to be resolved with the release of <cite>zcashd</cite> v4.7.0.)</p>
<p>Once the network upgrades, even though pre-NU5 nodes can still accept the numerically larger protocol version used by NU5 as being valid, NU5 nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by <aid="footnote-reference-25"class="footnote_reference"href="#zip-0225">15</a>. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.</p>
<p>Backward compatibility of the new <code>MSG_WTX</code> inv type introduced for <code>inv</code> and <code>getdata</code> messages is discussed in <aid="footnote-reference-26"class="footnote_reference"href="#zip-0239">16</a>.</p>
<sectionid="support-in-zcashd"><h2><spanclass="section-heading">Support in zcashd</span><spanclass="section-anchor"><arel="bookmark"href="#support-in-zcashd"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h2>
<li><cite>zcashd</cite> v4.5.0 implemented a consensus revision that contained critical bugs in the Orchard Action circuit.</li>
<li>Before that revision could activate, <cite>zcashd</cite> v4.5.1 was released, with a later activation height of 1599200 as described in section <ahref="#nu5-deployment">NU5 deployment</a> above. This revision also had a consensus bug that caused many nodes to stall at or near height 1779199, shortly after the first block containing an Orchard output.</li>
<li><cite>zcashd</cite> v4.7.0 implements what is expected to be the final revision of the NU5 consensus rules, causing a long rollback to an alternate Testnet chain. It is necessary to use the <code>-reindex</code> and <code>-rescan</code> options to <cite>zcashd</cite> in order to follow this chain as intended.</li>
<sectionid="backward-compatibility-in-zcashd"><h3><spanclass="section-heading">Backward compatibility in zcashd</span><spanclass="section-anchor"><arel="bookmark"href="#backward-compatibility-in-zcashd"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>The minimum peer protocol version that NU5-compatible <cite>zcashd</cite> nodes will connect to is 170002. On Testnet, they will immediately disconnect from nodes advertising a peer protocol version less than 170040.</p>
<sectionid="nu5-deployment-for-zcashd"><h3><spanclass="section-heading">NU5 deployment for zcashd</span><spanclass="section-anchor"><arel="bookmark"href="#nu5-deployment-for-zcashd"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>For each network, approximately 1.5 days (defined in terms of block height) before the corresponding NU5 activation height, nodes compatible with NU5 activation on that network will change the behaviour of their peer connection logic in order to prefer pre-NU5 peers on that network for eviction from the set of peer connections:</p>
<pre>/**
* The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks).
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
*/
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<p>The implementation is similar to that for Overwinter which was described in <aid="footnote-reference-27"class="footnote_reference"href="#zip-0201">7</a>.</p>
<p>However, NU5 nodes will have a preference for connecting to other NU5 nodes, so pre-NU5 nodes will gradually be disconnected in the run up to activation.</p>
<sectionid="support-in-zebra"><h2><spanclass="section-heading">Support in Zebra</span><spanclass="section-anchor"><arel="bookmark"href="#support-in-zebra"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h2>
<p>Several versions of Zebra have implemented versions of the NU5 consensus rules on Testnet:</p>
<ul>
<li><cite>zebrad</cite> v1.0.0-alpha.18 implemented partial support for NU5 on Testnet, validating a strict subset of the NU5 consensus rules. This version had an activation height of 1599200, as described in section <ahref="#nu5-deployment">NU5 deployment</a> above.</li>
<li><cite>zebrad</cite> v1.0.0-beta.8 will fully validate what is expected to be the final revision of the NU5 consensus rules. As part of these consensus rule changes, <cite>zebrad</cite> v1.0.0-beta.8 will automatically re-download the entire chain from genesis, then follow an alternate chain starting at height 1599200. It will advertise protocol version 170050.</li>
<sectionid="backward-compatibility-in-zebra"><h3><spanclass="section-heading">Backward compatibility in Zebra</span><spanclass="section-anchor"><arel="bookmark"href="#backward-compatibility-in-zebra"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>The minimum peer protocol version that NU5-compatible Zebra nodes will connect to is 170002. They will immediately disconnect from nodes advertising a peer protocol version less than:</p>
<sectionid="nu5-deployment-for-zebra"><h3><spanclass="section-heading">NU5 deployment for Zebra</span><spanclass="section-anchor"><arel="bookmark"href="#nu5-deployment-for-zebra"><imgwidth="24"height="24"class="section-anchor"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>For each network, at the corresponding NU5 activation height, nodes compatible with NU5 activation on that network will close existing connections with pre-NU5 peers, and reject new connections from pre-NU5 peers.</p>