From a6d3eed30718ba07a525e94f8f98d783324af765 Mon Sep 17 00:00:00 2001 From: Daira-Emma Hopwood Date: Wed, 19 Feb 2025 23:52:01 +0000 Subject: [PATCH] Re-render HTML. Signed-off-by: Daira-Emma Hopwood --- README.rst | 8 ++-- rendered/index.html | 8 ++-- rendered/zip-0233.html | 94 +++++++++++++++++++++--------------------- rendered/zip-0234.html | 92 +++++++++++++++++++++-------------------- rendered/zip-0235.html | 81 ++++++++++++++++++------------------ 5 files changed, 146 insertions(+), 137 deletions(-) diff --git a/README.rst b/README.rst index e9376841c..5d68a1f79 100644 --- a/README.rst +++ b/README.rst @@ -156,9 +156,9 @@ written. 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Memo Bundles Draft - 233 Network Sustainability Mechanism: Burning Draft + 233 Network Sustainability Mechanism: Removing Funds From Circulation Draft 234 Network Sustainability Mechanism: Issuance Smoothing Draft - 235 Burn 60% of Transaction Fees Draft + 235 Remove 60% of Transaction Fees From Circulation Draft 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft 254 Deployment of the NU7 Network Upgrade Draft 302 Standardized Memo Field Format Draft @@ -283,9 +283,9 @@ Index of ZIPs 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Memo Bundles Draft - 233 Network Sustainability Mechanism: Burning Draft + 233 Network Sustainability Mechanism: Removing Funds From Circulation Draft 234 Network Sustainability Mechanism: Issuance Smoothing Draft - 235 Burn 60% of Transaction Fees Draft + 235 Remove 60% of Transaction Fees From Circulation Draft 236 Blocks should balance exactly Implemented (zcashd and zebrad) 239 Relay of Version 5 Transactions Final 243 Transaction Signature Validation for Sapling Final diff --git a/rendered/index.html b/rendered/index.html index f06b03aa4..c0e79e8d1 100644 --- a/rendered/index.html +++ b/rendered/index.html @@ -111,9 +111,9 @@ 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Memo Bundles Draft - 233 Network Sustainability Mechanism: Burning Draft + 233 Network Sustainability Mechanism: Removing Funds From Circulation Draft 234 Network Sustainability Mechanism: Issuance Smoothing Draft - 235 Burn 60% of Transaction Fees Draft + 235 Remove 60% of Transaction Fees From Circulation Draft 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft 254 Deployment of the NU7 Network Upgrade Draft 302 Standardized Memo Field Format Draft @@ -219,9 +219,9 @@ 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft 231 Memo Bundles Draft - 233 Network Sustainability Mechanism: Burning Draft + 233 Network Sustainability Mechanism: Removing Funds From Circulation Draft 234 Network Sustainability Mechanism: Issuance Smoothing Draft - 235 Burn 60% of Transaction Fees Draft + 235 Remove 60% of Transaction Fees From Circulation Draft 236 Blocks should balance exactly Implemented (zcashd and zebrad) 239 Relay of Version 5 Transactions Final 243 Transaction Signature Validation for Sapling Final diff --git a/rendered/zip-0233.html b/rendered/zip-0233.html index e486657c4..40a964bba 100644 --- a/rendered/zip-0233.html +++ b/rendered/zip-0233.html @@ -1,7 +1,7 @@ - ZIP 233: Network Sustainability Mechanism: Burning + ZIP 233: Network Sustainability Mechanism: Removing Funds From Circulation @@ -10,9 +10,10 @@ 
ZIP: 233
-Title: Network Sustainability Mechanism: Burning
+Title: Network Sustainability Mechanism: Removing Funds From Circulation
 Owners: Jason McGee <jason@shieldedlabs.net>
         Zooko Wilcox <zooko@shieldedlabs.net>
+        Mark Henderson <mark@shieldedlabs.net>
         Tomek Piotrowski <tomek@eiger.co>
         Mariusz Pilarek <mariusz@eiger.co>
         Paul Dann <paul@eiger.co>
@@ -49,9 +50,6 @@ 
Terminology
 
