From 3fc7a9a2b8b680b732da761f0a780306d2f62a4e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 10 Mar 2020 20:57:31 +0000 Subject: [PATCH 01/26] ZIP 207: line wrapping (to reduce the subsequent diff). Signed-off-by: Daira Hopwood --- zip-0207.rst | 63 ++++++++++++++++++++++++++++++---------------------- 1 file changed, 36 insertions(+), 27 deletions(-) diff --git a/zip-0207.rst b/zip-0207.rst index 10368b67b..545c9587d 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -12,8 +12,8 @@ Terminology =========== -The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in -RFC 2119. [#RFC2119]_ +The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are +to be interpreted as described in RFC 2119. [#RFC2119]_ Abstract @@ -57,13 +57,15 @@ We also define the following constants and functions: Funding streams --------------- -A funding stream is defined by a block reward fraction (represented as a numerator and a denominator), a start -height (inclusive), and an end height (exclusive). +A funding stream is defined by a block reward fraction (represented as a +numerator and a denominator), a start height (inclusive), and an end height +(exclusive). -By defining the issuance as a proportion of the total block issuance, rather than absolute zatoshis, this ZIP -dovetails with any changes to both block target times and issuance-per-block rates while maintaining an -unchanged target-time-based issuance schedule. We anticipate such target-time / issuance rate changes in other -ZIPs (for example, [#zip-0208]_). +By defining the issuance as a proportion of the total block issuance, rather +than absolute zatoshis, this ZIP dovetails with any changes to both block +target times and issuance-per-block rates while maintaining an unchanged +target-time-based issuance schedule. We anticipate such target-time / issuance +rate changes in other ZIPs (for example, [#zip-0208]_). The value of a funding stream at a given block height is defined as:: @@ -72,12 +74,14 @@ The value of a funding stream at a given block height is defined as:: BlockReward(height) * FundingStream[FUND].ValueNumerator ) / FundingStream[FUND].ValueDenominator) -An active funding stream at a given block height is defined as a funding stream for which the block height is -less than its end height, but not less than its start height. +An active funding stream at a given block height is defined as a funding +stream for which the block height is less than its end height, but not less +than its start height. -Each funding stream has an associated set of recipient addresses. Each address is used for at most 1/48th of a -halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given -block height is defined as follows:: +Each funding stream has an associated set of recipient addresses. +Each address is used for at most 1/48th of a halving interval, creating a +roughly-monthly sequence of funding periods. The address to be used for a +given block height is defined as follows:: AddressChangeInterval = PostBlossomHalvingInterval / 48 AddressPeriod(height) = @@ -88,12 +92,14 @@ block height is defined as follows:: AddressPeriod(height) - AddressPeriod(FundingStream[FUND].StartHeight) Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex(height)] -This has the property that all active funding streams change the address they are using on the same block -height schedule, aligned to the height of the first halving so that 48 funding periods fit cleanly within a -halving interval. This can be leveraged to simplify implementations, by batching the necessary outputs for -each funding period. +This has the property that all active funding streams change the address they +are using on the same block height schedule, aligned to the height of the +first halving so that 48 funding periods fit cleanly within a halving +interval. This can be leveraged to simplify implementations, by batching the +necessary outputs for each funding period. -Below is a visual representation of how stream addresses align with funding periods: +Below is a visual representation of how stream addresses align with funding +periods: ================================== ======== ======== ======== Example height Stream A Stream B Stream C @@ -121,14 +127,16 @@ Founders' Reward address period prior to Blossom activation. Consensus rules --------------- -Prior to activation of the Blossom network upgrade, the existing consensus rule for payment of the original -Founders' Reward is enforced. [#original-fr-consensus-rule]_ +Prior to activation of the Blossom network upgrade, the existing consensus rule +for payment of the original Founders' Reward is enforced. [#original-fr-consensus-rule]_ Once the Blossom network upgrade activates: -- The existing consensus rule [#original-fr-consensus-rule]_ is no longer active. -- The coinbase transaction in each block MUST contain at least one output per active funding stream that pays - the stream's value to the stream's recipient address for the block's height. +- The existing consensus rule [#original-fr-consensus-rule]_ is no longer + active. +- The coinbase transaction in each block MUST contain at least one output per + active funding stream that pays the stream's value to the stream's recipient + address for the block's height. Stream definitions ------------------ @@ -452,10 +460,11 @@ This proposal was originally intended to be deployed with the Blossom network up Backward compatibility ====================== -This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this -mechanism requires that all network participants upgrade their software to a compatible version within the -upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade -branch that persists. +This proposal intentionally creates what is known as a "bilateral consensus +rule change". Use of this mechanism requires that all network participants +upgrade their software to a compatible version within the upgrade window. +Older software will treat post-upgrade blocks as invalid, and will follow any +pre-upgrade branch that persists. This proposal is designed with the explicit requirement of not altering the overall issuance schedule (based on time), nor does it alter the proportion or timeline of the overall Founders' Reward. As a result, no users From 811fb7e0ce2feb95e9ad1f8273c3ce3aa9090996 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 10 Mar 2020 21:49:18 +0000 Subject: [PATCH 02/26] Reintroduce ZIP 207. Signed-off-by: Daira Hopwood --- README.rst | 2 +- css/style.css | 2 +- index.html | 2 +- zip-0207.html | 558 ++++++++++++++++++-------------------------------- zip-0207.rst | 374 ++++++++++++--------------------- 5 files changed, 337 insertions(+), 601 deletions(-) diff --git a/README.rst b/README.rst index 94d9db3a4..7211ee6d2 100644 --- a/README.rst +++ b/README.rst @@ -57,7 +57,7 @@ Index of ZIPs 203 Transaction Expiry Final 205 Deployment of the Sapling Network Upgrade Final 206 Deployment of the Blossom Network Upgrade Final - 207 Split Founders' Reward Withdrawn + 207 Funding Streams Draft 208 Shorter Block Target Spacing Final 209 Prohibit Negative Shielded Value Pool Final 210 Sapling Anchor Deduplication within Transactions Draft diff --git a/css/style.css b/css/style.css index 36c73f23f..158b07d61 100644 --- a/css/style.css +++ b/css/style.css @@ -255,7 +255,7 @@ td:first-child { width: 920px; } pre, div.math, table { - font-size: 0.9375rem; + font-size: 0.85rem; } } diff --git a/index.html b/index.html index 76d4d4861..8ab8fe379 100644 --- a/index.html +++ b/index.html @@ -36,7 +36,7 @@ 203 Transaction Expiry Final 205 Deployment of the Sapling Network Upgrade Final 206 Deployment of the Blossom Network Upgrade Final - 207 Split Founders' Reward Withdrawn + 207 Funding Streams Draft 208 Shorter Block Target Spacing Final 209 Prohibit Negative Shielded Value Pool Final 210 Sapling Anchor Deduplication within Transactions Draft diff --git a/zip-0207.html b/zip-0207.html index 877790522..026bb7aa8 100644 --- a/zip-0207.html +++ b/zip-0207.html @@ -1,52 +1,70 @@ - ZIP 207: Split Founders' Reward + ZIP 207: Funding Streams 
ZIP: 207
-Title: Split Founders' Reward
+Title: Funding Streams
 Owners: Jack Grigg <str4d@electriccoin.co>
+        Daira Hopwood <daira@electriccoin.co>
 Category: Consensus
-Status: Withdrawn
+Status: Draft
 Created: 2019-01-04
 License: MIT

Terminology

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

+

The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 3 5

+

The terms below are to be interpreted as follows:

+
+
${NU4}
+
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
+
Testnet
+
The Zcash test network, as defined in the Zcash Protocol Specification. 2
+
Mainnet
+
The Zcash production network, as defined in the Zcash Protocol Specification. 2
+

Abstract

-

This Withdrawn proposal would have altered consensus rules to split the original Founders' Reward across several recipient addresses per block instead of one, corresponding to the several funding streams contained within it.

+

This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.

+

This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 10. It should be read in conjunction with ZIP 1014 12, which describes the high-level requirements for that fund.

Motivation

-

Since the launch of the Zcash network, the consensus rules have required that until the first block reward halving (at block 850,000), each block must send 20% of the block subsidy to a hard-coded transparent address. 2 This funding stream is referred to as the Founders' Reward.

-

This stream of 2.5-ZEC outputs (the value after the mining slow-start was completed) can be split into several logical funding streams (for background, see 3). Modifying the consensus rules to allocate the 2.5 ZEC across separate recipient addresses decouples these funding streams organizationally, legally, and operationally. It further reinforces transparency as to the structure of the original Founders' Reward.

+

Motivation for the Zcash Development Fund is considered in ZIP 1014 12.

+

This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.

+
+

Requirements

+

The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 12, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.

+

As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.

Specification

Definitions

-

We use the following constants and functions defined in 4:

+

We use the following constants and functions defined in 4, 5, and 6:

  • BlossomActivationHeight
  • PostBlossomHalvingInterval
  • Halving(height)
    • +
  • BlockSubsidy(height)
    • +
  • RedeemScriptHash(height).
-

We also define the following constants and functions:

+

We also define the following function:

    -
  • SlowStartShift as-defined in 2.
  • HeightForHalving(halving): Smallest height such that Halving(height) = halving

Funding streams

-

A funding stream is defined by a block reward fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).

-

By defining the issuance as a proportion of the total block issuance, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target times and issuance-per-block rates while maintaining an unchanged target-time-based issuance schedule. We anticipate such target-time / issuance rate changes in other ZIPs (for example, 4).

+

A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).

+

By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates, while maintaining an unchanged target-time-based issuance schedule. Such a target-time / issuance rate change occurred at the Blossom network upgrade, for example. 8

The value of a funding stream at a given block height is defined as:

FundingStream[FUND].Value(height) =
     floor((
-        BlockReward(height) * FundingStream[FUND].ValueNumerator
+        BlockSubsidy(height) * FundingStream[FUND].ValueNumerator
     ) / FundingStream[FUND].ValueDenominator)

An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height.

-

Each funding stream has an associated set of recipient addresses. Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:

+

Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.

+

Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:

AddressChangeInterval = PostBlossomHalvingInterval / 48
 AddressPeriod(height) =
     floor((
@@ -57,311 +75,116 @@
 Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex(height)]

This has the property that all active funding streams change the address they are using on the same block height schedule, aligned to the height of the first halving so that 48 funding periods fit cleanly within a halving interval. This can be leveraged to simplify implementations, by batching the necessary outputs for each funding period.

Below is a visual representation of how stream addresses align with funding periods:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Example heightStream AStream BStream C
AddressChangeInterval - 2A0
AddressChangeInterval - 1A0
AddressChangeIntervalA1B0C0
AddressChangeInterval + 1A1B0C0
...
2*AddressChangeInterval - 2A1B0C0
2*AddressChangeInterval - 1A1B0C0
2*AddressChangeIntervalA2C1
2*AddressChangeInterval + 1A2C1
...
PostBlossomHalvingInterval - 2A2C1
PostBlossomHalvingInterval - 1A2C1
PostBlossomHalvingIntervalC2
PostBlossomHalvingInterval + 1C2
-

Note that this is not intended to align with the end of a pre-Blossom Founders' Reward address period (as defined by FounderAddressChangeInterval in 5). There will be a shortened Founders' Reward address period prior to Blossom activation.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Example heightStream AStream BStream C
AddressChangeInterval - 2A0
AddressChangeInterval - 1A0
AddressChangeIntervalA1B0C0
AddressChangeInterval + 1A1B0C0
...
2*AddressChangeInterval - 2A1B0C0
2*AddressChangeInterval - 1A1B0C0
2*AddressChangeIntervalA2C1
2*AddressChangeInterval + 1A2C1
...
PostBlossomHalvingInterval - 2A2C1
PostBlossomHalvingInterval - 1A2C1
PostBlossomHalvingIntervalC2
PostBlossomHalvingInterval + 1C2
+
+

On Mainnet, ${NU4} is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to ${NU4} activation.

Consensus rules

-

Prior to activation of the Blossom network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 5

-

Once the Blossom network upgrade activates:

+

Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 6

+

Once the ${NU4} network upgrade activates:

    -
  • The existing consensus rule 5 is no longer active.
    • -
  • The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value to the stream's recipient address for the block's height.
    • -
-
-

Stream definitions

-

The consensus-defined funding streams described above each start at the Blossom activation height, and end at the first block reward halving. They are defined as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
StreamValue numeratorValue denominatorStart heightEnd height
FS 1340BlossomActivationHeightHeightForHalving(1)
FS 2125BlossomActivationHeightHeightForHalving(1)
FS 3140BlossomActivationHeightHeightForHalving(1)
FS 4150BlossomActivationHeightHeightForHalving(1)
FS 5180BlossomActivationHeightHeightForHalving(1)
FS 6180BlossomActivationHeightHeightForHalving(1)
FS 71100BlossomActivationHeightHeightForHalving(1)
FS 81200BlossomActivationHeightHeightForHalving(1)
-
    -
  • To-do: specify the correct values.
    • -
-

The sum of the block reward fractions for the above funding streams is 1/5, equal to the original Founders' Reward (as-defined by FoundersFraction in 6).

-

The sets of recipient addresses are defined as follows:

- 
std::vector<std::string> FS_1_ADDRESSES = [
-    "tFS1INVALIDADDRESS00",
-    "tFS1INVALIDADDRESS01",
-    "tFS1INVALIDADDRESS02",
-    "tFS1INVALIDADDRESS03",
-    "tFS1INVALIDADDRESS04",
-    "tFS1INVALIDADDRESS05",
-    "tFS1INVALIDADDRESS06",
-    "tFS1INVALIDADDRESS07",
-    "tFS1INVALIDADDRESS08",
-    "tFS1INVALIDADDRESS09",
-    "tFS1INVALIDADDRESS10",
-    "tFS1INVALIDADDRESS11",
-];
-
-std::vector<std::string> FS_2_ADDRESSES = [
-    "tFS2INVALIDADDRESS00",
-    "tFS2INVALIDADDRESS01",
-    "tFS2INVALIDADDRESS02",
-    "tFS2INVALIDADDRESS03",
-    "tFS2INVALIDADDRESS04",
-    "tFS2INVALIDADDRESS05",
-    "tFS2INVALIDADDRESS06",
-    "tFS2INVALIDADDRESS07",
-    "tFS2INVALIDADDRESS08",
-    "tFS2INVALIDADDRESS09",
-    "tFS2INVALIDADDRESS10",
-    "tFS2INVALIDADDRESS11",
-];
-
-std::vector<std::string> FS_3_ADDRESSES = [
-    "tFS3INVALIDADDRESS00",
-    "tFS3INVALIDADDRESS01",
-    "tFS3INVALIDADDRESS02",
-    "tFS3INVALIDADDRESS03",
-    "tFS3INVALIDADDRESS04",
-    "tFS3INVALIDADDRESS05",
-    "tFS3INVALIDADDRESS06",
-    "tFS3INVALIDADDRESS07",
-    "tFS3INVALIDADDRESS08",
-    "tFS3INVALIDADDRESS09",
-    "tFS3INVALIDADDRESS10",
-    "tFS3INVALIDADDRESS11",
-];
-
-std::vector<std::string> FS_4_ADDRESSES = [
-    "tFS4INVALIDADDRESS00",
-    "tFS4INVALIDADDRESS01",
-    "tFS4INVALIDADDRESS02",
-    "tFS4INVALIDADDRESS03",
-    "tFS4INVALIDADDRESS04",
-    "tFS4INVALIDADDRESS05",
-    "tFS4INVALIDADDRESS06",
-    "tFS4INVALIDADDRESS07",
-    "tFS4INVALIDADDRESS08",
-    "tFS4INVALIDADDRESS09",
-    "tFS4INVALIDADDRESS10",
-    "tFS4INVALIDADDRESS11",
-];
-
-std::vector<std::string> FS_5_ADDRESSES = [
-    "tFS5INVALIDADDRESS00",
-    "tFS5INVALIDADDRESS01",
-    "tFS5INVALIDADDRESS02",
-    "tFS5INVALIDADDRESS03",
-    "tFS5INVALIDADDRESS04",
-    "tFS5INVALIDADDRESS05",
-    "tFS5INVALIDADDRESS06",
-    "tFS5INVALIDADDRESS07",
-    "tFS5INVALIDADDRESS08",
-    "tFS5INVALIDADDRESS09",
-    "tFS5INVALIDADDRESS10",
-    "tFS5INVALIDADDRESS11",
-];
-
-std::vector<std::string> FS_6_ADDRESSES = [
-    "tFS6INVALIDADDRESS00",
-    "tFS6INVALIDADDRESS01",
-    "tFS6INVALIDADDRESS02",
-    "tFS6INVALIDADDRESS03",
-    "tFS6INVALIDADDRESS04",
-    "tFS6INVALIDADDRESS05",
-    "tFS6INVALIDADDRESS06",
-    "tFS6INVALIDADDRESS07",
-    "tFS6INVALIDADDRESS08",
-    "tFS6INVALIDADDRESS09",
-    "tFS6INVALIDADDRESS10",
-    "tFS6INVALIDADDRESS11",
-];
-
-std::vector<std::string> FS_7_ADDRESSES = [
-    "tFS7INVALIDADDRESS00",
-    "tFS7INVALIDADDRESS01",
-    "tFS7INVALIDADDRESS02",
-    "tFS7INVALIDADDRESS03",
-    "tFS7INVALIDADDRESS04",
-    "tFS7INVALIDADDRESS05",
-    "tFS7INVALIDADDRESS06",
-    "tFS7INVALIDADDRESS07",
-    "tFS7INVALIDADDRESS08",
-    "tFS7INVALIDADDRESS09",
-    "tFS7INVALIDADDRESS10",
-    "tFS7INVALIDADDRESS11",
-];
-
-std::vector<std::string> FS_8_ADDRESSES = [
-    "tFS8INVALIDADDRESS00",
-    "tFS8INVALIDADDRESS01",
-    "tFS8INVALIDADDRESS02",
-    "tFS8INVALIDADDRESS03",
-    "tFS8INVALIDADDRESS04",
-    "tFS8INVALIDADDRESS05",
-    "tFS8INVALIDADDRESS06",
-    "tFS8INVALIDADDRESS07",
-    "tFS8INVALIDADDRESS08",
-    "tFS8INVALIDADDRESS09",
-    "tFS8INVALIDADDRESS10",
-    "tFS8INVALIDADDRESS11",
-];
-
    -
  • To-do: specify the correct sets of FR addresses.
    • -
  • To-do: require that the FR address sets are PGP-signed with appropriate keys.
    • +
  • The existing consensus rule 6 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
    • +
  • The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.
    • +
  • The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form OP_HASH160 RedeemScriptHash(height) OP_EQUAL as the scriptPubKey.
    • +
  • The "prescribed way" to pay a Sapling address is as defined in 9. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.
+

For the funding stream definitions to be activated at ${NU4}, see ZIP 214. 10 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 7

Example implementation 

struct FundingPeriod {
@@ -373,14 +196,9 @@
 };
 
 enum FundingStream {
-    FS_1,
-    FS_2,
-    FS_3,
-    FS_4,
-    FS_5,
-    FS_6,
-    FS_7,
-    FS_8,
+    FS_ECC,
+    FS_ZF,
+    FS_MG,
     MAX_FUNDING_STREAMS,
 };
 
@@ -413,14 +231,9 @@
 
     consensus.nFundingPeriodLength = consensus.nSubsidyPostBlossomHalvingInterval / 48;
 
-    AddZIP207FundingStream(consensus, Consensus::FS_1, FS_1_ADDRESSES, 3, 40);
-    AddZIP207FundingStream(consensus, Consensus::FS_2, FS_2_ADDRESSES, 1, 25);
-    AddZIP207FundingStream(consensus, Consensus::FS_3, FS_3_ADDRESSES, 1, 40);
-    AddZIP207FundingStream(consensus, Consensus::FS_4, FS_4_ADDRESSES, 1, 50);
-    AddZIP207FundingStream(consensus, Consensus::FS_5, FS_5_ADDRESSES, 1, 80);
-    AddZIP207FundingStream(consensus, Consensus::FS_6, FS_6_ADDRESSES, 1, 80);
-    AddZIP207FundingStream(consensus, Consensus::FS_7, FS_7_ADDRESSES, 1, 100);
-    AddZIP207FundingStream(consensus, Consensus::FS_8, FS_8_ADDRESSES, 1, 200);
+    AddZIP207FundingStream(consensus, Consensus::FS_ECC, FS_ECC_ADDRESSES, 7, 100);
+    AddZIP207FundingStream(consensus, Consensus::FS_ZF,  FS_ZF_ADDRESSES,  5, 100);
+    AddZIP207FundingStream(consensus, Consensus::FS_MG,  FS_MG_ADDRESSES,  8, 100);
 
     ...
 }
@@ -476,7 +289,7 @@
 {
     ...
 
-    if (NetworkUpgradeActive(nHeight, consensusParams, Consensus::UPGRADE_BLOSSOM)) {
+    if (NetworkUpgradeActive(nHeight, consensusParams, Consensus::UPGRADE_NU4)) {
         // Coinbase transaction must include outputs corresponding to the consensus
         // funding streams active at the current block height.
         auto requiredStreams = GetActiveFundingStreams(nHeight, consensusParams);
@@ -491,14 +304,15 @@
         }
 
         if (!requiredStreams.empty()) {
-            return state.DoS(100, error("%s: funding stream missing", __func__), REJECT_INVALID, "cb-funding-stream-missing");
+            return state.DoS(100, error("%s: funding stream missing", __func__),
+                             REJECT_INVALID, "cb-funding-stream-missing");
         }
     } else {
         // Coinbase transaction must include an output sending 20% of
-        // the block reward to a founders reward script, until the last founders
+        // the block subsidy to a Founders' Reward script, until the last founders
         // reward block is reached, with exception of the genesis block.
-        // The last founders reward block is defined as the block just before the
-        // first subsidy halving block, which occurs at halving_interval + slow_start_shift
+        // The last Founders' Reward block is defined as the block just before the
+        // first subsidy halving block.
         if ((nHeight > 0) && (nHeight <= consensusParams.GetLastFoundersRewardBlockHeight())) {
             bool found = false;
 
@@ -512,7 +326,8 @@
             }
 
             if (!found) {
-                return state.DoS(100, error("%s: founders reward missing", __func__), REJECT_INVALID, "cb-no-founders-reward");
+                return state.DoS(100, error("%s: founders reward missing", __func__),
+                                 REJECT_INVALID, "cb-no-founders-reward");
             }
         }
     }
@@ -522,15 +337,10 @@

Deployment

-

This proposal was originally intended to be deployed with the Blossom network upgrade. 7

+

This proposal is intended to be deployed with ${NU4}. 11

Backward compatibility

This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists.

-

This proposal is designed with the explicit requirement of not altering the overall issuance schedule (based on time), nor does it alter the proportion or timeline of the overall Founders' Reward. As a result, no users outside of the Zerocoin Electric Coin Company and Zcash Foundation should experience any UX or economic change outside of the upgrade due to this proposal itself.

-

Interactions with other ZIPs

-

4 (Shorter Block Target Spacing) specifies a change to the block target spacing. It is planned to take effect in the Blossom network upgrade 7. This ZIP was originally written to take effect at the same time, but was Withdrawn from consideration for Blossom.

-

ZIP 208 modifies the payment of the original Founders' Reward to take account of the block target spacing change. It does this by specifying a FounderAddressAdjustedHeight function and related changes, which would need to be revisited to take into account funding streams.

-

Reference Implementation

TBC

