<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <aid="id1"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="id2"class="footnote_reference"href="#zip-0200">5</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <aid="id3"class="footnote_reference"href="#protocol-networks">3</a>.</p>
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</p>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <aid="id12"class="footnote_reference"href="#zip-0201">6</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <aid="id13"class="footnote_reference"href="#zip-0200">5</a> are defined for the Canopy upgrade:</p>
<p>Nodes compatible with Canopy activation on testnet MUST advertise protocol version 170012 or later. Nodes compatible with Canopy activation on mainnet MUST advertise protocol version 170013 or later. The minimum peer protocol version that Canopy-compatible nodes will connect to is 170002.</p>
<p>Pre-Canopy testnet nodes are defined as nodes on testnet advertising a protocol version less than 170012. Pre-Canopy mainnet nodes are defined as nodes on mainnet advertising a protocol version less than 170013.</p>
<p>For each network (testnet and mainnet), approximately 1.5 days (defined in terms of block height) before the corresponding Canopy activation height, nodes compatible with Canopy activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Canopy peers on that network for eviction from the set of peer connections:</p>
<p>Prior to the network upgrade activating on each network, Canopy and pre-Canopy nodes are compatible and can connect to each other. However, Canopy nodes will have a preference for connecting to other Canopy nodes, so pre-Canopy nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Canopy nodes can still accept the numerically larger protocol version used by Canopy as being valid, Canopy nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <aid="id15"class="footnote_reference"href="#protocol-txnencoding">4</a>; and use the same transaction digest algorithm as defined in <aid="id16"class="footnote_reference"href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <aid="id17"class="footnote_reference"href="#zip-0243">12</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"src="assets/images/section-anchor.png"alt=""></a></span></h2>
<p>Support for Canopy on testnet will be implemented in <code>zcashd</code> version 3.1.0, which will advertise protocol version 170012. Support for Canopy on mainnet will be implemented in <code>zcashd</code> version 4.0.0, which will advertise protocol version 170013.</p>