-
“Burning” - The method by which ZEC/TAZ becomes unavailable for circulation
-on the network.

-
 
\(\mathsf{MAX\_MONEY}\), as defined in § 5.3 ‘Constants’ 5,
 is the total ZEC/TAZ supply cap measured in zatoshi, corresponding to
 21,000,000 ZEC. This is slightly larger than the supply cap for the current
@@ -60,11 +58,11 @@ 
TerminologyAbstract 

 
-
This ZIP proposes the introduction of a mechanism to voluntarily burn funds,
-removing those funds entirely from circulation on the network. This mechanism,
-in combination with ZIP 234 6 and ZIP 235 7, comprises a
-long-term strategy for the sustainability of the network. We will refer to the
-combined effects of these three ZIPs as the “Network Sustainability Mechanism”.

+
This ZIP proposes the introduction of a mechanism to voluntarily remove funds
+entirely from circulation on the network. This mechanism, in combination with
+ZIP 234 6 and ZIP 235 7, comprises a long-term strategy for
+the sustainability of the network. We will refer to the combined effects of
+these three ZIPs as the “Network Sustainability Mechanism”.

 
 
Motivation 

 
@@ -72,32 +70,35 @@ 
Motivation\(\mathsf{MAX\_MONEY}\). This lays necessary groundwork for extending the
-block subsidy system, which currently has a clear final end date.
-
  • Benefits to ZEC Holders: Burning funds reduces the supply of ZEC,
-benefiting network users in proportion to their holdings without requiring
-them to opt into any scheme, introducing extra risk, active oversight, or
-accounting complexity.
    • 
+
  • Long Term Consensus Sustainability: By enabling the removal of funds from
+circulation, the network gains the ability to create “headroom” between the
+chain value and \(\mathsf{MAX\_MONEY}\). This lays necessary groundwork for
+extending the block subsidy system, which currently has a clear final end
+date.
    • 
+
  • Benefits to ZEC Holders: Removing funds from circulation reduces the
+circulating supply of ZEC. To the extent that this potentially contributes to
+an increase in the value of remaining ZEC, it can be argued to benefit network
+users in proportion to their holdings — without requiring them to opt into any
+scheme, introducing extra risk, active oversight, or accounting complexity.
    • 
 
 
 
    Specification 
    
 
-
    Burn amount 
    
+
    Transaction Field 
    
 
-
    Each transaction gains a \(\mathsf{burn\_amount}\) property, specifying the
-value in zatoshis that is burned when the transaction is mined. The burned value
-subtracts from the remaining value in the “transparent transaction value pool”
-as described in § 3.4 ‘Transactions and Treestates’ 8.
    
+
    Each transaction gains a \(\mathsf{zip233\_amount}\) property, specifying the
+value in zatoshis that is removed from circulation when the transaction is
+mined. The value removed from circulation subtracts from the remaining value in
+the “transparent transaction value pool” as described in § 3.4 ‘Transactions and
+Treestates’ 8.
    
 
-
    \(\mathsf{burn\_amount}\) does not result in an output being produced in any
+
    \(\mathsf{zip233\_amount}\) does not result in an output being produced in any
 chain value pool, and therefore from the point at which the transaction is
-applied to the global chain state, \(\mathsf{burn\_amount}\) is subtracted from the
-issued supply. It is unavailable for circulation on the network at least through
-to the end of the block in which the transaction is mined. ZIP 234 6
-specifies a potential mechanism by which the burned funds would again become
-available.
    
+applied to the global chain state, \(\mathsf{zip233\_amount}\) is subtracted from
+the issued supply. It is unavailable for circulation on the network at least
+through to the end of the block in which the transaction is mined. ZIP 234
+6 specifies a potential mechanism by which the funds removed from
+circulation would again become available.
    
 
 
    Changes to ZIP 230 9
    
 
@@ -117,22 +118,22 @@ 
    Changes to ZIP 230  Bytes 
 	 Name   
 	 Data Type 
-	 Description            
+	 Description                
 
 
 
 
 
 	 8 
-	 burnAmount 
+	 zip233Amount 
 	 uint64 