@@ -544,51 +354,91 @@ - +
- +
2Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]Zcash Protocol Specification, Version 2020.1.1 or later
- +
- +
3Continued Funding and TransparencySection 3.9: Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later
- +
- +
4ZIP 208: Shorter Block Target SpacingSection 5.3: Constants. Zcash Protocol Specification, Version 2020.1.1 or later
- +
- +
5Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later
- +
- +
6Section 5.3: Constants. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling]Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later
- +
- + + + +
7ZIP 206: Blossom Network UpgradeZIP 0: ZIP Process
+ + + + + + + +
8ZIP 208: Shorter Block Target Spacing
+ + + + + + + +
9ZIP 213: Shielded Coinbase
+ + + + + + + +
10ZIP 214: Consensus rules for a Zcash Development Fund
+ + + + + + + +
11ZIP 251: Deployment of the ${NU4} Network Upgrade
+ + + + +
12ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
diff --git a/zip-0207.rst b/zip-0207.rst index 545c9587d..93d202a04 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -1,10 +1,11 @@ :: ZIP: 207 - Title: Split Founders' Reward + Title: Funding Streams Owners: Jack Grigg + Daira Hopwood Category: Consensus - Status: Withdrawn + Status: Draft Created: 2019-01-04 License: MIT @@ -15,26 +16,59 @@ Terminology The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ +The terms "block subsidy" and "halving" in this document are to be interpreted +as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. +[#protocol-subsidyconcepts]_ [#protocol-subsidies]_ + +The terms below are to be interpreted as follows: + +${NU4} + Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4. +Testnet + The Zcash test network, as defined in the Zcash Protocol Specification. [#protocol]_ +Mainnet + The Zcash production network, as defined in the Zcash Protocol Specification. [#protocol]_ + Abstract ======== -This Withdrawn proposal would have altered consensus rules to split the original Founders' Reward across -several recipient addresses per block instead of one, corresponding to the several funding streams contained -within it. +This proposal specifies a mechanism to support funding streams, distributed +from a portion of the block subsidy for a specified range of block heights. + +This is intended as a means of implementing the Zcash Development Fund, +using the funding stream definitions specified in ZIP 214 [#zip-0214]_. It +should be read in conjunction with ZIP 1014 [#zip-1014]_, which describes +the high-level requirements for that fund. Motivation ========== -Since the launch of the Zcash network, the consensus rules have required that until the first block reward -halving (at block 850,000), each block must send 20% of the block subsidy to a hard-coded transparent address. -[#block-subsidy]_ This funding stream is referred to as the Founders' Reward. +Motivation for the Zcash Development Fund is considered in ZIP 1014 [#zip-1014]_. + +This ZIP 207 was originally proposed for the Blossom network upgrade, as a +means of splitting the original Founders' Reward into several streams. It was +then withdrawn when such splitting was judged to be unnecessary at the consensus +level. Since the capabilities of the funding stream mechanism match the +requirements for the Zcash Development Fund, the ZIP is being reintroduced +for that purpose in order to reuse specification, analysis, and implementation +effort. + -This stream of 2.5-ZEC outputs (the value after the mining slow-start was completed) can be split into several -logical funding streams (for background, see [#continued-funding]_). Modifying the consensus rules to allocate -the 2.5 ZEC across separate recipient addresses decouples these funding streams organizationally, legally, and -operationally. It further reinforces transparency as to the structure of the original Founders' Reward. +Requirements +============ + +The primary requirement of this ZIP is to provide a mechanism for specifying +the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash +Development Fund. It should be sufficiently expressive to handle both the main +three "slices" (ECC, ZF, and MG) defined in ZIP 1014 [#zip-1014]_, and also +(with additional funding stream definitions) the "direct grant option" described +in that ZIP. + +As for the original Founders' Reward, addresses for a given funding stream are +changed on a roughly-monthly basis, so that keys that are not yet needed may be +kept off-line as a security measure. Specification @@ -43,42 +77,48 @@ Specification Definitions ----------- -We use the following constants and functions defined in [#zip-0208]_: +We use the following constants and functions defined in [#protocol-constants]_, +[#protocol-subsidies]_, and [#protocol-foundersreward]_: - ``BlossomActivationHeight`` - ``PostBlossomHalvingInterval`` - ``Halving(height)`` +- ``BlockSubsidy(height)`` +- ``RedeemScriptHash(height)``. + +We also define the following function: -We also define the following constants and functions: +- ``HeightForHalving(halving)``: Smallest ``height`` such that + ``Halving(height) = halving`` -- ``SlowStartShift`` as-defined in [#block-subsidy]_. -- ``HeightForHalving(halving)``: Smallest ``height`` such that ``Halving(height) = halving`` Funding streams --------------- -A funding stream is defined by a block reward fraction (represented as a +A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive). -By defining the issuance as a proportion of the total block issuance, rather +By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block -target times and issuance-per-block rates while maintaining an unchanged -target-time-based issuance schedule. We anticipate such target-time / issuance -rate changes in other ZIPs (for example, [#zip-0208]_). +target spacing and issuance-per-block rates, while maintaining an unchanged +target-time-based issuance schedule. Such a target-time / issuance rate change +occurred at the Blossom network upgrade, for example. [#zip-0208]_ The value of a funding stream at a given block height is defined as:: FundingStream[FUND].Value(height) = floor(( - BlockReward(height) * FundingStream[FUND].ValueNumerator + BlockSubsidy(height) * FundingStream[FUND].ValueNumerator ) / FundingStream[FUND].ValueDenominator) An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height. -Each funding stream has an associated set of recipient addresses. +Each funding stream has an associated sequence of recipient addresses, +each of which MUST be either a transparent P2SH address or a Sapling address. + Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:: @@ -101,193 +141,59 @@ necessary outputs for each funding period. Below is a visual representation of how stream addresses align with funding periods: -================================== ======== ======== ======== - Example height Stream A Stream B Stream C -================================== ======== ======== ======== - ``AddressChangeInterval - 2`` A0 - ``AddressChangeInterval - 1`` A0 - ``AddressChangeInterval`` A1 B0 C0 - ``AddressChangeInterval + 1`` A1 B0 C0 - \... - ``2*AddressChangeInterval - 2`` A1 B0 C0 - ``2*AddressChangeInterval - 1`` A1 B0 C0 - ``2*AddressChangeInterval`` A2 C1 - ``2*AddressChangeInterval + 1`` A2 C1 - \... -``PostBlossomHalvingInterval - 2`` A2 C1 -``PostBlossomHalvingInterval - 1`` A2 C1 -``PostBlossomHalvingInterval`` C2 -``PostBlossomHalvingInterval + 1`` C2 -================================== ======== ======== ======== - -Note that this is not intended to align with the end of a pre-Blossom Founders' Reward address period (as -defined by ``FounderAddressChangeInterval`` in [#original-fr-consensus-rule]_). There will be a shortened -Founders' Reward address period prior to Blossom activation. + ================================== ======== ======== ======== + Example height Stream A Stream B Stream C + ================================== ======== ======== ======== + ``AddressChangeInterval - 2`` A0 + ``AddressChangeInterval - 1`` A0 + ``AddressChangeInterval`` A1 B0 C0 + ``AddressChangeInterval + 1`` A1 B0 C0 + \... + ``2*AddressChangeInterval - 2`` A1 B0 C0 + ``2*AddressChangeInterval - 1`` A1 B0 C0 + ``2*AddressChangeInterval`` A2 C1 + ``2*AddressChangeInterval + 1`` A2 C1 + \... + ``PostBlossomHalvingInterval - 2`` A2 C1 + ``PostBlossomHalvingInterval - 1`` A2 C1 + ``PostBlossomHalvingInterval`` C2 + ``PostBlossomHalvingInterval + 1`` C2 + ================================== ======== ======== ======== + +On Mainnet, ${NU4} is planned to activate exactly at the point when the Founders' +Reward expires, at block height 1046400. On Testnet, there will be a shortened +Founders' Reward address period prior to ${NU4} activation. + Consensus rules --------------- -Prior to activation of the Blossom network upgrade, the existing consensus rule -for payment of the original Founders' Reward is enforced. [#original-fr-consensus-rule]_ +Prior to activation of the ${NU4} network upgrade, the existing consensus rule +for payment of the original Founders' Reward is enforced. [#protocol-foundersreward]_ -Once the Blossom network upgrade activates: +Once the ${NU4} network upgrade activates: -- The existing consensus rule [#original-fr-consensus-rule]_ is no longer - active. -- The coinbase transaction in each block MUST contain at least one output per - active funding stream that pays the stream's value to the stream's recipient - address for the block's height. - -Stream definitions ------------------- - -The consensus-defined funding streams described above each start at the Blossom activation height, and end at -the first block reward halving. They are defined as follows: +- The existing consensus rule [#protocol-foundersreward]_ is no longer active. + (This would be the case under the preexisting consensus rules for Mainnet, but + not for Testnet.) -====== =============== ================= =========================== ======================= -Stream Value numerator Value denominator Start height End height -====== =============== ================= =========================== ======================= - FS 1 3 40 ``BlossomActivationHeight`` ``HeightForHalving(1)`` - FS 2 1 25 ``BlossomActivationHeight`` ``HeightForHalving(1)`` - FS 3 1 40 ``BlossomActivationHeight`` ``HeightForHalving(1)`` - FS 4 1 50 ``BlossomActivationHeight`` ``HeightForHalving(1)`` - FS 5 1 80 ``BlossomActivationHeight`` ``HeightForHalving(1)`` - FS 6 1 80 ``BlossomActivationHeight`` ``HeightForHalving(1)`` - FS 7 1 100 ``BlossomActivationHeight`` ``HeightForHalving(1)`` - FS 8 1 200 ``BlossomActivationHeight`` ``HeightForHalving(1)`` -====== =============== ================= =========================== ======================= - -- To-do: specify the correct values. +- The coinbase transaction in each block MUST contain at least one output per + active funding stream that pays the stream's value in the prescribed way to + the stream's recipient address for the block's height. -The sum of the block reward fractions for the above funding streams is ``1/5``, equal to the original -Founders' Reward (as-defined by ``FoundersFraction`` in [#protocol-constants]_). +- The "prescribed way" to pay a transparent P2SH address is to use a standard + P2SH script of the form ``OP_HASH160 RedeemScriptHash(height) OP_EQUAL`` as + the ``scriptPubKey``. -The sets of recipient addresses are defined as follows: +- The "prescribed way" to pay a Sapling address is as defined in [#zip-0213]_. + That is, all Sapling outputs in coinbase transactions (including, but not + limited to, outputs for funding streams) MUST have valid note commitments + when recovered using a 32-byte array of zeroes as the outgoing viewing key. -.. code:: cpp +For the funding stream definitions to be activated at ${NU4}, see ZIP 214. [#zip-0214]_ +Funding stream definitions can be added, changed, or deleted in ZIPs associated +with subsequent network upgrades, subject to the ZIP process. [#zip-0000]_ - std::vector FS_1_ADDRESSES = [ - "tFS1INVALIDADDRESS00", - "tFS1INVALIDADDRESS01", - "tFS1INVALIDADDRESS02", - "tFS1INVALIDADDRESS03", - "tFS1INVALIDADDRESS04", - "tFS1INVALIDADDRESS05", - "tFS1INVALIDADDRESS06", - "tFS1INVALIDADDRESS07", - "tFS1INVALIDADDRESS08", - "tFS1INVALIDADDRESS09", - "tFS1INVALIDADDRESS10", - "tFS1INVALIDADDRESS11", - ]; - - std::vector FS_2_ADDRESSES = [ - "tFS2INVALIDADDRESS00", - "tFS2INVALIDADDRESS01", - "tFS2INVALIDADDRESS02", - "tFS2INVALIDADDRESS03", - "tFS2INVALIDADDRESS04", - "tFS2INVALIDADDRESS05", - "tFS2INVALIDADDRESS06", - "tFS2INVALIDADDRESS07", - "tFS2INVALIDADDRESS08", - "tFS2INVALIDADDRESS09", - "tFS2INVALIDADDRESS10", - "tFS2INVALIDADDRESS11", - ]; - - std::vector FS_3_ADDRESSES = [ - "tFS3INVALIDADDRESS00", - "tFS3INVALIDADDRESS01", - "tFS3INVALIDADDRESS02", - "tFS3INVALIDADDRESS03", - "tFS3INVALIDADDRESS04", - "tFS3INVALIDADDRESS05", - "tFS3INVALIDADDRESS06", - "tFS3INVALIDADDRESS07", - "tFS3INVALIDADDRESS08", - "tFS3INVALIDADDRESS09", - "tFS3INVALIDADDRESS10", - "tFS3INVALIDADDRESS11", - ]; - - std::vector FS_4_ADDRESSES = [ - "tFS4INVALIDADDRESS00", - "tFS4INVALIDADDRESS01", - "tFS4INVALIDADDRESS02", - "tFS4INVALIDADDRESS03", - "tFS4INVALIDADDRESS04", - "tFS4INVALIDADDRESS05", - "tFS4INVALIDADDRESS06", - "tFS4INVALIDADDRESS07", - "tFS4INVALIDADDRESS08", - "tFS4INVALIDADDRESS09", - "tFS4INVALIDADDRESS10", - "tFS4INVALIDADDRESS11", - ]; - - std::vector FS_5_ADDRESSES = [ - "tFS5INVALIDADDRESS00", - "tFS5INVALIDADDRESS01", - "tFS5INVALIDADDRESS02", - "tFS5INVALIDADDRESS03", - "tFS5INVALIDADDRESS04", - "tFS5INVALIDADDRESS05", - "tFS5INVALIDADDRESS06", - "tFS5INVALIDADDRESS07", - "tFS5INVALIDADDRESS08", - "tFS5INVALIDADDRESS09", - "tFS5INVALIDADDRESS10", - "tFS5INVALIDADDRESS11", - ]; - - std::vector FS_6_ADDRESSES = [ - "tFS6INVALIDADDRESS00", - "tFS6INVALIDADDRESS01", - "tFS6INVALIDADDRESS02", - "tFS6INVALIDADDRESS03", - "tFS6INVALIDADDRESS04", - "tFS6INVALIDADDRESS05", - "tFS6INVALIDADDRESS06", - "tFS6INVALIDADDRESS07", - "tFS6INVALIDADDRESS08", - "tFS6INVALIDADDRESS09", - "tFS6INVALIDADDRESS10", - "tFS6INVALIDADDRESS11", - ]; - - std::vector FS_7_ADDRESSES = [ - "tFS7INVALIDADDRESS00", - "tFS7INVALIDADDRESS01", - "tFS7INVALIDADDRESS02", - "tFS7INVALIDADDRESS03", - "tFS7INVALIDADDRESS04", - "tFS7INVALIDADDRESS05", - "tFS7INVALIDADDRESS06", - "tFS7INVALIDADDRESS07", - "tFS7INVALIDADDRESS08", - "tFS7INVALIDADDRESS09", - "tFS7INVALIDADDRESS10", - "tFS7INVALIDADDRESS11", - ]; - - std::vector FS_8_ADDRESSES = [ - "tFS8INVALIDADDRESS00", - "tFS8INVALIDADDRESS01", - "tFS8INVALIDADDRESS02", - "tFS8INVALIDADDRESS03", - "tFS8INVALIDADDRESS04", - "tFS8INVALIDADDRESS05", - "tFS8INVALIDADDRESS06", - "tFS8INVALIDADDRESS07", - "tFS8INVALIDADDRESS08", - "tFS8INVALIDADDRESS09", - "tFS8INVALIDADDRESS10", - "tFS8INVALIDADDRESS11", - ]; - -- To-do: specify the correct sets of FR addresses. -- To-do: require that the FR address sets are PGP-signed with appropriate keys. Example implementation ---------------------- @@ -303,14 +209,9 @@ Example implementation }; enum FundingStream { - FS_1, - FS_2, - FS_3, - FS_4, - FS_5, - FS_6, - FS_7, - FS_8, + FS_ECC, + FS_ZF, + FS_MG, MAX_FUNDING_STREAMS, }; @@ -343,14 +244,9 @@ Example implementation consensus.nFundingPeriodLength = consensus.nSubsidyPostBlossomHalvingInterval / 48; - AddZIP207FundingStream(consensus, Consensus::FS_1, FS_1_ADDRESSES, 3, 40); - AddZIP207FundingStream(consensus, Consensus::FS_2, FS_2_ADDRESSES, 1, 25); - AddZIP207FundingStream(consensus, Consensus::FS_3, FS_3_ADDRESSES, 1, 40); - AddZIP207FundingStream(consensus, Consensus::FS_4, FS_4_ADDRESSES, 1, 50); - AddZIP207FundingStream(consensus, Consensus::FS_5, FS_5_ADDRESSES, 1, 80); - AddZIP207FundingStream(consensus, Consensus::FS_6, FS_6_ADDRESSES, 1, 80); - AddZIP207FundingStream(consensus, Consensus::FS_7, FS_7_ADDRESSES, 1, 100); - AddZIP207FundingStream(consensus, Consensus::FS_8, FS_8_ADDRESSES, 1, 200); + AddZIP207FundingStream(consensus, Consensus::FS_ECC, FS_ECC_ADDRESSES, 7, 100); + AddZIP207FundingStream(consensus, Consensus::FS_ZF, FS_ZF_ADDRESSES, 5, 100); + AddZIP207FundingStream(consensus, Consensus::FS_MG, FS_MG_ADDRESSES, 8, 100); ... } @@ -406,7 +302,7 @@ Example implementation { ... - if (NetworkUpgradeActive(nHeight, consensusParams, Consensus::UPGRADE_BLOSSOM)) { + if (NetworkUpgradeActive(nHeight, consensusParams, Consensus::UPGRADE_NU4)) { // Coinbase transaction must include outputs corresponding to the consensus // funding streams active at the current block height. auto requiredStreams = GetActiveFundingStreams(nHeight, consensusParams); @@ -421,14 +317,15 @@ Example implementation } if (!requiredStreams.empty()) { - return state.DoS(100, error("%s: funding stream missing", __func__), REJECT_INVALID, "cb-funding-stream-missing"); + return state.DoS(100, error("%s: funding stream missing", __func__), + REJECT_INVALID, "cb-funding-stream-missing"); } } else { // Coinbase transaction must include an output sending 20% of - // the block reward to a founders reward script, until the last founders + // the block subsidy to a Founders' Reward script, until the last founders // reward block is reached, with exception of the genesis block. - // The last founders reward block is defined as the block just before the - // first subsidy halving block, which occurs at halving_interval + slow_start_shift + // The last Founders' Reward block is defined as the block just before the + // first subsidy halving block. if ((nHeight > 0) && (nHeight <= consensusParams.GetLastFoundersRewardBlockHeight())) { bool found = false; @@ -442,7 +339,8 @@ Example implementation } if (!found) { - return state.DoS(100, error("%s: founders reward missing", __func__), REJECT_INVALID, "cb-no-founders-reward"); + return state.DoS(100, error("%s: founders reward missing", __func__), + REJECT_INVALID, "cb-no-founders-reward"); } } } @@ -454,7 +352,7 @@ Example implementation Deployment ========== -This proposal was originally intended to be deployed with the Blossom network upgrade. [#zip-0206]_ +This proposal is intended to be deployed with ${NU4}. [#zip-0251]_ Backward compatibility @@ -466,23 +364,6 @@ upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists. -This proposal is designed with the explicit requirement of not altering the overall issuance schedule (based -on time), nor does it alter the proportion or timeline of the overall Founders' Reward. As a result, no users -outside of the Zerocoin Electric Coin Company and Zcash Foundation should experience any UX or economic change -outside of the upgrade due to this proposal itself. - - -Interactions with other ZIPs ----------------------------- - -[#zip-0208]_ (Shorter Block Target Spacing) specifies a change to the block target spacing. It is planned -to take effect in the Blossom network upgrade [#zip-0206]_. This ZIP was originally written to take effect -at the same time, but was Withdrawn from consideration for Blossom. - -ZIP 208 modifies the payment of the original Founders' Reward to take account of the block target spacing -change. It does this by specifying a FounderAddressAdjustedHeight function and related changes, which would -need to be revisited to take into account funding streams. - Reference Implementation ======================== @@ -494,9 +375,14 @@ References ========== .. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#block-subsidy] `Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] `_ -.. [#continued-funding] `Continued Funding and Transparency `_ +.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later `_ +.. [#protocol-subsidyconcepts] `Section 3.9: Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later `_ +.. [#protocol-constants] `Section 5.3: Constants. Zcash Protocol Specification, Version 2020.1.1 or later `_ +.. [#protocol-subsidies] `Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later `_ +.. [#protocol-foundersreward] `Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later `_ +.. [#zip-0000] `ZIP 0: ZIP Process `_ .. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ -.. [#original-fr-consensus-rule] `Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] `_ -.. [#protocol-constants] `Section 5.3: Constants. Zcash Protocol Specification, Version 2018.0-beta-33 or later [Overwinter+Sapling] `_ -.. [#zip-0206] `ZIP 206: Blossom Network Upgrade `_ +.. [#zip-0213] `ZIP 213: Shielded Coinbase `_ +.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund `_ +.. [#zip-0251] `ZIP 251: Deployment of the ${NU4} Network Upgrade `_ +.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_ From 6526ebb0881eccece6ff8e789efc233f1dd6fbb8 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 10 Mar 2020 21:49:50 +0000 Subject: [PATCH 03/26] Add ZIPs 214 and 251. Signed-off-by: Daira Hopwood --- README.rst | 2 + index.html | 2 + zip-0214.html | 198 ++++++++++++++++++++++++++++++ zip-0214.rst | 327 ++++++++++++++++++++++++++++++++++++++++++++++++++ zip-0251.html | 135 +++++++++++++++++++++ zip-0251.rst | 134 +++++++++++++++++++++ 6 files changed, 798 insertions(+) create mode 100644 zip-0214.html create mode 100644 zip-0214.rst create mode 100644 zip-0251.html create mode 100644 zip-0251.rst diff --git a/README.rst b/README.rst index 7211ee6d2..d377de233 100644 --- a/README.rst +++ b/README.rst @@ -62,9 +62,11 @@ Index of ZIPs 209 Prohibit Negative Shielded Value Pool Final 210 Sapling Anchor Deduplication within Transactions Draft 213 Shielded Coinbase Implemented (zcashd) + 214 Consensus rules for a Zcash Development Fund Draft 221 FlyClient - Consensus-Layer Changes Proposed 243 Transaction Signature Verification for Sapling Final 250 Deployment of the Heartwood Network Upgrade Draft + 251 Deployment of the ${NU4} Network Upgrade Draft 308 Sprout to Sapling Migration Final 310 Security Properties of Sapling Viewing Keys Draft 401 Addressing mempool denial-of-service Final diff --git a/index.html b/index.html index 8ab8fe379..6da551a04 100644 --- a/index.html +++ b/index.html @@ -41,9 +41,11 @@ 209 Prohibit Negative Shielded Value Pool Final 210 Sapling Anchor Deduplication within Transactions Draft 213 Shielded Coinbase Implemented (zcashd) + 214 Consensus rules for a Zcash Development Fund Draft 221 FlyClient - Consensus-Layer Changes Proposed 243 Transaction Signature Verification for Sapling Final 250 Deployment of the Heartwood Network Upgrade Draft + 251 Deployment of the ${NU4} Network Upgrade Draft 308 Sprout to Sapling Migration Final 310 Security Properties of Sapling Viewing Keys Draft 401 Addressing mempool denial-of-service Final diff --git a/zip-0214.html b/zip-0214.html new file mode 100644 index 000000000..6ea7b69cf --- /dev/null +++ b/zip-0214.html @@ -0,0 +1,198 @@ + + + + ZIP 214: Consensus rules for a Zcash Development Fund + + + +
+ 
ZIP: 214
+Title: Consensus rules for a Zcash Development Fund
+Owners: Daira Hopwood <daira@electriccoin.co>
+Status: Draft
+Category: Consensus
+Created: 2020-02-28
+License: MIT
+Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>
+

Terminology

+

The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" 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 5 and the Zcash Trademark Donation and License Agreement (3 or successor agreement).

+

The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 2

+

The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 9.

+

The terms below are to be interpreted as follows:

+
+
${NU4}
+
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
+
Testnet
+
The Zcash test network, as defined in 2.
+
Mainnet
+
The Zcash production network, as defined in 2.
+
+
+

Abstract

+

This ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

+
+

Motivation

+

Motivation for the Zcash Development Fund itself is considered in ZIP 1014 9, which gives a high-level description of the intended structure of the fund.

+

An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.

+
+

Requirements

+

The primary requirement of this ZIP is to make changes to consensus rules necessary and sufficient to implement the intent of ZIP 1014.

+

The Zcash Development Fund distributes funding in ZEC obtained from block subsidies on Mainnet. This ZIP should also specify corresponding rules, addresses, and activation height for Testnet, in order to allow testing and auditing of the design and implementation within sufficient lead time before activation on Mainnet.

+
+

Non-requirements

+

This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.

+
+

Specification

+

The Blossom network upgrade changed the height of the first halving to block height 1046400 7, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.

+

Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of ${NU4} on Mainnet therefore SHALL be 1046400.

+

ZIP 207 6 SHALL be activated in ${NU4}.

+

The following funding streams are defined for Mainnet:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StreamNumeratorDenominatorStart heightEnd height
FS_ECC710010464002726400
FS_ZF510010464002726400
FS_MG810010464002726400
+
+

The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of ${NU4} on Testnet, i.e. xxxxxxx.

+

Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the corresponding initial amount on Mainnet. This reduces to the same amount as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).

