Add ZIP 205.

Signed-off-by: Daira Hopwood <[email protected]>

zip-0205.rst

@@ -0,0 +1,143 @@
+::
+
+  ZIP: 205
+  Title: Deployment of the Sapling Network Upgrade
+  Author: Daira Hopwood <[email protected]>
+  Credits: Simon Liu <[email protected]>
+  Category: Consensus
+  Created: 2018-10-08
+  License: MIT
+
+Terminology
+===========
+
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be 
+interpreted as described in RFC 2119. [#RFC2119]_
+
+The terms "branch" and "network upgrade" in this document are to be interpreted as 
+described in ZIP 200. [#zip-0200]_
+
+The terms below are to be interpreted as follows:
+
+Sapling
+  Code-name for the second Zcash network upgrade, also known as Network Upgrade 1.
+
+
+Abstract
+========
+
+This proposal defines the deployment of the Sapling network upgrade. In addition, 
+it describes a hard fork that occurred on testnet to allow "minimum-difficulty" 
+blocks.
+
+
+Specification
+=============
+
+Sapling deployment
+------------------
+
+The primary sources of information about Sapling consensus protocol changes are:
+
+- The Zcash Protocol Specification [#protocol]_.
+- Transaction Signature Verification for Sapling [#zip-0243]_.
+- Network Upgrade Activation Mechanism [#zip-0200]_.
+
+The network handshake and peer management mechanisms defined in [#zip-0201]_ also 
+apply to this upgrade.
+
+
+The following network upgrade constants [#zip-0200]_ are defined for the Sapling 
+upgrade:
+
+BRANCH_ID
+  ``0x76b809bb``
+
+ACTIVATION_HEIGHT (Sapling)
+  Testnet: 280000
+
+  Mainnet: 419200
+
+
+On testnet, Sapling had activated prior to this height, but that branch was rolled 
+back. A subsequent hard fork occurred on testnet, changing the difficulty algorithm 
+to accept "minimum-difficulty" blocks under certain conditions starting at block 
+height 299188.
+
+
+On both mainnet and testnet, Sapling-compatible nodes MUST advertise protocol 
+version 170007 or later. The minimum peer protocol version that Sapling-compatible 
+nodes will connect to, remains 170002.
+
+Pre-Sapling nodes are defined as nodes advertising a protocol version less than 
+170007.
+
+Approximately three days (defined in terms of block height) before the Sapling 
+activation height, Sapling-compatible nodes will change the behaviour of their peer 
+connection logic in order to prefer pre-Sapling peers for eviction from the set of 
+peer connections.
+
+    /** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
+    static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
+
+The implementation is similar to that for Overwinter which was described in 
+[#zip-0201].
+
+Once Sapling activates on testnet or mainnet, Sapling nodes should take steps to:
+
+- reject new connections from pre-Sapling nodes;
+- disconnect any existing connections to pre-Sapling nodes.
+
+
+Change to difficulty adjustment on testnet
+------------------------------------------
+
+Section 7.6.3 of [#protocol]_ describes the algorithm used to adjust the difficulty
+of a block (defined in terms of a "target threshold") based on the `nTime` and
+`nBits` fields of preceding blocks.
+
+This algorithm changed on testnet, starting from block 299188, to allow 
+"minimum-difficulty" blocks. If the block time of a block from this height onward 
+is at least 15 minutes after that of the preceding block, then the block is a 
+minimum-difficulty block, and its target threshold is set to the value of
+PoWLimit for testnet (see [#protocol]_ section 5.3). However, its `nBits` field
+is still computed according to the original difficulty adjustment algorithm.
+
+This does not affect how the minimum-difficulty block is treated for subsequent 
+difficulty adjustments. In particular, only the `nBits` field computed by the
+original algorithm is used for the purpose of computing the `MeanTarget` values
+from which subsequent difficulty changes are calculated.
+
+This change does not affect mainnet.
+
+
+Backward compatibility
+======================
+
+Prior to the network upgrade activating, Sapling and pre-Sapling nodes are 
+compatible and can connect to each other. However, Sapling nodes will have a 
+preference for connecting to other Sapling nodes, so pre-Sapling nodes will 
+gradually be disconnected in the run up to activation.
+
+Once the network upgrades, even though pre-Sapling nodes can still accept the 
+numerically larger protocol version used by Sapling as being valid, Sapling nodes 
+will always disconnect peers using lower protocol versions.
+
+
+Support in zcashd
+=================
+
+Support for Sapling consensus rules was implemented in zcashd version 2.0.0.
+The majority of support for RPC calls and persistence of Sapling z-addresses
+was implemented in version 2.0.1. Both of these versions advertise protocol
+version 170007.
+
+
+References
+==========
+
+.. [#protocol] `Zcash Protocol Specification, Version 2018.0-beta-32 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
+.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
+.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
+.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
+.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling <https://github.com/zcash/zips/blob/master/zip-0243.rst>`_