Canopy deployment

The primary sources of information about Canopy consensus protocol changes are:

• The Zcash Protocol Specification 2
• ZIP 200: Network Upgrade Mechanism 5
• ZIP 207: Funding Streams 7
• ZIP 211: Disabling Addition of New Value to the Sprout Value Pool 8
• ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext 9
• ZIP 214: Consensus rules for a Zcash Development Fund 10
• ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules 11
• ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants 13.

The network handshake and peer management mechanisms defined in ZIP 201 6 also apply to this upgrade.

The following network upgrade constants 5 are defined for the Canopy upgrade:

CONSENSUS_BRANCH_ID

0xE9FF75A6

ACTIVATION_HEIGHT (Canopy)

Testnet: 1028500

Mainnet: 1046400

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.

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.

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:

/**
 * 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;

The implementation is similar to that for Overwinter which was described in 6.

Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:

• reject new connections from pre-Canopy nodes on that network;
• disconnect any existing connections to pre-Canopy nodes on that network.