+

Dev Fund Recipient Addresses

+

For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of independent recipient addresses to be used for each stream in each funding period:

+
    +
  • ECC SHALL generate the addresses for the FS_ECC funding stream, which on Mainnet corresponds to the ECC slice;
    • +
  • ZF SHALL generate the addresses for the FS_ZF and FS_MG funding streams, which on Mainnet correspond to the ZF slice and MG slice respectively.
    • +
+

Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 9.

+

No requirements are imposed on the use of funds sent to Testnet funding streams.

+

Direct-grant option

+

ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before ${NU4} activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 9

+

The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total amount of funding streams assigned to direct grantees MUST be subtracted from the funding stream for the remaining MG slice (or, if all Major Grants are direct, replace the funding stream for the MG slice).

+

For each network upgrade after ${NU4} requiring modifications to the set of direct grantees, a separate ZIP would be published specifying those modifications.

+
+
+

Mainnet Recipient Addresses

+
+
+
FS_ECC_Addresses[0..47] = [
+
"TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO" ]
+
FS_ZF_Addresses[0..47] = [
+
"TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO" ]
+
FS_MG_Addresses[0..47] = [
+
"TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO" ]
+
+
+
+

Testnet Recipient Addresses

+

TODO

+
+
+

Deployment

+

This proposal is intended to be deployed with ${NU4}. 8

+
+

References

+ + + + + + + +
1Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2Zcash Protocol Specification [Overwinter+Sapling+Blossom]
+ + + + + + + +
3Zcash Trademark Donation and License Agreement
+ + + + + + + +
4The Open Source Definition
+ + + + + + + +
5ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
6ZIP 207: Funding Streams
+ + + + + + + +
7ZIP 208: Shorter Block Target Spacing
+ + + + + + + +
8ZIP 251: Deployment of the ${NU4} Network Upgrade
+ + + + + + + +
9ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
+
+
+ + \ No newline at end of file diff --git a/zip-0214.rst b/zip-0214.rst new file mode 100644 index 000000000..236f5bfb0 --- /dev/null +++ b/zip-0214.rst @@ -0,0 +1,327 @@ +:: + + ZIP: 214 + Title: Consensus rules for a Zcash Development Fund + Owners: Daira Hopwood + Status: Draft + Category: Consensus + Created: 2020-02-28 + License: MIT + Discussions-To: + + +Terminology +=========== + +The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" +in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ + +The term "network upgrade" in this document is to be interpreted as +described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License +Agreement ([#trademark]_ or successor agreement). + +The terms "block subsidy" and "halving" in this document are to be interpreted +as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. +[#protocol]_ + +The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), +"Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to +be interpreted as described in ZIP 1014 [#zip-1014]_. + +The terms below are to be interpreted as follows: + +${NU4} + Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4. +Testnet + The Zcash test network, as defined in [#protocol]_. +Mainnet + The Zcash production network, as defined in [#protocol]_. + + +Abstract +======== + +This ZIP describes consensus rule changes interpreting the proposed structure of +the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last +for 4 years. + + +Motivation +========== + +Motivation for the Zcash Development Fund itself is considered in ZIP 1014 +[#zip-1014]_, which gives a high-level description of the intended structure of +the fund. + +An important motivation for describing the consensus rules in a separate ZIP is +to avoid making unintended changes to ZIP 1014, which has already been agreed +between ECC, ZF, and the Zcash community. This facilitates critically assessing +whether the consensus rule changes accurately reflect the intent of ZIP 1014. + + +Requirements +============ + +The primary requirement of this ZIP is to make changes to consensus rules necessary +and sufficient to implement the intent of ZIP 1014. + +The Zcash Development Fund distributes funding in ZEC obtained from block subsidies +on Mainnet. This ZIP should also specify corresponding rules, addresses, and +activation height for Testnet, in order to allow testing and auditing of the design +and implementation within sufficient lead time before activation on Mainnet. + + +Non-requirements +================ + +This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what +is implementable by Zcash consensus rules. + + +Specification +============= + +The Blossom network upgrade changed the height of the first halving to block height +1046400 [#zip-0208]_, as a consequence of reducing the block target spacing from +150 seconds to 75 seconds. + +Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, +the activation height of ${NU4} on Mainnet therefore SHALL be 1046400. + +ZIP 207 [#zip-0207]_ SHALL be activated in ${NU4}. + +The following funding streams are defined for Mainnet: + + ========== =========== ============= ============== ============ + Stream Numerator Denominator Start height End height + ========== =========== ============= ============== ============ + ``FS_ECC`` 7 100 1046400 2726400 + ``FS_ZF`` 5 100 1046400 2726400 + ``FS_MG`` 8 100 1046400 2726400 + ========== =========== ============= ============== ============ + +The funding streams are defined for Testnet are identical except that the +start height of each stream is the activation height of ${NU4} on Testnet, i.e. +xxxxxxx. + +Note: on Testnet, the activation height of ${NU4} will be before the first halving. +Therefore, the consequence of the above rules for Testnet is that the amount sent +to each Zcash Development Fund recipient address will initially (before Testnet +block height 1046400) be double the corresponding initial amount on Mainnet. This +reduces to the same amount as on Mainnet, from Testnet block heights 1046400 +(inclusive) to 2726400 (exclusive). + + +Dev Fund Recipient Addresses +---------------------------- + +For each of Testnet and Mainnet, before deploying this ZIP in a node implementation +with the activation height set for that network, each of the parties (ECC and ZF) +SHALL generate sequences of independent recipient addresses to be used for each +stream in each funding period: + +* ECC SHALL generate the addresses for the ``FS_ECC`` funding stream, which on + Mainnet corresponds to the **ECC slice**; +* ZF SHALL generate the addresses for the ``FS_ZF`` and ``FS_MG`` funding streams, + which on Mainnet correspond to the **ZF slice** and **MG slice** respectively. + +Funds sent to each Mainnet funding stream SHALL be governed by all requirements on +the corresponding slice specified in ZIP 1014 [#zip-1014]_. + +No requirements are imposed on the use of funds sent to Testnet funding streams. + + +Direct-grant option +''''''''''''''''''' + +ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC +and ZF before ${NU4} activation, some portion of the **MG slice** may be directly +assigned to the grantee(s), rather than accepted and disbursed by ZF. [#zip-1014]_ + +The funding stream mechanism allows for this option by adding a funding stream +corresponding to each direct grantee, with addresses generated by ZF. In this case +the total amount of funding streams assigned to direct grantees MUST be subtracted +from the funding stream for the remaining **MG slice** (or, if all Major Grants are +direct, replace the funding stream for the **MG slice**). + +For each network upgrade after ${NU4} requiring modifications to the set of direct +grantees, a separate ZIP would be published specifying those modifications. + + +Mainnet Recipient Addresses +--------------------------- + + FS_ECC_Addresses[0..47] = [ + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO" ] + + FS_ZF_Addresses[0..47] = [ + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO" ] + + FS_MG_Addresses[0..47] = [ + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO", + "TODO" ] + +Testnet Recipient Addresses +--------------------------- + +TODO + + +Deployment +========== + +This proposal is intended to be deployed with ${NU4}. [#zip-0251]_ + + +References +========== + +.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling+Blossom] `_ +.. [#trademark] `Zcash Trademark Donation and License Agreement `_ +.. [#osd] `The Open Source Definition `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zip-0207] `ZIP 207: Funding Streams `_ +.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ +.. [#zip-0251] `ZIP 251: Deployment of the ${NU4} Network Upgrade `_ +.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_ diff --git a/zip-0251.html b/zip-0251.html new file mode 100644 index 000000000..071982729 --- /dev/null +++ b/zip-0251.html @@ -0,0 +1,135 @@ + + + + ZIP 251: Deployment of the Network Upgrade + + + +
+ 
ZIP: 251
+Title: Deployment of the ${NU4} Network Upgrade
+Owners: Daira Hopwood <daira@electriccoin.co>
+Status: Draft
+Category: Consensus
+Created: 2020-02-28
+License: MIT
+

Terminology

+

The key words "MUST", "MUST NOT", "SHOULD", and "MAY" 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. 3

+

The terms below are to be interpreted as follows:

+
+
${NU4}
+
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
+
Testnet
+
The Zcash test network, as defined in 2.
+
Mainnet
+
The Zcash production network, as defined in 2.
+
+
+

Abstract

+

This proposal defines the deployment of the ${NU4} network upgrade.

+
+

Specification

+

${NU4} deployment

+

The primary sources of information about ${NU4} consensus protocol changes are:

+
    +
  • The Zcash Protocol Specification 2
    • +
  • ZIP 200: Network Upgrade Mechanism 3
    • +
  • ZIP 207: Funding Streams 5
    • +
  • ZIP 214: Consensus rules for a Zcash Development Fund 6
    • +
  • ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants 7
    • +
  • TODO: other ZIPs
    • +
+

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 ${NU4} upgrade:

+
+
BRANCH_ID
+
0xTODO
+
ACTIVATION_HEIGHT (${NU4})
+
+

Testnet: TODO

+

Mainnet: 1046400

+
+
+

Nodes compatible with ${NU4} activation on testnet MUST advertise protocol version TODO or later. Nodes compatible with ${NU4} activation on mainnet MUST advertise protocol version TODO or later. The minimum peer protocol version that ${NU4}-compatible nodes will connect to is 170002.

+

Pre-${NU4} testnet nodes are defined as nodes on testnet advertising a protocol version less than TODO. Pre-${NU4} mainnet nodes are defined as nodes on mainnet advertising a protocol version less than TODO.

+

For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding ${NU4} activation height, nodes compatible with ${NU4} activation on that network will change the behaviour of their peer connection logic in order to prefer pre-${NU4} 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). */
+static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
+

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

+

Once ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to:

+
    +
  • reject new connections from pre-${NU4} nodes on that network;
    • +
  • disconnect any existing connections to pre-${NU4} nodes on that network.
    • +
+
+
+

Backward compatibility

+

Prior to the network upgrade activating on each network, ${NU4} and pre-${NU4} nodes are compatible and can connect to each other. However, ${NU4} nodes will have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will gradually be disconnected in the run up to activation.

+

Once the network upgrades, even though pre-${NU4} nodes can still accept the numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes will always disconnect peers using lower protocol versions.

+

TODO: delete if applicable. Unlike Overwinter and Sapling, and like Blossom, ${NU4} does not define a new transaction version. ${NU4} transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in 2 section 7.1. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID.

+
+

Support in zcashd

+

Support for ${NU4} on testnet will be implemented in zcashd version TODO, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in zcashd version 3.0.0, which will advertise protocol version TODO.

+
+

References

