diff --git a/zip-0252.html b/zip-0252.html index d3cf17ce..86a57b6d 100644 --- a/zip-0252.html +++ b/zip-0252.html @@ -17,9 +17,9 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/440> Pull-Request: <https://github.com/zcash/zips/pull/446>

Terminology

-

The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. 1

-

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 6

-

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.

+

The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. 1

+

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 6

+

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.

Abstract

This proposal defines the deployment of the NU5 network upgrade.

@@ -28,29 +28,29 @@ Pull-Request: <https://githu

NU5 deployment

The primary sources of information about NU5 consensus and peer-to-peer protocol changes are:

-

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

-

Unified addresses and viewing keys are described in ZIP 316 18.

+

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

+

Unified addresses and viewing keys are described in ZIP 316 18.

The following ZIPs have been updated in varying degrees to take into account Orchard:

-

The following network upgrade constants 6 are defined for the NU5 upgrade:

+

The following network upgrade constants 6 are defined for the NU5 upgrade:

CONSENSUS_BRANCH_ID
0xc2d6d0b4
@@ -73,14 +73,14 @@ Pull-Request: <https://githu
  • reject new connections from pre-NU5 nodes on that network;
  • disconnect any existing connections to pre-NU5 nodes on that network.
    • -

    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. 16

    +

    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. 16

    Backward compatibility

    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 zcashd v4.7.0.)

    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 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 15. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.

    -

    Backward compatibility of the new MSG_WTX inv type introduced for inv and getdata messages is discussed in 16.

    +

    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 15. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.

    +

    Backward compatibility of the new MSG_WTX inv type introduced for inv and getdata messages is discussed in 16.

    Support in zcashd

    Several versions of zcashd have implemented versions of the NU5 consensus rules on Testnet:

    @@ -100,7 +100,7 @@ Pull-Request: <https://githu * 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 7.

    +

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

    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.