-	 The value to be burned in this transaction, in zatoshis. 
+	 The value to be removed from circulation in this transaction, in zatoshis. 
 
 
 
 
-
    The \(\mathsf{burn\_amount}\) of a transaction is defined to be the value of the
-burnAmount field if present, and otherwise 0.
    
+
    The \(\mathsf{zip233\_amount}\) of a transaction is defined to be the value of the
+zip233Amount field if present, and otherwise 0.
    
 
 
    Notes:
    
 
@@ -140,31 +141,32 @@ 
    Changes to ZIP 230 If both this ZIP and ZIP 2002 are selected for inclusion in the same Network
 Upgrade, then the ambiguity in ordering of the fields added by these ZIPs
 would need to be resolved.
-
  • Older transaction versions can continue to be supported after a network upgrade,
-but burning is not possible for these transactions. For example, NU5 supports
-both v4 and v5 transaction formats, for both coinbase and non-coinbase transactions.
    • 
+
  • Older transaction versions can continue to be supported after a network
+upgrade, but removing funds from circulation is not possible for these
+transactions. For example, NU5 supports both v4 and v5 transaction formats,
+for both coinbase and non-coinbase transactions.
    • 
 
 
 
    Changes to the Zcash Protocol Specification 
    
 
 
    Make a change to § 3.4 ‘Transactions and Treestates’ 8
-implementing the specification in Burn amount.
    
+implementing the specification in [ZIP-233 Amount].
    
 
 
    In § 7.1 ‘Transaction Encoding and Consensus’ 11, add:
    
 
 
    
-
    [NU7 onward] \(\mathsf{burn\_amount}\) MUST be in the range \(\{ 0 .. \mathsf{MAX\_MONEY} \}\).
    
+
    [NU7 onward] \(\mathsf{zip233\_amount}\) MUST be in the range \(\{ 0 .. \mathsf{MAX\_MONEY} \}\).
    
 
    
 
 
    Modifications relative to ZIP 244 12
    
 
 
    Relative to the sighash algorithm defined in ZIP 244, the sighash algorithm
 that applies to v6 transactions differs by appending the encoding of
-\(\mathsf{burn\_amount}\) to the Common Transaction Fields that are the input
+\(\mathsf{zip233\_amount}\) to the Common Transaction Fields that are the input
 to the digest in T.1: header_digest 13:
    
 
 
    
-
     T.1f: burn_amount (8-byte little-endian burn amount)
+
     T.1f: zip233_amount (8-byte little-endian amount to remove from circulation)
 
    
 
    
 
@@ -181,11 +183,11 @@ 
    RationaleNew transaction field for burn amount 
    
+
    New transaction field for amount to remove from circulation 
    
 
-
    An explicit value distinguishes the burned ZEC from the transaction fee.
-Explicitness also ensures any arithmetic flaws in any implementations are more
-likely to be observed and caught immediately.
    
+
    An explicit value distinguishes the funds to remove from circulation from
+the transaction fee. Explicitness also ensures any arithmetic flaws in any
+implementations are more likely to be observed and caught immediately.
    
 
 
    Deployment 
    
 
@@ -222,7 +224,7 @@ 
    References
-
    ZIP 235: Burn 60% of Transaction Fees  ↩︎
    
+
    ZIP 235: Remove 60% of Transaction Fees From Circulation  ↩︎
    
 
 
 
  • 
diff --git a/rendered/zip-0234.html b/rendered/zip-0234.html
index 7898fb543..fbdbb35f8 100644
--- a/rendered/zip-0234.html
+++ b/rendered/zip-0234.html
@@ -13,6 +13,7 @@
 Title: Network Sustainability Mechanism: Issuance Smoothing
 Owners: Jason McGee <jason@shieldedlabs.net>
         Zooko Wilcox <zooko@shieldedlabs.net>
+        Mark Henderson <mark@shieldedlabs.net>
         Tomek Piotrowski <tomek@eiger.co>
         Mariusz Pilarek <mariusz@eiger.co>
         Paul Dann <paul@eiger.co>
@@ -45,8 +46,8 @@ 
    Terminology“ZEC/TAZ” refers to the native currency of Zcash on a given network, i.e.
 ZEC on Mainnet and TAZ on Testnet.
    
 