+ + + + + + + +
1Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom]
+ + + + + + + +
3ZIP 200: Network Upgrade Activation Mechanism
+ + + + + + + +
4ZIP 201: Network Peer Management for Overwinter
+ + + + + + + +
5ZIP 208: Shorter Block Target Spacing
+ + + + + + + +
6ZIP 214: Consensus rules for a Zcash Development Fund
+ + + + + + + +
7ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
+
+
+ + \ No newline at end of file diff --git a/zip-0251.rst b/zip-0251.rst new file mode 100644 index 000000000..d5610b1b4 --- /dev/null +++ b/zip-0251.rst @@ -0,0 +1,134 @@ +:: + + ZIP: 251 + Title: Deployment of the ${NU4} Network Upgrade + Owners: Daira Hopwood + Status: Draft + Category: Consensus + Created: 2020-02-28 + 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 term "network upgrade" in this document is to be interpreted as described in +ZIP 200. [#zip-0200]_ + +The terms below are to be interpreted as follows: + +${NU4} + Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4. +Testnet + The Zcash test network, as defined in [#protocol]_. +Mainnet + The Zcash production network, as defined in [#protocol]_. + + +Abstract +======== + +This proposal defines the deployment of the ${NU4} network upgrade. + + +Specification +============= + +${NU4} deployment +----------------- + +The primary sources of information about ${NU4} consensus protocol changes are: + +- The Zcash Protocol Specification [#protocol]_ +- ZIP 200: Network Upgrade Mechanism [#zip-0200]_ +- ZIP 207: Funding Streams [#zip-0207]_ +- ZIP 214: Consensus rules for a Zcash Development Fund [#zip-0214]_ +- ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants [#zip-1014]_ +- TODO: other ZIPs + +The network handshake and peer management mechanisms defined in ZIP 201 [#zip-0201]_ +also apply to this upgrade. + + +The following network upgrade constants [#zip-0200]_ are defined for the ${NU4} +upgrade: + +BRANCH_ID + ``0xTODO`` + + +ACTIVATION_HEIGHT (${NU4}) + Testnet: TODO + + Mainnet: 1046400 + + +Nodes compatible with ${NU4} activation on testnet MUST advertise protocol version +TODO or later. Nodes compatible with ${NU4} activation on mainnet MUST advertise +protocol version TODO or later. The minimum peer protocol version that +${NU4}-compatible nodes will connect to is 170002. + +Pre-${NU4} testnet nodes are defined as nodes on testnet advertising a protocol +version less than TODO. Pre-${NU4} mainnet nodes are defined as nodes on mainnet +advertising a protocol version less than TODO. + +For each network (testnet and mainnet), approximately three days (defined in terms of +block height) before the corresponding ${NU4} activation height, nodes compatible +with ${NU4} activation on that network will change the behaviour of their peer +connection logic in order to prefer pre-${NU4} 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). */ + 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 ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to: + +- reject new connections from pre-${NU4} nodes on that network; +- disconnect any existing connections to pre-${NU4} nodes on that network. + + +Backward compatibility +====================== + +Prior to the network upgrade activating on each network, ${NU4} and pre-${NU4} +nodes are compatible and can connect to each other. However, ${NU4} nodes will +have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will +gradually be disconnected in the run up to activation. + +Once the network upgrades, even though pre-${NU4} nodes can still accept the +numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes +will always disconnect peers using lower protocol versions. + +TODO: delete if applicable. +Unlike Overwinter and Sapling, and like Blossom, ${NU4} does not define a new +transaction version. ${NU4} transactions are therefore in the same v4 format as +Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as +defined in [#protocol]_ section 7.1. This does not imply that transactions are +valid across the ${NU4} activation, since signatures MUST use the appropriate +consensus branch ID. + + +Support in zcashd +================= + +Support for ${NU4} on testnet will be implemented in ``zcashd`` version TODO, which +will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented +in ``zcashd`` version 3.0.0, which will advertise protocol version TODO. + + +References +========== + +.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ +.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ +.. [#zip-0207] `ZIP 208: Shorter Block Target Spacing `_ +.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund `_ +.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_ From 272f085f8c4f7af42a396fff4053aa6200b4de52 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 10 Mar 2020 23:18:37 +0000 Subject: [PATCH 04/26] ZIP 251: Add wording about transaction digest algorithm and reference ZIP 243. Signed-off-by: Daira Hopwood --- zip-0251.html | 16 ++++++++++++---- zip-0251.rst | 16 +++++++++------- 2 files changed, 21 insertions(+), 11 deletions(-) diff --git a/zip-0251.html b/zip-0251.html index 071982729..0a91fb783 100644 --- a/zip-0251.html +++ b/zip-0251.html @@ -37,7 +37,7 @@
  • ZIP 200: Network Upgrade Mechanism 3
  • ZIP 207: Funding Streams 5
  • ZIP 214: Consensus rules for a Zcash Development Fund 6
    • -
  • ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants 7
    • +
  • ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants 8
  • TODO: other ZIPs

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

    @@ -67,7 +67,7 @@

    Backward compatibility

    Prior to the network upgrade activating on each network, ${NU4} and pre-${NU4} nodes are compatible and can connect to each other. However, ${NU4} nodes will have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will gradually be disconnected in the run up to activation.

    Once the network upgrades, even though pre-${NU4} nodes can still accept the numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes will always disconnect peers using lower protocol versions.

    -

    TODO: delete if applicable. Unlike Overwinter and Sapling, and like Blossom, ${NU4} does not define a new transaction version. ${NU4} transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in 2 section 7.1. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID.

    +

    TODO: delete if inapplicable. Unlike Overwinter and Sapling, and like Blossom and Heartwood, ${NU4} does not define a new transaction version. ${NU4} transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in 2 section 7.1; and use the same transaction digest algorithm as defined in 7. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID. 7

    Support in zcashd

    Support for ${NU4} on testnet will be implemented in zcashd version TODO, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in zcashd version 3.0.0, which will advertise protocol version TODO.

    @@ -85,7 +85,7 @@ 2 - Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] + Zcash Protocol Specification, Version 2020.1.1 or later @@ -121,10 +121,18 @@ - +
    + + + +
    7ZIP 243: Transaction Signature Verification for Sapling
    + + + + diff --git a/zip-0251.rst b/zip-0251.rst index d5610b1b4..0d1d9b721 100644 --- a/zip-0251.rst +++ b/zip-0251.rst @@ -105,13 +105,14 @@ Once the network upgrades, even though pre-${NU4} nodes can still accept the numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes will always disconnect peers using lower protocol versions. -TODO: delete if applicable. -Unlike Overwinter and Sapling, and like Blossom, ${NU4} does not define a new -transaction version. ${NU4} transactions are therefore in the same v4 format as -Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as -defined in [#protocol]_ section 7.1. This does not imply that transactions are +TODO: delete if inapplicable. +Unlike Overwinter and Sapling, and like Blossom and Heartwood, ${NU4} does not +define a new transaction version. ${NU4} transactions are therefore in the same +v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 +as defined in [#protocol]_ section 7.1; and use the same transaction digest +algorithm as defined in [#zip-0243]_. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate -consensus branch ID. +consensus branch ID. [#zip-0243]_ Support in zcashd @@ -126,9 +127,10 @@ References ========== .. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] `_ +.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later `_ .. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0207] `ZIP 208: Shorter Block Target Spacing `_ .. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund `_ +.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling `_ .. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_ From 0fdd5de149f493d55c028c285cc6665cf3576fe3 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 10 Mar 2020 23:21:57 +0000 Subject: [PATCH 05/26] ZIP 214: Update version in Protocol Specification reference. Signed-off-by: Daira Hopwood --- zip-0214.html | 2 +- zip-0214.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0214.html b/zip-0214.html index 6ea7b69cf..a4f2c73b0 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -132,7 +132,7 @@ - +
    8 ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
    2Zcash Protocol Specification [Overwinter+Sapling+Blossom]Zcash Protocol Specification, Version 2020.1.1 or later
    diff --git a/zip-0214.rst b/zip-0214.rst index 236f5bfb0..847e7fdfe 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -317,7 +317,7 @@ References ========== .. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling+Blossom] `_ +.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later `_ .. [#trademark] `Zcash Trademark Donation and License Agreement `_ .. [#osd] `The Open Source Definition `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ From 45833a158876e06cb31cbb7d25a07b967a2700c6 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 11 Mar 2020 16:45:43 +0000 Subject: [PATCH 06/26] ZIP 251: remove trailing whitespace. Signed-off-by: Daira Hopwood --- zip-0251.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/zip-0251.rst b/zip-0251.rst index 0d1d9b721..efbe961a3 100644 --- a/zip-0251.rst +++ b/zip-0251.rst @@ -53,7 +53,7 @@ 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 ${NU4} +The following network upgrade constants [#zip-0200]_ are defined for the ${NU4} upgrade: BRANCH_ID @@ -77,14 +77,14 @@ advertising a protocol version less than TODO. For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding ${NU4} activation height, nodes compatible -with ${NU4} activation on that network will change the behaviour of their peer +with ${NU4} activation on that network will change the behaviour of their peer connection logic in order to prefer pre-${NU4} 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). */ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; -The implementation is similar to that for Overwinter which was described in +The implementation is similar to that for Overwinter which was described in [#zip-0201]_. Once ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to: @@ -98,11 +98,11 @@ Backward compatibility Prior to the network upgrade activating on each network, ${NU4} and pre-${NU4} nodes are compatible and can connect to each other. However, ${NU4} nodes will -have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will +have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will gradually be disconnected in the run up to activation. -Once the network upgrades, even though pre-${NU4} nodes can still accept the -numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes +Once the network upgrades, even though pre-${NU4} nodes can still accept the +numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes will always disconnect peers using lower protocol versions. TODO: delete if inapplicable. From 83abb5f5d32aef0c3ffb9b575588ad5452e104b1 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 11 Mar 2020 16:46:14 +0000 Subject: [PATCH 07/26] ZIP 207: s/founders reward/Founders' Reward/ Signed-off-by: Daira Hopwood --- zip-0207.html | 4 ++-- zip-0207.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0207.html b/zip-0207.html index 026bb7aa8..e80778e86 100644 --- a/zip-0207.html +++ b/zip-0207.html @@ -309,8 +309,8 @@ } } else { // Coinbase transaction must include an output sending 20% of - // the block subsidy to a Founders' Reward script, until the last founders - // reward block is reached, with exception of the genesis block. + // the block subsidy to a Founders' Reward script, until the last Founders' + // Reward block is reached, with exception of the genesis block. // The last Founders' Reward block is defined as the block just before the // first subsidy halving block. if ((nHeight > 0) && (nHeight <= consensusParams.GetLastFoundersRewardBlockHeight())) { diff --git a/zip-0207.rst b/zip-0207.rst index 93d202a04..6d19022c9 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -322,8 +322,8 @@ Example implementation } } else { // Coinbase transaction must include an output sending 20% of - // the block subsidy to a Founders' Reward script, until the last founders - // reward block is reached, with exception of the genesis block. + // the block subsidy to a Founders' Reward script, until the last Founders' + // Reward block is reached, with exception of the genesis block. // The last Founders' Reward block is defined as the block just before the // first subsidy halving block. if ((nHeight > 0) && (nHeight <= consensusParams.GetLastFoundersRewardBlockHeight())) { From e73e517fbf531efaef1119b095028bdad2cd1c71 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 13 Mar 2020 16:46:55 +0000 Subject: [PATCH 08/26] ZIP 214 is applicable only to Zcash. Signed-off-by: Daira Hopwood --- zip-0214.html | 26 +++++++++++++++----------- zip-0214.rst | 11 +++++++++++ 2 files changed, 26 insertions(+), 11 deletions(-) diff --git a/zip-0214.html b/zip-0214.html index a4f2c73b0..3eec73f8f 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -16,24 +16,28 @@ Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>

    Terminology

    The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" 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 5 and the Zcash Trademark Donation and License Agreement (3 or successor agreement).

    -

    The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 2

    -

    The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 9.

    +

    The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (3 or successor agreement).

    +

    The term "network upgrade" in this document is to be interpreted as described in ZIP 200 5 and the Zcash Trademark Donation and License Agreement (3 or successor agreement).

    +

    The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 2

    +

    The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 9.

    The terms below are to be interpreted as follows:

    ${NU4}
    Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
    Testnet
    -
    The Zcash test network, as defined in 2.
    +
    The Zcash test network, as defined in 2.
    Mainnet
    -
    The Zcash production network, as defined in 2.
    +
    The Zcash production network, as defined in 2.

    Abstract

    This ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

    +

    Applicability

    +

    This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other blockchains using Zcash technology.

    +

    Motivation

    -

    Motivation for the Zcash Development Fund itself is considered in ZIP 1014 9, which gives a high-level description of the intended structure of the fund.

    +

    Motivation for the Zcash Development Fund itself is considered in ZIP 1014 9, which gives a high-level description of the intended structure of the fund.

    An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.

    Requirements

    @@ -44,9 +48,9 @@

    This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.

    Specification

    -

    The Blossom network upgrade changed the height of the first halving to block height 1046400 7, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.

    +

    The Blossom network upgrade changed the height of the first halving to block height 1046400 7, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.

    Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of ${NU4} on Mainnet therefore SHALL be 1046400.

    -

    ZIP 207 6 SHALL be activated in ${NU4}.

    +

    ZIP 207 6 SHALL be activated in ${NU4}.

    The following funding streams are defined for Mainnet:

    @@ -92,10 +96,10 @@
  • ECC SHALL generate the addresses for the FS_ECC funding stream, which on Mainnet corresponds to the ECC slice;
  • ZF SHALL generate the addresses for the FS_ZF and FS_MG funding streams, which on Mainnet correspond to the ZF slice and MG slice respectively.
    • -

    Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 9.

    +

    Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 9.

    No requirements are imposed on the use of funds sent to Testnet funding streams.

    Direct-grant option

    -

    ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before ${NU4} activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 9

    +

    ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before ${NU4} activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 9

    The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total amount of funding streams assigned to direct grantees MUST be subtracted from the funding stream for the remaining MG slice (or, if all Major Grants are direct, replace the funding stream for the MG slice).

    For each network upgrade after ${NU4} requiring modifications to the set of direct grantees, a separate ZIP would be published specifying those modifications.

    @@ -117,7 +121,7 @@

    Deployment

    -

    This proposal is intended to be deployed with ${NU4}. 8

    +

    This proposal is intended to be deployed with ${NU4}. 8

    References

    diff --git a/zip-0214.rst b/zip-0214.rst index 847e7fdfe..06b975d32 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -16,6 +16,10 @@ Terminology The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ +The term "Zcash" in this document is to be interpreted as described in the +Zcash Trademark Donation and License Agreement ([#trademark]_ or successor +agreement). + The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor agreement). @@ -46,6 +50,13 @@ the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years. +Applicability +============= + +This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be +applicable to other blockchains using Zcash technology. + + Motivation ========== From 624ce6d6b078b164034bdc606a63ad703ec2f919 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 13 Mar 2020 16:47:26 +0000 Subject: [PATCH 09/26] ZIP 207: add definitions of "branch" and "network upgrade". Signed-off-by: Daira Hopwood --- zip-0207.html | 43 ++++++++++++++++++++++++++----------------- zip-0207.rst | 4 ++++ 2 files changed, 30 insertions(+), 17 deletions(-) diff --git a/zip-0207.html b/zip-0207.html index e80778e86..836ed6fc0 100644 --- a/zip-0207.html +++ b/zip-0207.html @@ -17,31 +17,32 @@

    Terminology

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

    The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 3 5

    +

    The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 8

    The terms below are to be interpreted as follows:

    ${NU4}
    Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
    Testnet
    -
    The Zcash test network, as defined in the Zcash Protocol Specification. 2
    +
    The Zcash test network, as defined in the Zcash Protocol Specification. 2
    Mainnet
    -
    The Zcash production network, as defined in the Zcash Protocol Specification. 2
    +
    The Zcash production network, as defined in the Zcash Protocol Specification. 2

    Abstract

    This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.

    -

    This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 10. It should be read in conjunction with ZIP 1014 12, which describes the high-level requirements for that fund.

    +

    This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 11. It should be read in conjunction with ZIP 1014 13, which describes the high-level requirements for that fund.

    Motivation

    -

    Motivation for the Zcash Development Fund is considered in ZIP 1014 12.

    +

    Motivation for the Zcash Development Fund is considered in ZIP 1014 13.

    This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.

    Requirements

    -

    The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 12, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.

    +

    The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 13, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.

    As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.

    Specification

    Definitions

    -

    We use the following constants and functions defined in 4, 5, and 6:

    +

    We use the following constants and functions defined in 4, 5, and 6:

    • BlossomActivationHeight
    • PostBlossomHalvingInterval
      • @@ -56,7 +57,7 @@

    Funding streams

    A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).

    -

    By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates, while maintaining an unchanged target-time-based issuance schedule. Such a target-time / issuance rate change occurred at the Blossom network upgrade, for example. 8

    +

    By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates, while maintaining an unchanged target-time-based issuance schedule. Such a target-time / issuance rate change occurred at the Blossom network upgrade, for example. 9

    The value of a funding stream at a given block height is defined as:

    FundingStream[FUND].Value(height) =
     floor((
@@ -176,15 +177,15 @@
                 
    On Mainnet, ${NU4} is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to ${NU4} activation.

    Consensus rules

    -

    Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 6

    +

    Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 6

    Once the ${NU4} network upgrade activates:

      -
    • The existing consensus rule 6 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
      • +
    • The existing consensus rule 6 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
    • The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.
    • The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form OP_HASH160 RedeemScriptHash(height) OP_EQUAL as the scriptPubKey.
      • -
    • The "prescribed way" to pay a Sapling address is as defined in 9. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.
      • +
    • The "prescribed way" to pay a Sapling address is as defined in 10. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.
    -

    For the funding stream definitions to be activated at ${NU4}, see ZIP 214. 10 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 7

    +

    For the funding stream definitions to be activated at ${NU4}, see ZIP 214. 11 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 7

    Example implementation 

    struct FundingPeriod {
@@ -337,7 +338,7 @@

    Deployment

    -

    This proposal is intended to be deployed with ${NU4}. 11

    +

    This proposal is intended to be deployed with ${NU4}. 12

    Backward compatibility

    This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists.

    @@ -402,10 +403,18 @@
    - +
    + + + +
    8ZIP 200: Network Upgrade Mechanism
    + + + + @@ -413,7 +422,7 @@
    9 ZIP 208: Shorter Block Target Spacing
    - + @@ -421,7 +430,7 @@
    910 ZIP 213: Shielded Coinbase
    - + @@ -429,7 +438,7 @@
    1011 ZIP 214: Consensus rules for a Zcash Development Fund
    - + @@ -437,7 +446,7 @@
    1112 ZIP 251: Deployment of the ${NU4} Network Upgrade
    - + diff --git a/zip-0207.rst b/zip-0207.rst index 6d19022c9..472f7cee9 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -20,6 +20,9 @@ The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. [#protocol-subsidyconcepts]_ [#protocol-subsidies]_ +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: ${NU4} @@ -381,6 +384,7 @@ References .. [#protocol-subsidies] `Section 7.7: Calculation of Block Subsidy and Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later `_ .. [#protocol-foundersreward] `Section 7.8: Payment of Founders' Reward. Zcash Protocol Specification, Version 2020.1.1 or later `_ .. [#zip-0000] `ZIP 0: ZIP Process `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ .. [#zip-0213] `ZIP 213: Shielded Coinbase `_ .. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund `_ From 0a26121691c678b7f3cff43939456a12d634ec5e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 13 Mar 2020 16:48:09 +0000 Subject: [PATCH 10/26] ZIP 214: state explicitly that start height is inclusive and end height is exclusive. Signed-off-by: Daira Hopwood --- zip-0214.html | 7 ++++--- zip-0214.rst | 4 ++++ 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/zip-0214.html b/zip-0214.html index 3eec73f8f..19925d991 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -88,6 +88,7 @@
    1213 ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
    +

    As specified in 6, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.

    The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of ${NU4} on Testnet, i.e. xxxxxxx.

    Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the corresponding initial amount on Mainnet. This reduces to the same amount as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).

    Dev Fund Recipient Addresses

    @@ -96,10 +97,10 @@
  • ECC SHALL generate the addresses for the FS_ECC funding stream, which on Mainnet corresponds to the ECC slice;
  • ZF SHALL generate the addresses for the FS_ZF and FS_MG funding streams, which on Mainnet correspond to the ZF slice and MG slice respectively.
    • -

    Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 9.

    +

    Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 9.

    No requirements are imposed on the use of funds sent to Testnet funding streams.

    Direct-grant option

    -

    ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before ${NU4} activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 9

    +

    ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before ${NU4} activation, some portion of the MG slice may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. 9

    The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total amount of funding streams assigned to direct grantees MUST be subtracted from the funding stream for the remaining MG slice (or, if all Major Grants are direct, replace the funding stream for the MG slice).

    For each network upgrade after ${NU4} requiring modifications to the set of direct grantees, a separate ZIP would be published specifying those modifications.

    @@ -121,7 +122,7 @@

    Deployment

    -

    This proposal is intended to be deployed with ${NU4}. 8

    +

    This proposal is intended to be deployed with ${NU4}. 8

    References

    diff --git a/zip-0214.rst b/zip-0214.rst index 06b975d32..176f1ae5f 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -111,6 +111,10 @@ The following funding streams are defined for Mainnet: ``FS_MG`` 8 100 1046400 2726400 ========== =========== ============= ============== ============ +As specified in [#zip-0207]_, a funding stream is active for a span of blocks +that includes the block at its start height, but excludes the block at its end +height. + The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of ${NU4} on Testnet, i.e. xxxxxxx. From 4fd8f06bc182bb6b7202b0502ba666e0dda98a12 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 13 Mar 2020 17:18:59 +0000 Subject: [PATCH 11/26] ZIP 214: change wording to reflect the fact that ZEC != TAZ. Signed-off-by: Daira Hopwood --- zip-0214.html | 2 +- zip-0214.rst | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0214.html b/zip-0214.html index 19925d991..f3e107346 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -90,7 +90,7 @@

    As specified in 6, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.

    The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of ${NU4} on Testnet, i.e. xxxxxxx.

    -

    Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the corresponding initial amount on Mainnet. This reduces to the same amount as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).

    +

    Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).

    Dev Fund Recipient Addresses

    For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of independent recipient addresses to be used for each stream in each funding period:

      diff --git a/zip-0214.rst b/zip-0214.rst index 176f1ae5f..d34f92437 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -122,9 +122,9 @@ xxxxxxx. Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet -block height 1046400) be double the corresponding initial amount on Mainnet. This -reduces to the same amount as on Mainnet, from Testnet block heights 1046400 -(inclusive) to 2726400 (exclusive). +block height 1046400) be double the number of currency units as the corresponding +initial amount on Mainnet. This reduces to the same number of currency units as on +Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive). Dev Fund Recipient Addresses From 0bd85486fe1c516066ba8415eee638ec9a900d30 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 13 Mar 2020 17:19:26 +0000 Subject: [PATCH 12/26] ZIP 214: add rationale section. Signed-off-by: Daira Hopwood --- zip-0214.html | 8 +++++++- zip-0214.rst | 23 +++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/zip-0214.html b/zip-0214.html index f3e107346..0738caf58 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -121,8 +121,14 @@

      TODO

    +

    Rationale

    +

    The rationale for ZF generating the addresses for the ZF_MG funding stream is that ZF is the financial recipient of the MG slice as specified in ZIP 1014. 9

    +

    Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.

    +

    Since Testnet is ahead of Mainnet in terms of block height (by ~77000 blocks at the time of writing, which is the equivalent of ~67 days at the post-Blossom block target spacing), the activation height and the start heights of the funding streams could have also been set to 1046400 on Testnet. However, 67 days is arguably too short a testing period, and the block rate on Testnet is less predictable than on Mainnet.

    +

    It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.

    +

    Deployment

    -

    This proposal is intended to be deployed with ${NU4}. 8

    +

    This proposal is intended to be deployed with ${NU4}. 8

    References

    diff --git a/zip-0214.rst b/zip-0214.rst index d34f92437..73b036e93 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -322,6 +322,29 @@ Testnet Recipient Addresses TODO +Rationale +========= + +The rationale for ZF generating the addresses for the ``ZF_MG`` funding +stream is that ZF is the financial recipient of the **MG slice** as specified +in ZIP 1014. [#zip-1014]_ + +Generation of recipient addresses for Testnet is specified to be done by the +same parties as on Mainnet, in order to allow practicing each party's security +procedures. + +Since Testnet is ahead of Mainnet in terms of block height (by ~77000 blocks +at the time of writing, which is the equivalent of ~67 days at the post-Blossom +block target spacing), the activation height and the start heights of the +funding streams could have also been set to 1046400 on Testnet. However, +67 days is arguably too short a testing period, and the block rate on Testnet +is less predictable than on Mainnet. + +It was judged to be unnecessary to have a mechanism to update funding stream +definitions (in case of security breach or changes to direct grant recipients) +other than at network upgrades. + + Deployment ========== From 1f77e08d4fc816084caf455bee5b7889e9774bdd Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 16 Mar 2020 19:52:48 +0000 Subject: [PATCH 13/26] "branch" -> "consensus branch" Signed-off-by: Daira Hopwood --- zip-0207.html | 4 ++-- zip-0207.rst | 6 +++--- zip-0251.html | 2 +- zip-0251.rst | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/zip-0207.html b/zip-0207.html index 836ed6fc0..68091babc 100644 --- a/zip-0207.html +++ b/zip-0207.html @@ -17,7 +17,7 @@

    Terminology

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

    The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 3 5

    -

    The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 8

    +

    The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 8

    The terms below are to be interpreted as follows:

    ${NU4}
    @@ -341,7 +341,7 @@

    This proposal is intended to be deployed with ${NU4}. 12

    Backward compatibility

    -

    This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists.

    +

    This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.

    Reference Implementation

    TBC

    diff --git a/zip-0207.rst b/zip-0207.rst index 472f7cee9..613fe68de 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -20,8 +20,8 @@ The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. [#protocol-subsidyconcepts]_ [#protocol-subsidies]_ -The terms "branch" and "network upgrade" in this document are to be interpreted as -described in ZIP 200. [#zip-0200]_ +The terms "consensus 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: @@ -365,7 +365,7 @@ This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any -pre-upgrade branch that persists. +pre-upgrade consensus branch that persists. Reference Implementation diff --git a/zip-0251.html b/zip-0251.html index 0a91fb783..aec38f660 100644 --- a/zip-0251.html +++ b/zip-0251.html @@ -43,7 +43,7 @@

    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 ${NU4} upgrade:

    -
    BRANCH_ID
    +
    CONSENSUS_BRANCH_ID
    0xTODO
    ACTIVATION_HEIGHT (${NU4})
    diff --git a/zip-0251.rst b/zip-0251.rst index efbe961a3..35e6befd5 100644 --- a/zip-0251.rst +++ b/zip-0251.rst @@ -56,7 +56,7 @@ also apply to this upgrade. The following network upgrade constants [#zip-0200]_ are defined for the ${NU4} upgrade: -BRANCH_ID +CONSENSUS_BRANCH_ID ``0xTODO`` From 3cca1cc1088e8d800ae2cb46f48deeeb1445187d Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 17 Mar 2020 18:32:51 +0000 Subject: [PATCH 14/26] Scrunch pre and math blocks a bit more. Signed-off-by: Daira Hopwood --- css/style.css | 45 ++++++++++++++++++++++++++++++--------------- 1 file changed, 30 insertions(+), 15 deletions(-) diff --git a/css/style.css b/css/style.css index 158b07d61..251f03863 100644 --- a/css/style.css +++ b/css/style.css @@ -122,7 +122,7 @@ div.math { margin: 0 1rem 1rem 1rem; text-align: center; padding: 0; - font-size: 0.9375rem; + font-size: 0.75rem; } a, a:visited { @@ -170,15 +170,6 @@ table { border: 0 none transparent; } -@media (max-width: 576px) { - table:not(.footnote) { - display: block; - } - pre, div.math, table { - font-size: 0.6rem; - } -} - th, td { border: 1px solid #212529; } @@ -221,12 +212,27 @@ td:first-child { content: "]"; } +@media (max-width: 576px) { + table:not(.footnote) { + display: block; + } + pre, div.math { + font-size: 0.5rem; + } + table { + font-size: 0.6rem; + } +} + @media (min-width: 576px) { body > section { max-width: initial; width: 510px; } - pre, div.math, table { + pre, div.math { + font-size: 0.5rem; + } + table { font-size: 0.6rem; } } @@ -235,7 +241,10 @@ td:first-child { body > section { width: 690px; } - pre, div.math, table { + pre, div.math { + font-size: 0.55rem; + } + table { font-size: 0.7rem; } } @@ -244,7 +253,10 @@ td:first-child { body > section { width: 770px; } - pre, div.math, table { + pre, div.math { + font-size: 0.6rem; + } + table { font-size: 0.8rem; } } @@ -254,7 +266,10 @@ td:first-child { max-width: initial; width: 920px; } - pre, div.math, table { + pre, div.math { + font-size: 0.68rem; + } + table { font-size: 0.85rem; } } @@ -265,7 +280,7 @@ td:first-child { width: 1200px; } pre, div.math { - font-size: 0.9375rem; + font-size: 0.75rem; } table { font-size: 1rem; From c9ae7af581c0b61df403e35cb9732d0bcfe0b700 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 17 Mar 2020 18:40:07 +0000 Subject: [PATCH 15/26] ZIP 207: simplify wording about using a proportion of block subsidy. Signed-off-by: Daira Hopwood --- zip-0207.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/zip-0207.rst b/zip-0207.rst index 613fe68de..18b44d5bc 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -104,9 +104,8 @@ numerator and a denominator), a start height (inclusive), and an end height By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block -target spacing and issuance-per-block rates, while maintaining an unchanged -target-time-based issuance schedule. Such a target-time / issuance rate change -occurred at the Blossom network upgrade, for example. [#zip-0208]_ +target spacing and issuance-per-block rates. Such a change occurred at the +Blossom network upgrade, for example. [#zip-0208]_ The value of a funding stream at a given block height is defined as:: From b70ba3406d00075dc6234d2249b238e6eb2d405d Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 17 Mar 2020 18:40:57 +0000 Subject: [PATCH 16/26] ZIP 207: use math markup. Signed-off-by: Daira Hopwood --- zip-0207.rst | 50 ++++++++++++++++++++++++++++---------------------- 1 file changed, 28 insertions(+), 22 deletions(-) diff --git a/zip-0207.rst b/zip-0207.rst index 18b44d5bc..985ff0d8b 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -83,16 +83,16 @@ Definitions We use the following constants and functions defined in [#protocol-constants]_, [#protocol-subsidies]_, and [#protocol-foundersreward]_: -- ``BlossomActivationHeight`` -- ``PostBlossomHalvingInterval`` -- ``Halving(height)`` -- ``BlockSubsidy(height)`` -- ``RedeemScriptHash(height)``. +- :math:`\mathsf{BlossomActivationHeight}` +- :math:`\mathsf{PostBlossomHalvingInterval}` +- :math:`\mathsf{Halving}(\mathsf{height})` +- :math:`\mathsf{BlockSubsidy}(\mathsf{height})` +- :math:`\mathsf{RedeemScriptHash}(\mathsf{height})`. We also define the following function: -- ``HeightForHalving(halving)``: Smallest ``height`` such that - ``Halving(height) = halving`` +- :math:`\mathsf{HeightForHalving}(\mathsf{halving})`: Smallest :math:`\mathsf{height}` such that + :math:`\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}` Funding streams @@ -107,12 +107,14 @@ than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. [#zip-0208]_ -The value of a funding stream at a given block height is defined as:: +The value of a funding stream at a given block height is defined as: - FundingStream[FUND].Value(height) = - floor(( - BlockSubsidy(height) * FundingStream[FUND].ValueNumerator - ) / FundingStream[FUND].ValueDenominator) +.. math:: + + \mathsf{FundingStream[FUND].Value}(\mathsf{height}) = + \mathsf{floor}\left( + \frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}} + \right) An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less @@ -123,16 +125,20 @@ each of which MUST be either a transparent P2SH address or a Sapling address. Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a -given block height is defined as follows:: - - AddressChangeInterval = PostBlossomHalvingInterval / 48 - AddressPeriod(height) = - floor(( - height + PostBlossomHalvingInterval - HeightForHalving(1) - ) / AddressChangeInterval) - FundingStream[FUND].AddressIndex(height) = - AddressPeriod(height) - AddressPeriod(FundingStream[FUND].StartHeight) - Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex(height)] +given block height is defined as follows: + +.. math:: + + \begin{eqnarray*} + \mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\ + \mathsf{AddressPeriod}(\mathsf{height}) &=& + \mathsf{floor}\left( + {\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}} + \right) \\ + \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &=& + \mathsf{AddressPeriod}(\mathsf{height}) - \\&&\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\ + \mathsf{Address}(\mathsf{height}) &=& \mathsf{FundingStream[FUND].Addresses[} \\&&\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]} + \end{eqnarray*} This has the property that all active funding streams change the address they are using on the same block height schedule, aligned to the height of the From 1ec5ac728110cf729077c466c025a0636098e285 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 17 Mar 2020 18:41:40 +0000 Subject: [PATCH 17/26] ZIP 207: in the example implementation, ensure that multiplication by the numerator won't overflow. Signed-off-by: Daira Hopwood --- zip-0207.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/zip-0207.rst b/zip-0207.rst index 985ff0d8b..be9512dbc 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -238,6 +238,7 @@ Example implementation uint64_t valueDenominator) { assert(valueNumerator < valueDenominator); + assert(valueNumerator < INT64_MAX / MAX_MONEY); params.vFundingPeriods[idx].addresses = addresses; params.vFundingPeriods[idx].valueNumerator = valueNumerator; params.vFundingPeriods[idx].valueDenominator = valueDenominator; From 9ce78b04f58eeabe2981680d8a948baa514ed61a Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 17 Mar 2020 18:42:29 +0000 Subject: [PATCH 18/26] ZIP 207: be more explicit about which consensus rule is no longer active after NU4 activation. Signed-off-by: Daira Hopwood --- zip-0207.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zip-0207.rst b/zip-0207.rst index be9512dbc..25f1d7d30 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -181,7 +181,8 @@ for payment of the original Founders' Reward is enforced. [#protocol-foundersrew Once the ${NU4} network upgrade activates: -- The existing consensus rule [#protocol-foundersreward]_ is no longer active. +- The existing consensus rule for payment of the Founders' Reward [#protocol-foundersreward]_ + is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.) From 9ac5984f547c88e310d194f50b2768582ac7b97d Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 17 Mar 2020 18:43:15 +0000 Subject: [PATCH 19/26] ZIP 207: reference fix and HTML. Signed-off-by: Daira Hopwood --- zip-0207.html | 72 ++++++++++++++++++++++++++++++++------------------- zip-0207.rst | 2 +- 2 files changed, 47 insertions(+), 27 deletions(-) diff --git a/zip-0207.html b/zip-0207.html index 68091babc..077dd7a20 100644 --- a/zip-0207.html +++ b/zip-0207.html @@ -3,6 +3,7 @@ ZIP 207: Funding Streams +
    @@ -37,43 +38,61 @@

    This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.

    Requirements

    -

    The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 13, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.

    +

    The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 11 to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 13, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.

    As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.

    Specification

    Definitions

    -

    We use the following constants and functions defined in 4, 5, and 6:

    +

    We use the following constants and functions defined in 4, 5, and 6:

      -
    • BlossomActivationHeight
      • -
    • PostBlossomHalvingInterval
      • -
    • Halving(height)
      • -
    • BlockSubsidy(height)
      • -
    • RedeemScriptHash(height).
      • +
    • + \(\mathsf{BlossomActivationHeight}\) +
      • +
    • + \(\mathsf{PostBlossomHalvingInterval}\) +
      • +
    • + \(\mathsf{Halving}(\mathsf{height})\) +
      • +
    • + \(\mathsf{BlockSubsidy}(\mathsf{height})\) +
      • +
    • + \(\mathsf{RedeemScriptHash}(\mathsf{height})\) + .

    We also define the following function:

      -
    • HeightForHalving(halving): Smallest height such that Halving(height) = halving
      • +
    • + \(\mathsf{HeightForHalving}(\mathsf{halving})\) + : Smallest + \(\mathsf{height}\) + such that + \(\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}\) +

    Funding streams

    A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).

    -

    By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates, while maintaining an unchanged target-time-based issuance schedule. Such a target-time / issuance rate change occurred at the Blossom network upgrade, for example. 9

    +

    By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. 9

    The value of a funding stream at a given block height is defined as:

    - 
    FundingStream[FUND].Value(height) =
-    floor((
-        BlockSubsidy(height) * FundingStream[FUND].ValueNumerator
-    ) / FundingStream[FUND].ValueDenominator)
    +
    \(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) = + \mathsf{floor}\left( + \frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}} + \right)\)

    An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height.

    Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.

    Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:

    - 
    AddressChangeInterval = PostBlossomHalvingInterval / 48
-AddressPeriod(height) =
-    floor((
-        height + PostBlossomHalvingInterval - HeightForHalving(1)
-    ) / AddressChangeInterval)
-FundingStream[FUND].AddressIndex(height) =
-    AddressPeriod(height) - AddressPeriod(FundingStream[FUND].StartHeight)
-Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex(height)]
    +
    \(\begin{eqnarray*} + \mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\ + \mathsf{AddressPeriod}(\mathsf{height}) &=& + \mathsf{floor}\left( + {\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}} + \right) \\ + \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &=& + \mathsf{AddressPeriod}(\mathsf{height}) - \\&&\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\ + \mathsf{Address}(\mathsf{height}) &=& \mathsf{FundingStream[FUND].Addresses[} \\&&\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]} +\end{eqnarray*}\)

    This has the property that all active funding streams change the address they are using on the same block height schedule, aligned to the height of the first halving so that 48 funding periods fit cleanly within a halving interval. This can be leveraged to simplify implementations, by batching the necessary outputs for each funding period.

    Below is a visual representation of how stream addresses align with funding periods:

    @@ -177,15 +196,15 @@

    On Mainnet, ${NU4} is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to ${NU4} activation.

    Consensus rules

    -

    Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 6

    +

    Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 6

    Once the ${NU4} network upgrade activates:

      -
    • The existing consensus rule 6 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
      • +
    • The existing consensus rule for payment of the Founders' Reward 6 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
    • The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.
    • The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form OP_HASH160 RedeemScriptHash(height) OP_EQUAL as the scriptPubKey.
      • -
    • The "prescribed way" to pay a Sapling address is as defined in 10. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.
      • +
    • The "prescribed way" to pay a Sapling address is as defined in 10. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.
    -

    For the funding stream definitions to be activated at ${NU4}, see ZIP 214. 11 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 7

    +

    For the funding stream definitions to be activated at ${NU4}, see ZIP 214. 11 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 7

    Example implementation 

    struct FundingPeriod {
@@ -218,6 +237,7 @@
     uint64_t valueDenominator)
 {
     assert(valueNumerator < valueDenominator);
+    assert(valueNumerator < INT64_MAX / MAX_MONEY);
     params.vFundingPeriods[idx].addresses = addresses;
     params.vFundingPeriods[idx].valueNumerator = valueNumerator;
     params.vFundingPeriods[idx].valueDenominator = valueDenominator;
@@ -338,7 +358,7 @@

    Deployment

    -

    This proposal is intended to be deployed with ${NU4}. 12

    +

    This proposal is intended to be deployed with ${NU4}. 12

    Backward compatibility

    This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.

    diff --git a/zip-0207.rst b/zip-0207.rst index 25f1d7d30..36603514e 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -63,7 +63,7 @@ Requirements ============ The primary requirement of this ZIP is to provide a mechanism for specifying -the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash +the funding streams that are used in ZIP 214 [#zip-0214]_ to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 [#zip-1014]_, and also (with additional funding stream definitions) the "direct grant option" described From edc43904c9918ee8276b331fc5935f893c38f620 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 24 Mar 2020 15:13:53 +0000 Subject: [PATCH 20/26] Protocol spec: clarify note about hashFinalSaplingRoot/hashLightClientRoot. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 91a83d954..c79156d0f 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -9225,8 +9225,8 @@ \item There are no changes to the \blockVersionNumber or format for \Blossom. } \heartwood{ - \item The $\hashFinalSaplingRoot$ field is renamed to $\hashLightClientRoot$, and - its semantics changed according to \cite{ZIP-221}. + \item For \Heartwood, the $\hashFinalSaplingRoot$ field is renamed to $\hashLightClientRoot$. + Once \Heartwood activates, the meaning of this field changes according to \cite{ZIP-221}. } \end{pnotes} From 5fa56e83bff18f53703c881026e9db4be4069be3 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 24 Mar 2020 22:44:54 +0000 Subject: [PATCH 21/26] Protocol spec: add references for the NU4 upgrade. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 16 ++++++++++++++++ protocol/zcash.bib | 18 ++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index c79156d0f..8aaa8041c 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -8644,6 +8644,9 @@ \heartwood{The specifications of the \Heartwood upgrade are described in this document, \cite{ZIP-250}, \cite{ZIP-213}, and \cite{ZIP-221}.} +\nufour{The specifications of the \Nufour upgrade are described in this document, +\cite{ZIP-251}, \cite{ZIP-207}, and \cite{ZIP-214}.} + \vspace{1ex} \introlist Each \networkUpgrade is introduced as a @@ -10386,6 +10389,19 @@ \intropart \lsection{Change History}{changehistory} +\historyentry{2020.1.3}{} + +\begin{itemize} + \item No changes to \Sprout, \Sapling, or \Blossom. +\heartwood{ + \item Minor wording clarifications. +} +\nufour{ + \item Reference \cite{ZIP-251}, \cite{ZIP-207}, and \cite{ZIP-214} for the \Nufour upgrade. +} +\end{itemize} + + \historyentry{2020.1.2}{2020-03-20} \begin{itemize} diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 2693ad7c6..4538337b8 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -927,6 +927,15 @@ @misc{ZIP-213 urldate={2020-03-20} } +@misc{ZIP-214, + presort={ZIP-0214}, + author={Daira Hopwood}, + title={Consensus rules for a Zcash Development Fund}, + howpublished={Zcash Improvement Proposal 214. Created February~28, 2020.}, + url={https://zips.z.cash/zip-0214}, + urldate={2020-03-24} +} + @misc{ZIP-221, presort={ZIP-0221}, author={Jack Grigg}, @@ -954,6 +963,15 @@ @misc{ZIP-250 urldate={2020-03-20} } +@misc{ZIP-251, + presort={ZIP-0251}, + author={Daira Hopwood}, + title={Deployment of the \$\{NU4\} Network Upgrade}, + howpublished={Zcash Improvement Proposal 251. Created February~28, 2020.}, + url={https://zips.z.cash/zip-0251}, + urldate={2020-03-24} +} + @misc{ZIP-302, presort={ZIP-0302}, author={Jay Graber and Jack Grigg}, From d3784f64c4043e90d110169d2c0bff287c3ee06c Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 24 Mar 2020 22:56:12 +0000 Subject: [PATCH 22/26] ZIP 214: blockchains -> block chains. Co-Authored-By: str4d --- zip-0214.html | 2 +- zip-0214.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0214.html b/zip-0214.html index 0738caf58..963d766cb 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -34,7 +34,7 @@

    This ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

    Applicability

    -

    This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other blockchains using Zcash technology.

    +

    This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other block chains using Zcash technology.

    Motivation

    Motivation for the Zcash Development Fund itself is considered in ZIP 1014 9, which gives a high-level description of the intended structure of the fund.

    diff --git a/zip-0214.rst b/zip-0214.rst index 73b036e93..f097dddfc 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -54,7 +54,7 @@ Applicability ============= This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be -applicable to other blockchains using Zcash technology. +applicable to other block chains using Zcash technology. Motivation From 27accd4cc3c99bac445b250c9fd237e8ce1d99ca Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 24 Mar 2020 23:07:45 +0000 Subject: [PATCH 23/26] ZIP 214: allow addresses within a funding stream to be repeated. Remove definitions of unused RFC 2119 keywords. Signed-off-by: Daira Hopwood --- zip-0214.html | 5 +++-- zip-0214.rst | 12 ++++++++---- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/zip-0214.html b/zip-0214.html index 963d766cb..9d0096754 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -15,7 +15,7 @@ License: MIT Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>

    Terminology

    -

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

    +

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

    The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (3 or successor agreement).

    The term "network upgrade" in this document is to be interpreted as described in ZIP 200 5 and the Zcash Trademark Donation and License Agreement (3 or successor agreement).

    The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 2

    @@ -92,11 +92,12 @@

    The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of ${NU4} on Testnet, i.e. xxxxxxx.

    Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).

    Dev Fund Recipient Addresses

    -

    For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of independent recipient addresses to be used for each stream in each funding period:

    +

    For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of recipient addresses to be used for each stream in each funding period:

    • ECC SHALL generate the addresses for the FS_ECC funding stream, which on Mainnet corresponds to the ECC slice;
    • ZF SHALL generate the addresses for the FS_ZF and FS_MG funding streams, which on Mainnet correspond to the ZF slice and MG slice respectively.
    +

    Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.

    Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 9.

    No requirements are imposed on the use of funds sent to Testnet funding streams.

    Direct-grant option

    diff --git a/zip-0214.rst b/zip-0214.rst index f097dddfc..872bc9b2a 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -13,8 +13,8 @@ Terminology =========== -The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" -in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ +The key words "MUST", "SHALL", and "SHOULD" in this document are to be +interpreted as described in RFC 2119. [#RFC2119]_ The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor @@ -132,14 +132,18 @@ Dev Fund Recipient Addresses For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) -SHALL generate sequences of independent recipient addresses to be used for each -stream in each funding period: +SHALL generate sequences of recipient addresses to be used for each stream in each +funding period: * ECC SHALL generate the addresses for the ``FS_ECC`` funding stream, which on Mainnet corresponds to the **ECC slice**; * ZF SHALL generate the addresses for the ``FS_ZF`` and ``FS_MG`` funding streams, which on Mainnet correspond to the **ZF slice** and **MG slice** respectively. +Within each stream, the addresses MAY be independent, or MAY be repeated between +funding periods. Each party SHOULD take account of operational security issues +associated with potential compromise of the associated spending keys. + Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 [#zip-1014]_. From 5182e212d030555220a618437be483199a0ba699 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 27 Mar 2020 00:08:43 +0000 Subject: [PATCH 24/26] ZIP 207: improvements to the pseudocode. Signed-off-by: Daira Hopwood --- zip-0207.html | 49 ++++++++++++++++++++++++++++++------------------- zip-0207.rst | 49 ++++++++++++++++++++++++++++++------------------- 2 files changed, 60 insertions(+), 38 deletions(-) diff --git a/zip-0207.html b/zip-0207.html index 077dd7a20..84d08007c 100644 --- a/zip-0207.html +++ b/zip-0207.html @@ -222,6 +222,8 @@ MAX_FUNDING_STREAMS, }; +const auto FIRST_FUNDING_STREAM = FS_ECC; + struct Params { ... int nFundingPeriodLength; @@ -234,16 +236,17 @@ Consensus::FundingStream idx, std::vector<std::string> addresses, uint64_t valueNumerator, - uint64_t valueDenominator) + uint64_t valueDenominator, + int startHeight, + int endHeight) { assert(valueNumerator < valueDenominator); assert(valueNumerator < INT64_MAX / MAX_MONEY); params.vFundingPeriods[idx].addresses = addresses; params.vFundingPeriods[idx].valueNumerator = valueNumerator; params.vFundingPeriods[idx].valueDenominator = valueDenominator; - params.vFundingPeriods[idx].startHeight = - params.vUpgrades[Consensus::UPGRADE_BLOSSOM].nActivationHeight; - params.vFundingPeriods[idx].endHeight = HeightForHalving(params, 1); + params.vFundingPeriods[idx].startHeight = startHeight; + params.vFundingPeriods[idx].endHeight = endHeight; assert(params.vFundingPeriods[idx].startHeight < params.vFundingPeriods[idx].endHeight); }; @@ -252,9 +255,11 @@ consensus.nFundingPeriodLength = consensus.nSubsidyPostBlossomHalvingInterval / 48; - AddZIP207FundingStream(consensus, Consensus::FS_ECC, FS_ECC_ADDRESSES, 7, 100); - AddZIP207FundingStream(consensus, Consensus::FS_ZF, FS_ZF_ADDRESSES, 5, 100); - AddZIP207FundingStream(consensus, Consensus::FS_MG, FS_MG_ADDRESSES, 8, 100); + int devFundStartHeight = HeightForHalving(params, 1); + int devFundEndHeight = HeightForHalving(params, 2); + AddZIP207FundingStream(consensus, Consensus::FS_ECC, FS_ECC_ADDRESSES, 7, 100, devFundStartHeight, devFundEndHeight); + AddZIP207FundingStream(consensus, Consensus::FS_ZF, FS_ZF_ADDRESSES, 5, 100, devFundStartHeight, devFundEndHeight); + AddZIP207FundingStream(consensus, Consensus::FS_MG, FS_MG_ADDRESSES, 8, 100, devFundStartHeight, devFundEndHeight); ... } @@ -264,17 +269,23 @@ const Consensus::Params& params, Consensus::FundingStream idx) { - // Integer division is floor division in C++ - auto curPeriod = ( - nHeight + params.nSubsidyPostBlossomHalvingInterval - HeightForHalving(params, 1) - ) / params.nFundingPeriodLength; - auto startPeriod = ( - params.vFundingPeriods[idx].startHeight - + params.nSubsidyPostBlossomHalvingInterval - - HeightForHalving(params, 1) - ) / params.nFundingPeriodLength; + assert(nHeight <= INT_MAX - params.nSubsidyPostBlossomHalvingInterval); + assert(params.vFundingPeriods[idx].startHeight <= INT_MAX - params.nSubsidyPostBlossomHalvingInterval); + + int curPeriodNumerator = nHeight + params.nSubsidyPostBlossomHalvingInterval - HeightForHalving(params, 1); + int startPeriodNumerator = params.vFundingPeriods[idx].startHeight + params.nSubsidyPostBlossomHalvingInterval + - HeightForHalving(params, 1); + + // Integer division is floor division for nonnegative integers in C++ + assert(curPeriodNumerator >= 0); + assert(startPeriodNumerator >= 0); + auto curPeriod = curPeriodNumerator / params.nFundingPeriodLength; + auto startPeriod = startPeriodNumerator / params.nFundingPeriodLength; auto addressIndex = curPeriod - startPeriod; - return params.vFundingPeriods[idx].addresses[addressIndex]; + + auto addresses = params.vFundingPeriods[idx].addresses; + assert(addressIndex >= 0 && addressIndex < addresses.size()); + return addresses[addressIndex]; }; CAmount FundingStreamValue( @@ -282,7 +293,7 @@ const Consensus::Params& params, Consensus::FundingStream idx) { - // Integer division is floor division in C++ + // Integer division is floor division for nonnegative integers in C++ return CAmount(( GetBlockSubsidy(nHeight, params) * params.vFundingPeriods[idx].valueNumerator ) / params.vFundingPeriods[idx].valueDenominator); @@ -293,7 +304,7 @@ const Consensus::Params& params) { std::set<std::pair<CScript, CAmount>> requiredStreams; - for (int idx = Consensus::FS_ZECC_EF; idx < Consensus::MAX_FUNDING_STREAMS; idx++) { + for (int idx = Consensus::FIRST_FUNDING_STREAM; idx < Consensus::MAX_FUNDING_STREAMS; idx++) { // Funding period is [startHeight, endHeight) if (nHeight >= params.vFundingPeriods[idx].startHeight && nHeight < params.vFundingPeriods[idx].endHeight) diff --git a/zip-0207.rst b/zip-0207.rst index 36603514e..fa2bed198 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -224,6 +224,8 @@ Example implementation MAX_FUNDING_STREAMS, }; + const auto FIRST_FUNDING_STREAM = FS_ECC; + struct Params { ... int nFundingPeriodLength; @@ -236,16 +238,17 @@ Example implementation Consensus::FundingStream idx, std::vector addresses, uint64_t valueNumerator, - uint64_t valueDenominator) + uint64_t valueDenominator, + int startHeight, + int endHeight) { assert(valueNumerator < valueDenominator); assert(valueNumerator < INT64_MAX / MAX_MONEY); params.vFundingPeriods[idx].addresses = addresses; params.vFundingPeriods[idx].valueNumerator = valueNumerator; params.vFundingPeriods[idx].valueDenominator = valueDenominator; - params.vFundingPeriods[idx].startHeight = - params.vUpgrades[Consensus::UPGRADE_BLOSSOM].nActivationHeight; - params.vFundingPeriods[idx].endHeight = HeightForHalving(params, 1); + params.vFundingPeriods[idx].startHeight = startHeight; + params.vFundingPeriods[idx].endHeight = endHeight; assert(params.vFundingPeriods[idx].startHeight < params.vFundingPeriods[idx].endHeight); }; @@ -254,9 +257,11 @@ Example implementation consensus.nFundingPeriodLength = consensus.nSubsidyPostBlossomHalvingInterval / 48; - AddZIP207FundingStream(consensus, Consensus::FS_ECC, FS_ECC_ADDRESSES, 7, 100); - AddZIP207FundingStream(consensus, Consensus::FS_ZF, FS_ZF_ADDRESSES, 5, 100); - AddZIP207FundingStream(consensus, Consensus::FS_MG, FS_MG_ADDRESSES, 8, 100); + int devFundStartHeight = HeightForHalving(params, 1); + int devFundEndHeight = HeightForHalving(params, 2); + AddZIP207FundingStream(consensus, Consensus::FS_ECC, FS_ECC_ADDRESSES, 7, 100, devFundStartHeight, devFundEndHeight); + AddZIP207FundingStream(consensus, Consensus::FS_ZF, FS_ZF_ADDRESSES, 5, 100, devFundStartHeight, devFundEndHeight); + AddZIP207FundingStream(consensus, Consensus::FS_MG, FS_MG_ADDRESSES, 8, 100, devFundStartHeight, devFundEndHeight); ... } @@ -266,17 +271,23 @@ Example implementation const Consensus::Params& params, Consensus::FundingStream idx) { - // Integer division is floor division in C++ - auto curPeriod = ( - nHeight + params.nSubsidyPostBlossomHalvingInterval - HeightForHalving(params, 1) - ) / params.nFundingPeriodLength; - auto startPeriod = ( - params.vFundingPeriods[idx].startHeight - + params.nSubsidyPostBlossomHalvingInterval - - HeightForHalving(params, 1) - ) / params.nFundingPeriodLength; + assert(nHeight <= INT_MAX - params.nSubsidyPostBlossomHalvingInterval); + assert(params.vFundingPeriods[idx].startHeight <= INT_MAX - params.nSubsidyPostBlossomHalvingInterval); + + int curPeriodNumerator = nHeight + params.nSubsidyPostBlossomHalvingInterval - HeightForHalving(params, 1); + int startPeriodNumerator = params.vFundingPeriods[idx].startHeight + params.nSubsidyPostBlossomHalvingInterval + - HeightForHalving(params, 1); + + // Integer division is floor division for nonnegative integers in C++ + assert(curPeriodNumerator >= 0); + assert(startPeriodNumerator >= 0); + auto curPeriod = curPeriodNumerator / params.nFundingPeriodLength; + auto startPeriod = startPeriodNumerator / params.nFundingPeriodLength; auto addressIndex = curPeriod - startPeriod; - return params.vFundingPeriods[idx].addresses[addressIndex]; + + auto addresses = params.vFundingPeriods[idx].addresses; + assert(addressIndex >= 0 && addressIndex < addresses.size()); + return addresses[addressIndex]; }; CAmount FundingStreamValue( @@ -284,7 +295,7 @@ Example implementation const Consensus::Params& params, Consensus::FundingStream idx) { - // Integer division is floor division in C++ + // Integer division is floor division for nonnegative integers in C++ return CAmount(( GetBlockSubsidy(nHeight, params) * params.vFundingPeriods[idx].valueNumerator ) / params.vFundingPeriods[idx].valueDenominator); @@ -295,7 +306,7 @@ Example implementation const Consensus::Params& params) { std::set> requiredStreams; - for (int idx = Consensus::FS_ZECC_EF; idx < Consensus::MAX_FUNDING_STREAMS; idx++) { + for (int idx = Consensus::FIRST_FUNDING_STREAM; idx < Consensus::MAX_FUNDING_STREAMS; idx++) { // Funding period is [startHeight, endHeight) if (nHeight >= params.vFundingPeriods[idx].startHeight && nHeight < params.vFundingPeriods[idx].endHeight) From ec7b435480a00e490bcc0636525886fda314fd60 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 27 Mar 2020 00:33:21 +0000 Subject: [PATCH 25/26] ZIPs 208, 250 and 251: keep `NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD` the same in terms of blocks, but it represents 1.5 days for the Heartwood upgrade onward. Signed-off-by: Daira Hopwood --- zip-0208.html | 8 +++++++- zip-0208.rst | 7 ++++++- zip-0250.html | 9 ++++++--- zip-0250.rst | 9 ++++++--- zip-0251.html | 9 ++++++--- zip-0251.rst | 9 ++++++--- 6 files changed, 37 insertions(+), 14 deletions(-) diff --git a/zip-0208.html b/zip-0208.html index 741b8ac41..87b3563ac 100644 --- a/zip-0208.html +++ b/zip-0208.html @@ -180,7 +180,13 @@ static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024; /** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */ -static const unsigned int MIN_BLOCKS_TO_KEEP = 288; +static const unsigned int MIN_BLOCKS_TO_KEEP = 288; + +/** + * 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;
    diff --git a/zip-0208.rst b/zip-0208.rst index 4367f18db..18df47bf1 100644 --- a/zip-0208.rst +++ b/zip-0208.rst @@ -328,7 +328,6 @@ account of cases where the time period that needs to be estimated crosses Blosso activation. - Other block-related constants ''''''''''''''''''''''''''''' @@ -351,6 +350,12 @@ decision was made not to change them:: /** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */ static const unsigned int MIN_BLOCKS_TO_KEEP = 288; + /** + * 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; + Deployment ========== diff --git a/zip-0250.html b/zip-0250.html index a651b7943..d309b0766 100644 --- a/zip-0250.html +++ b/zip-0250.html @@ -51,9 +51,12 @@

    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 three 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). */
-static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
    +

    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:

      diff --git a/zip-0250.rst b/zip-0250.rst index 6186b192f..14d0c99fb 100644 --- a/zip-0250.rst +++ b/zip-0250.rst @@ -73,14 +73,17 @@ Pre-Heartwood testnet nodes are defined as nodes on testnet advertising a protoc 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 three days (defined in terms of +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). */ - static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; + /** + * 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 [#zip-0201]_. diff --git a/zip-0251.html b/zip-0251.html index aec38f660..ae4f6d9e8 100644 --- a/zip-0251.html +++ b/zip-0251.html @@ -53,9 +53,12 @@

      Nodes compatible with ${NU4} activation on testnet MUST advertise protocol version TODO or later. Nodes compatible with ${NU4} activation on mainnet MUST advertise protocol version TODO or later. The minimum peer protocol version that ${NU4}-compatible nodes will connect to is 170002.

      Pre-${NU4} testnet nodes are defined as nodes on testnet advertising a protocol version less than TODO. Pre-${NU4} mainnet nodes are defined as nodes on mainnet advertising a protocol version less than TODO.

      -

      For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding ${NU4} activation height, nodes compatible with ${NU4} activation on that network will change the behaviour of their peer connection logic in order to prefer pre-${NU4} 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). */
-static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
      +

      For each network (testnet and mainnet), approximately 1.5 days (defined in terms of block height) before the corresponding ${NU4} activation height, nodes compatible with ${NU4} activation on that network will change the behaviour of their peer connection logic in order to prefer pre-${NU4} 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 ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to:

        diff --git a/zip-0251.rst b/zip-0251.rst index 35e6befd5..14b114955 100644 --- a/zip-0251.rst +++ b/zip-0251.rst @@ -75,14 +75,17 @@ Pre-${NU4} testnet nodes are defined as nodes on testnet advertising a protocol version less than TODO. Pre-${NU4} mainnet nodes are defined as nodes on mainnet advertising a protocol version less than TODO. -For each network (testnet and mainnet), approximately three days (defined in terms of +For each network (testnet and mainnet), approximately 1.5 days (defined in terms of block height) before the corresponding ${NU4} activation height, nodes compatible with ${NU4} activation on that network will change the behaviour of their peer connection logic in order to prefer pre-${NU4} 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). */ - static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; + /** + * 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 [#zip-0201]_. From 3693c9edd6ee1c77c9be49e3bc6e9f1e9187a7dc Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sat, 11 Apr 2020 20:16:46 +0100 Subject: [PATCH 26/26] ZIP 251: update versions of zcashd that are planned to support NU4. Signed-off-by: Daira Hopwood --- zip-0251.html | 2 +- zip-0251.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0251.html b/zip-0251.html index ae4f6d9e8..465a0b59a 100644 --- a/zip-0251.html +++ b/zip-0251.html @@ -73,7 +73,7 @@

        TODO: delete if inapplicable. Unlike Overwinter and Sapling, and like Blossom and Heartwood, ${NU4} does not define a new transaction version. ${NU4} transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in 2 section 7.1; and use the same transaction digest algorithm as defined in 7. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID. 7

    Support in zcashd

    -

    Support for ${NU4} on testnet will be implemented in zcashd version TODO, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in zcashd version 3.0.0, which will advertise protocol version TODO.

    +

    Support for ${NU4} on testnet will be implemented in zcashd version 3.1.0, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in zcashd version 4.0.0, which will advertise protocol version TODO.

    References

    diff --git a/zip-0251.rst b/zip-0251.rst index 14b114955..da13630df 100644 --- a/zip-0251.rst +++ b/zip-0251.rst @@ -121,9 +121,9 @@ consensus branch ID. [#zip-0243]_ Support in zcashd ================= -Support for ${NU4} on testnet will be implemented in ``zcashd`` version TODO, which +Support for ${NU4} on testnet will be implemented in ``zcashd`` version 3.1.0, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented -in ``zcashd`` version 3.0.0, which will advertise protocol version TODO. +in ``zcashd`` version 4.0.0, which will advertise protocol version TODO. References