Heartwood deployment

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

• The Zcash Protocol Specification 2
• ZIP 200: Network Upgrade Mechanism 3
• ZIP 213: Shielded Coinbase 5
• ZIP 221: FlyClient - Consensus-Layer Changes 6.

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

The following network upgrade constants 3 are defined for the Heartwood upgrade:

CONSENSUS_BRANCH_ID

0xF5B9230B

ACTIVATION_HEIGHT (Heartwood)

Testnet: 903800

Mainnet: 903000

Nodes compatible with Heartwood activation on testnet MUST advertise protocol version 170010 or later. Nodes compatible with Heartwood activation on mainnet MUST advertise protocol version 170011 or later. The minimum peer protocol version that Heartwood-compatible nodes will connect to is 170002.

Pre-Heartwood testnet nodes are defined as nodes on testnet advertising a protocol version less than 170010. Pre-Heartwood mainnet nodes are defined as nodes on mainnet advertising a protocol version less than 170011.

For each network (testnet and mainnet), approximately 1.5 days (defined in terms of block height) before the corresponding Heartwood activation height, nodes compatible with Heartwood activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Heartwood 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 4.

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

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