-
    The terms “Block Subsidy”, “Issuance”, and “Burning” are to be interpreted
-as described in ZIP 233. 6
    
+
    The terms “Block Subsidy” and “Issuance” are to be interpreted as described in
+ZIP 233. 6
    
 
 
    Let \(\mathsf{PostBlossomHalvingInterval}\) be as defined in 7.
    
 
@@ -74,8 +75,8 @@ 
    AbstractMotivation 
    
 
@@ -84,8 +85,8 @@ 
    MotivationRequirements
 
  • For any 4-year period, all paid out block subsidies are approximately equal
 to half of the Money Reserve at the beginning of that 4-year period, if no
-ZEC is burned during those 4 years.
    • 
+ZEC is removed from circulation during those 4 years.
    • 
 
  • Decrease the short-term impact of the deployment of this ZIP on block subsidy
 recipients, and minimize the potential reputation risk to Zcash of changing
 the block subsidy amount.
    • 
@@ -137,42 +138,19 @@ 
    Parameters\(\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT} = \mathsf{TBD}\)
    
 
+
    \(\mathsf{MoneyReserveAfter}(\mathsf{height}) =\) The value of the Money Reserve
+after the specified block height.
    
+
 
    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 second halving at
-which the NSM issuance would be less than the current BTC-style issuance
-neglecting any burnt ZEC (i.e. assuming the amount of ZEC burnt is
-exactly 0).
      • 
+
    • It is calculated to be the lowest height after the second halving at which
+the NSM issuance would be less than the current BTC-style issuance neglecting
+any ZEC removed from circulation (i.e. assuming the amount of ZEC removed from
+circulation is exactly 0).
      • 
 
    
 
-
    This selection is intended to achieve Key Objective 6 while still being at
