ZIP 234: Update specification for DEPLOYMENT_BLOCK_HEIGHT

Co-authored-by: shielded-nate <[email protected]>

zips/zip-0234.md

@@ -58,6 +58,8 @@ Key Objectives:
 4. We want the issuance rate to remain similar to the historical rate for Zcash
    (and before that, Bitcoin).
 5. We want issuance to be easy for all network users to understand and predict.
+6. We want the new issuance to activate at a block with as minimal a delta from
+   the current issuance as possible.
 
 The current Zcash economic model, inherited from Bitcoin, includes a halving
 mechanism that dictates the issuance of new coins. While this has been
@@ -94,11 +96,38 @@ TODO daira: add a requirement that makes the initial total issuance match the pr
 
 # Specification
 
-## Definitions
+## Parameters
 
 `BLOCK_SUBSIDY_FRACTION` = 4126 / 10,000,000,000 or `0.0000004126`
 
-`DEPLOYMENT_BLOCK_HEIGHT` = 2726400
+`DEPLOYMENT_BLOCK_HEIGHT` = `TBD`
+
+The block height will be chosen by the following criteria:
+
+- It is after NU7 activation height.
+- It is calculated to be the lowest height after the the second halving at
+  which the NSM issuance would be less than the current BTC-style issuance
+  _neglecting_ any burnt ZEC (ie. assuming the amount of ZEC burnt is exactly 0).
+
+This selection is intended to achieve Key Objective 6 while still being a
+constant height. An alternative would be to have a dynamic "latch" style
+activation which would calculate the activation height by testing the "less
+than" conditional with every block after the second halving. We prefer the
+pre-defined constant height parameter to give everyone more _time_ certainty at
+the cost of _issuance level_ certainty. The difference in up-front calculation
+versus dynamic calculation is whether or not burns are accounted for (since
+future burns cannot be calculated up-front). This means with the pre-defined
+constant parameter approach, issuance will jump _up_ some amount at activation.
+This amount should be equivalent to all ZEC burnt prior to that height times
+`BLOCK_SUBSIDY_FRACTION`. For example, if a total of 100,000 ZEC were burnt
+prior to the pre-defined constant activation height, then at activation the
+issuance would be larger than BTC-style issuance by `100_000 ZEC *
+BLOCK_SUBSIDY_FRACTION` which we calculate equals `0.04126 ZEC`. This example
+is chosen to demonstrate that a very large burn amount (much larger than
+expected) would elevate issuance by a relatively small amount. For this reason,
+we believe a pre-defined constant is a better approach to achieving Key
+Objective 6 than a "dynamic latch" logic because it is so much simpler to
+implement and reason about.
 
 `MoneyReserveAfter(block_height)` = The value of the Money Reserve after the
 specified block height.
@@ -140,17 +169,6 @@ chose a power-of-10 denominator for simplicity.
 
 TODO for ZIP owners: How many ZEC per day?
 
-## `DEPLOYMENT_BLOCK_HEIGHT`
-
-The deployment should happen at the next halving, which is block `2726400`.
-
-Since there is a planned halving at this point, there will already be a
-significant "shock" caused by the drop in issuance caused by the halving. This
-reduces surprise and thus increases security, satisfying **Requirement 5**.
-Also, due to the nature of the smoothed curve having a portion of the curve
-above the respective step function line at times, this will maximally _reduce_
-the issuance shock at the `DEPLOYMENT_BLOCK_HEIGHT`.
-
 ## Visualization of the Smoothed Curve
 
 The following graph compares issuance for the current halving-based step