From d2c1d9b910e08a47a425dba11e757476995643c9 Mon Sep 17 00:00:00 2001 From: teor Date: Tue, 23 Feb 2021 18:14:04 +1000 Subject: [PATCH] ZIP-252: Replace Canopy with NU5 --- zip-0252.rst | 56 ++++++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/zip-0252.rst b/zip-0252.rst index 36a36020..c20f2680 100644 --- a/zip-0252.rst +++ b/zip-0252.rst @@ -21,23 +21,23 @@ ZIP 200. [#zip-0200]_ The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. -"Canopy" is the code-name for the fifth Zcash network upgrade, also known as -Network Upgrade 4. +NU5 is the code-name for the sixth Zcash network upgrade, also known as +Network Upgrade 5. Abstract ======== -This proposal defines the deployment of the Canopy network upgrade. +This proposal defines the deployment of the NU5 network upgrade. Specification ============= -Canopy deployment +NU5 deployment ----------------- -The primary sources of information about Canopy consensus protocol changes are: +The primary sources of information about NU5 consensus protocol changes are: - The Zcash Protocol Specification [#protocol]_ - ZIP 200: Network Upgrade Mechanism [#zip-0200]_ @@ -52,32 +52,32 @@ The network handshake and peer management mechanisms defined in ZIP 201 [#zip-02 also apply to this upgrade. -The following network upgrade constants [#zip-0200]_ are defined for the Canopy +The following network upgrade constants [#zip-0200]_ are defined for the NU5 upgrade: CONSENSUS_BRANCH_ID ``0xE9FF75A6`` -ACTIVATION_HEIGHT (Canopy) +ACTIVATION_HEIGHT (NU5) 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 +Nodes compatible with NU5 activation on testnet MUST advertise protocol version +170012 or later. Nodes compatible with NU5 activation on mainnet MUST advertise protocol version 170013 or later. The minimum peer protocol version that -Canopy-compatible nodes will connect to is 170002. +NU5-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 +Pre-NU5 testnet nodes are defined as nodes on testnet advertising a protocol +version less than 170012. Pre-NU5 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 +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:: /** @@ -89,38 +89,38 @@ from the set of peer connections:: The implementation is similar to that for Overwinter which was described in [#zip-0201]_. -Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to: +Once NU5 activates on testnet or mainnet, NU5 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. +- reject new connections from pre-NU5 nodes on that network; +- disconnect any existing connections to pre-NU5 nodes on that network. Backward compatibility ====================== -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 +Prior to the network upgrade activating on each network, NU5 and pre-NU5 +nodes are compatible and can connect to each other. 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. -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 +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. -Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not -define a new transaction version. Canopy transactions are therefore in the same +Unlike Overwinter and Sapling, and like Blossom and Heartwood, NU5 does not +define a new transaction version. NU5 transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in [#protocol-txnencodingandconsensus]_; and use the same transaction digest algorithm as defined in [#zip-0243]_. This does not imply that transactions are -valid across the Canopy activation, since signatures MUST use the appropriate +valid across the NU5 activation, since signatures MUST use the appropriate consensus branch ID. [#zip-0243]_ Support in zcashd ================= -Support for Canopy on testnet will be implemented in ``zcashd`` version 3.1.0, which -will advertise protocol version 170012. Support for Canopy on mainnet will be implemented +Support for NU5 on testnet will be implemented in ``zcashd`` version 3.1.0, which +will advertise protocol version 170012. Support for NU5 on mainnet will be implemented in ``zcashd`` version 4.0.0, which will advertise protocol version 170013.