-a constant, predictable 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 in
-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
-\(\mathsf{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\textsf{ ZEC} \cdot \mathsf{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.
    
-
-
    \(\mathsf{MoneyReserveAfter}(\mathsf{height}) =\) The value of the Money Reserve
-after the specified block height.
    
-
 
    Issuance Calculation 
    
 
 
    At the \(\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT}\), nodes should switch from the current issuance
@@ -191,6 +169,31 @@ 
    RationaleParameters 
    
+
+
    The selection is intended to achieve Key Objective 6 while still being at
+a constant, predictable 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
+in whether or not funds removed from circulation are accounted for
+(since funds removed from circulation in the future 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 removed from circulation prior to that height times
+\(\mathsf{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\textsf{ ZEC}
+\cdot \mathsf{BLOCK\_SUBSIDY\_FRACTION}\), which we calculate equals \(0.04126\)
+ZEC. This example is chosen to demonstrate that a very large amount removed from
+circulation (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.
    
+
 
    BLOCK_SUBSIDY_FRACTION 
    
 
 
    Let \(\mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears} = 0.5\).
    
@@ -203,9 +206,9 @@ 
    BLOCK_SUBSIDY_FRAC
 have been issued as block subsidies, thus satisfying Requirement 4.
    
 
 
    The largest possible value in the Money Reserve is \(\mathsf{MAX\_MONEY}\), in the
-theoretically possible case that all issued funds are burned. If this happened,
-the largest interim sum in the block subsidy calculation would be
-\(\mathsf{MAX\_MONEY} \cdot 4126 / 10\_000\_000\_000\).
    
+theoretically possible case that all issued funds are removed from circulation.
+If this happened, the largest interim sum in the block subsidy calculation would
+be \(\mathsf{MAX\_MONEY} \cdot 4126 / 10\_000\_000\_000\).
    
 
 
    This uses 62.91 bits, which is just under the 63-bit limit for signed
 two’s complement 64-bit integer amount types.
    
@@ -243,9 +246,9 @@ 
    Appendix: Simulation<
 
    Last block is 47917869 in ~113.88 years
 
    
 
-
    indicates that, assuming that no ZEC is ever burned, the Money Reserve will be
-depleted after 113.88 years, and the block subsidy will be 0 ZEC after that
-point.
    
+
    indicates that, assuming that no ZEC is ever removed from circulation, the Money
+Reserve will be depleted after 113.88 years, and the block subsidy will be 0 ZEC
+after that point.
    
 
 
    This fragment of the output:
    
 
@@ -266,7 +269,8 @@ 
    Appen
 
    Deployment 
    
 
 
    This ZIP is proposed to activate with Network Upgrade 7. 10
-It MUST be deployed at the same time or after ZIP 233 (“NSM: Burning” 6).
    
+It MUST be deployed at the same time or after ZIP 233 (“NSM: Removing Funds From
+Circulation” 6).
    
 
 
    References 
    
 
diff --git a/rendered/zip-0235.html b/rendered/zip-0235.html
index c893b8541..4865735b5 100644
--- a/rendered/zip-0235.html
+++ b/rendered/zip-0235.html
@@ -1,7 +1,7 @@
 
 
 
-    ZIP 235: Burn 60% of Transaction Fees
+    ZIP 235: Remove 60% of Transaction Fees From Circulation
     
     
     
@@ -10,9 +10,10 @@
 
 
 
    ZIP: 235
-Title: Burn 60% of Transaction Fees
+Title: Remove 60% of Transaction Fees From Circulation
 Owners: Jason McGee <jason@shieldedlabs.net>
         Zooko Wilcox <zooko@shieldedlabs.net>
+        Mark Henderson <mark@shieldedlabs.net>
         Tomek Piotrowski <tomek@eiger.co>
         Mariusz Pilarek <mariusz@eiger.co>
         Paul Dann <paul@eiger.co>
@@ -45,58 +46,59 @@ 
    Terminology“ZEC/TAZ” refers to the native currency of Zcash on a given network, i.e.
 ZEC on Mainnet and TAZ on Testnet.
    
 
-
    The terms “Block Subsidy”, “Issuance”, and “Burning” are to be interpreted
-as described in ZIP 233. 6
    
+
    The terms “Block Subsidy” and “Issuance” are to be interpreted as described in
+ZIP 233. 6
    
 
 
    Abstract 
    
 
-
    This ZIP proposes to burn 60% of transaction fees, while the remaining 40% is
-directed as before, providing a deflationary effect, and building the groundwork
-for long-term support of the Zcash network via the new block subsidy rules
-proposed by ZIP 234 7.
    
+
    This ZIP proposes to remove 60% of transaction fees from circulation, while
+the remaining 40% is directed as before, providing a deflationary effect, and
+building the groundwork for long-term support of the Zcash network via the new
+block subsidy rules proposed by ZIP 234 7.
    
 
 
    Motivation 
    
 
-
    ZIP 233 (“Network Sustainability Mechanism: Burning” 6) describes a
-method by which ZEC can be burned to support network sustainability.
    
+
    ZIP 233 (“Network Sustainability Mechanism: Removing Funds From Circulation”
+6) describes a method by which ZEC can be removed from circulation to
+support network sustainability.
    
 
 
    By introducing a requirement that a certain proportion of transaction fees be
-burned, we ensure that ZEC will be removed from circulating supply to contribute
-to the long-term sustainability of the network as described below:
    
+removed from circulation, we aim to contribute to the long-term sustainability
+of the network as described below:
    
 
 
    Benefits to the Network 
    
 
 
      
 
    1. Network Sustainability: This mechanism involves temporarily reducing the
 supply of ZEC, similar to asset burning in Ethereum’s EIP-1559 8,
-but with long-term sustainability benefits, as the burned funds effectively
-boost future mining rewards, making it an attractive option for current and
-future Zcash users.
      2. 
+but with long-term sustainability benefits, as the funds removed from
+circulation effectively boost future mining rewards, making it an attractive
+option for current and future Zcash users.
 
    2. Incentivizing Transaction Inclusion: By maintaining a 40% share of
 transaction fees for miners, we continue incentivizing miners to prioritize
 including transactions in their blocks. This helps ensure the continued
 efficient processing of transactions and supports a robust and responsive
 network.
      3. 
-
    3. Aligning Interests: Burning transaction fees aligns the interests
-of miners with the long-term health of the network, incentivizing them
-to prioritize security and efficiency. As miners focus on maintaining a
+
    4. Aligning Interests: Removing transaction fees from circulation aligns the
+interests of miners with the long-term health of the network, incentivizing
+them to prioritize security and efficiency. As miners focus on maintaining a
 robust network, overall adoption and usage can increase, leading to higher
 transaction volumes in the long run. This structure discourages short-term
 profit-seeking behaviors, as miners benefit more from a stable and thriving
 ecosystem than from engaging in malicious activities that could undermine the
 network’s reputation and security.
      5. 
-
    5. Future-Proofing the Network: Burning a portion of transaction fees
-is a forward-looking approach that prepares the Zcash network for future
-challenges and opportunities. It establishes a financial buffer that can be
-instrumental in addressing unforeseen issues and seizing strategic advantages
-as the Zcash ecosystem evolves.
      6. 
+
    6. Future-Proofing the Network: Removing a portion of transaction fees from
+circulation is a forward-looking approach that prepares the Zcash network for
+future challenges and opportunities. It establishes a financial buffer that
+can be instrumental in addressing unforeseen issues and seizing strategic
+advantages as the Zcash ecosystem evolves.
      7. 
 
    
 
 
    Requirements 
    
 
 
      
 
    • For each block, at least 60% (rounded down) of the total fees are to be
-burned.
      • 
+removed from circulation.
 
    • No restrictions are placed on the destination of the remaining proportion of
 fees.
      • 
 
    • Any fractions are rounded in favor of the miner.
      • 
@@ -106,7 +108,7 @@ 
      SpecificationConsensus Rule Changes 
      
 
-
      For a given block, the coinbase transaction MUST have a \(\mathsf{burn\_amount}\),
+
      For a given block, the coinbase transaction MUST have a \(\mathsf{zip233\_amount}\),
 as defined in 6, that is greater than or equal to
 \(\mathsf{floor}(\mathsf{transactionFees} \cdot 6 / 10)\).
      
 
@@ -125,14 +127,14 @@ 
      RationaleRationale for requiring the coinbase transaction to be v6 or later 
      
 
-
      There is no explicit mechanism in prior transaction versions to burn the
-required funds. Since \(\mathsf{burn\_amount} = 0\) for transaction versions
-prior to v6, absent the rule about the coinbase transaction version it
-would be technically possible to satisfy the constraint on \(\mathsf{burn\_amount}\)
-with earlier versions than v6, but only when \(\mathsf{transactionFees} = 0\).
-That would introduce a corner case in the transaction consensus rules that
-is not useful, since it is expected that the \(\mathsf{transactionFees}\)
-will normally be non-zero.
      
+
      There is no explicit mechanism in prior transaction versions to remove
+the required funds from circulation. Since \(\mathsf{zip233\_amount} = 0\)
+for transaction versions prior to v6, absent the rule about the coinbase
+transaction version it would be technically possible to satisfy the constraint
+on \(\mathsf{zip233\_amount}\) with earlier versions than v6, but only when
+\(\mathsf{transactionFees} = 0\). That would introduce a corner case in the
+transaction consensus rules that is not useful, since it is expected that the
+\(\mathsf{transactionFees}\) will normally be non-zero.
      
 
 
      Estimated impact on miners 
      
 
@@ -145,7 +147,8 @@ 
      Estimated impact
 Extrapolating to a year, we would expect 351.44 ZEC in fees paid to miners over
 a year.
      
 
-
      If 60% of these fees burned, that would be 210.864 ZEC per year. 11
      
+
      If 60% of these fees are removed from circulation, that would be 210.864 ZEC per
+year. 11
      
 
 
      Considerations for the Future 
      
 
@@ -159,8 +162,8 @@ 
      Considerations
 reconsider the 60/40 split. However, this will likely not be the case for the
 next 8–10 years due to forecasts based on issuance models and network traffic.
      
 
-
      Further ZIPs may be proposed to burn ZEC in various ways to support network
-sustainability, including but not limited to:
      
+
      Further ZIPs may be proposed to remove ZEC from circulation in various ways to
+support network sustainability, including but not limited to: