From 4ebc0f76299c756fa8cdb2b0a8a63fdd340e5e90 Mon Sep 17 00:00:00 2001 From: Andrew Arnott Date: Mon, 31 Jul 2023 07:13:11 -0600 Subject: [PATCH 01/47] Fix identification of HRP for full viewing keys This was likely a copy-paste error with the section above it, which is very similar but presents the human-readable part of *incoming* viewing keys. --- protocol/protocol.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 532d0c933..5b1c15610 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11929,8 +11929,8 @@ for either $\AuthSignPublic$ or $\NullifierKey$, or if $\AuthSignPublic \notin \SubgroupJstar$, or if $\NullifierKey \notin \SubgroupJ$. -For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}. -For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}. +For \fullViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}. +For \fullViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}. } %sapling From af2f3aece441484c3947864a4850d2d12c193a77 Mon Sep 17 00:00:00 2001 From: Andrew Arnott Date: Mon, 31 Jul 2023 07:16:58 -0600 Subject: [PATCH 02/47] Fix reference to undefined LEBS2OS function The `LEBS2OS` function does not exist and isn't meant to. This reference is understood to have meant `LEBS2OSP`. See discussion at: https://forum.zcashcommunity.com/t/what-is-the-lebs2os-function-in-the-zip-32-spec/44886 --- zip-0032.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0032.rst b/zip-0032.rst index fee192572..823fffa9c 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -177,7 +177,7 @@ Sapling helper functions Define * :math:`\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk}) :=`:math:`\mathsf{I2LEOSP}_{256}(\mathsf{ask})`:math:`||\,\mathsf{I2LEOSP}_{256}(\mathsf{nsk})`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}` -* :math:`\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=`:math:`\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))`:math:`||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}` +* :math:`\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=`:math:`\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))`:math:`||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}` Sapling master key generation ----------------------------- From 61654491cebc6a6265997a01a16eb8dccf41a459 Mon Sep 17 00:00:00 2001 From: Andrew Arnott Date: Mon, 31 Jul 2023 07:21:04 -0600 Subject: [PATCH 03/47] Fix ZIP-316 bug in expected `dk` length The `dk` value is 256 bits long. It's the *diversifier* that is only 88 bits long. The incoming viewing key requires the diversifier key -- not the diversifier. This change also reflects the de facto standard in implementations up to this point, including YWallet and the [zcash_address crate](https://docs.rs/zcash_address/latest/src/zcash_address/kind/unified/ivk.rs.html). --- zip-0316.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0316.rst b/zip-0316.rst index f5ec2e1b7..2cc8c3dff 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -431,7 +431,7 @@ The following FVK or IVK Encodings are used in place of the * A Sapling IVK Encoding, also with Typecode :math:`\mathtt{0x02},` is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by - :math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` + :math:`\mathsf{I2LEOSP}_{256}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` * There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be From 43a7ca825729118673c0f007dd0b8247cfcb6953 Mon Sep 17 00:00:00 2001 From: Tomek Piotrowski Date: Wed, 16 Aug 2023 13:06:47 +0200 Subject: [PATCH 04/47] Add Zcash Sustainability Fund ZIP draft --- draft-zsf.md | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 draft-zsf.md diff --git a/draft-zsf.md b/draft-zsf.md new file mode 100644 index 000000000..c5ccbd028 --- /dev/null +++ b/draft-zsf.md @@ -0,0 +1,154 @@ +``` +ZIP: +Title: Establish the Zcash Sustainability Fund on the Protocol Level +Owners: Jason McGee + Mark Henderson + Tomek Piotrowski + Mariusz Pilarek +Original-Authors: Nathan Wilcox +Credits: Nathan Wilcox + Mark Henderson + Jason McGee + Tomek Piotrowski + Mariusz Pilarek +Status: Draft +Category: Ecosystem +Created: 2023-08- +License: BSD-2-Clause +``` + +# Terminology + +The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" 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. [2] + +The term "Block Rewards" refers to the algorithmic +issuance of ZEC to every block's creator -- part of the consensus rules. + +"Issuance" - The method by which unmined or unissued ZEC is converted to ZEC available to users of the network + +"We" - the ZIP authors, owners listed in the above front matter + +"`MAX_MONEY`" is the ZEC supply cap. For simplicity, this ZIP defines it to be `21,000,000 ZEC`, although this is slightly larger than the actual supply cap of the original ZEC issuance mechanism. + +# Abstract + +This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications. + +The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a `ZSF_BALANCE`, and for a new transaction field to be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders. + +# Motivation + +The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks sometihng like this: + +- At Every New Block: + - Miner rewarded via unissued ZEC + - Transaction fees `(inputs - outputs)` + +The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in *bold* below: + +- **Unmined ZEC is now accounted for as `ZSF_BALANCE`** +- **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field** +- Thus, at Every New Block: + - Miner still rewarded **from `ZSF_BALANCE`** + - Transaction fees `(inputs - outputs)`, **including the `ZF_DEPOSIT` amount** + +This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits. + +For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes. + +This ZIP is explicitly agnostic as to the recipients of block rewards so that acceptance or adoption of the Sustainability Fund does not introduce or bundle reallocation decisions with the primary proposal. + +This quite simple alternation has -- in our opinion -- a multitude of benefits: + +1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment and eventually replace block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time. +2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity. +3. **Network Sustainability:** This mechanism involves temporarily reducing the supply of ZEC similar to asset burning in Ethereum's EIP-1559, but with potential long-term sustainability benefits as the redistribution of deposits contributes to issuance rewards and network development, making it an attractive option for current and future Zcash users. +4. **Reduce "Governance Attack Surface":** The proposal's policies aim to enhance predictability, financial sustainability, and minimize governance capture risks, ensuring Zcash's successful evolution as a global currency with a growing userbase and stakeholdership. +5. **Ecosystem Benefits of Longer Time Horizons:** A reliable and long-term functioning Zcash blockchain allows users to make secure long-term plans, leading to a sustainable and virtuous adoption cycle, rather than being influenced by short-term trends. +6. **Consensus Continuity During Lulls:** Rate-limited payouts from the Sustainability Fund help maintain blockchain security during periods of low activity by utilizing savings from high activity periods, whereas direct miner rewards tied to short-term activity may favor miners with significant savings reserves or access to credit, reducing mining competitiveness and overall ecosystem certainty about mining capacity. +7. **Mitigate Payment-to-Self Vulnerabilities:** The risk of miners benefiting from "spoofing" transactions and the desire for a fixed eventual supply goal lead to considering alternatives like the Sustainability Fund, which pays out fees over a long enough time horizon to prevent recouping costs, allowing Zcash to remain closer to its supply goal and offering an alternative to other protocol designs that destroy or burn funds. +8. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below. + +_Disclaimer 1: Long term success depends on the specific mechanisms of deposits, the quantities involved, and broader economic considerations. For such as if the payout rate is both sufficient and not excessive enough to threaten sustainability._ + +# Specification + +In practice, The Zcash Sustainability Fund is a single global balance maintained by the node state and contributed to via a single transaction field. This provides the economic and security support described in the motivation section, while also importantly keeping the fund payouts extremely simple to describe and implement. + +The two modifications are: +1. The re-accounting of unmined ZEC as a node state field called `ZSF_BALANCE` +2. The addition of a transaction field called `ZSF_DEPOSIT` + +Please note that a **network upgrade is required** for this work to be fully implemented. + +## `ZSF_BALANCE` + +Upon activation at height `H`, the ZEC issuance mechanism is permanently suspended, the value of `ZSF_BALANCE[H]` is set to the remainder of unissued ZEC. This must be done before the `Block Rewards Payout Rule` is enforced for the block at height `H`. **This is not a pre-mine.** This is simply a re-accounting of unissued ZEC that comes with the benefit of other possible sources of funding. + +Consensus nodes are then required to track new per-block state: + +- `ZSF_BALANCE[H] : u64 [zatoshi]` + +The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula: + +`TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS` + +This formula holds for all future blocks. It is safe and semantically consistent to consider all blocks prior to the activation height to have a value of `0` in this field. This is not required by this proposal but may be convenient in designs or implementations. + +### `ZSF_BALANCE` Requirements + +- The value of `ZSF_BALANCE` SHOULD equal `0` for all blocks prior to the activation height `H`. +- The above described formula `TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS` MUST hold for all future blocks. +- Future protocol changes MUST NOT reduce or redistribute the funds in the ZSF, and they may not increase the payout rate to a reasonable approximation beyond the four year half-life constraint. + +## `ZSF_DEPOSIT` + +Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF + +This is achieved by adding a new field to all transactions: + +- `ZSF_DEPOSIT : u64 [zatoshi]` + +The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all transactions in the block is added to the balance. + +It is safe and consistent to treat older transactions using pre-Sustainability Fund formats as if they have this field implicitly present with a value of 0 where that simplifies designs or implementations. + +Note: this field is not generally considered an "output" because it differs from other outputs in several significant ways: + +- All `ZSF_DEPOSIT` fields contribute to a single global balance rather than a user-specific output state, +- Consensus validation can account for this field by updating `ZSF_BALANCE[H]` and do not need to track any transaction field specific state after this accounting in contrast to e.g. UTXOs which must be tracked until spent. +- This field does not contribute to the transaction graph of senders or recipients whether transparent or protected by cryptography. + +### `ZSF_DEPOSIT` Requirements + +- There MUST be only one `ZSF_DEPOSIT` field per transaction +- ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well. +- Separate programming language implementations (C++, Rust, etc) MUST guarantee that the calculations described above are consistent + +# Rationale + +All technical decisions in this ZIP are balanced between the necessary robustness of the ZSF mechanics, and simplicity of implementation. + +## `ZSF_BALANCE` as node state + +Tracking the `ZSF_BALANCE` value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications. + +### Alternative: `ZSF_BALANCE` as block header commitment + +An alternative to node state could be to include the `ZSF_BALANCE` field as a block header and require a block header commitment. + +Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value. + +## `ZSF_DEPOSIT` as explicit transaction field + +An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately. + +# References + +**[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)** + +**[2]: [ZIP 200: Network Upgrade Mechanism](https://zips.z.cash/zip-0200)** + +**[3]: [ZIP 225: Version 5 Transaction Format](https://zips.z.cash/zip-0225)** From 22b954c90062e4a2231945e618d83218a1fc0b59 Mon Sep 17 00:00:00 2001 From: Tomek Piotrowski Date: Wed, 16 Aug 2023 23:21:17 +0200 Subject: [PATCH 05/47] Add the ZSF draft HTML --- draft-zsf.html | 273 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 273 insertions(+) create mode 100644 draft-zsf.html diff --git a/draft-zsf.html b/draft-zsf.html new file mode 100644 index 000000000..8c9545b25 --- /dev/null +++ b/draft-zsf.html @@ -0,0 +1,273 @@ + + + + Draft zsf: Establish the Zcash Sustainability Fund on the Protocol Level + + + + + +
ZIP: 
+Title: Establish the Zcash Sustainability Fund on the Protocol Level
+Owners: Jason McGee <jason@shieldedlabs.com>
+        Mark Henderson <mark@equilibrium.co>
+        Tomek Piotrowski <tomek@eiger.co>
+        Mariusz Pilarek <mariusz@eiger.co>
+Original-Authors: Nathan Wilcox
+Credits: Nathan Wilcox
+         Mark Henderson
+         Jason McGee
+         Tomek Piotrowski
+         Mariusz Pilarek
+Status: Draft
+Category: Ecosystem
+Created: 2023-08-
+License: BSD-2-Clause
+

Terminology

+

The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, +“OPTIONAL”, and “REQUIRED” 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. [2]

+

The term “Block Rewards” refers to the algorithmic issuance of ZEC to +every block’s creator – part of the consensus rules.

+

“Issuance” - The method by which unmined or unissued ZEC is converted +to ZEC available to users of the network

+

“We” - the ZIP authors, owners listed in the above front matter

+

“MAX_MONEY” is the ZEC supply cap. For simplicity, this +ZIP defines it to be 21,000,000 ZEC, although this is +slightly larger than the actual supply cap of the original ZEC issuance +mechanism.

+

Abstract

+

This ZIP describes the motivation, the necessary changes for, and the +implementation specifications for the Zcash Sustainability Fund (ZSF). +The ZSF is a proposed alteration to the block rewards system and +accounting of unmined ZEC that allows for other sources of funding +besides unissued ZEC. This new mechanism for deposits – that new +applications or protocol designs can use to strengthen the long-term +sustainability of the network – will likely be an important step for +future economic upgrades, such as a transition to Proof of Stake or +Zcash Shielded Assets, and other potential protocol fees and user +applications.

+

The changes in this ZIP are ultimately minimal, only requiring for +the node to track state in the form of a ZSF_BALANCE, and +for a new transaction field to be added, called +ZSF_DEPOSIT. While wallet developer would be encouraged to +add the ZSF_DEPOSIT field to their UIs, no changes or new +behavior are absolutely required for developers or ZEC holders.

+

Motivation

+

The Zcash network’s operation and development relies fundamentally on +the block reward system inherited from Bitcoin. This system currently +looks sometihng like this:

+
    +
  • At Every New Block: +
      +
    • Miner rewarded via unissued ZEC
      • +
    • Transaction fees (inputs - outputs)
      • +
    • +
+

The Zcash Sustainability Fund is a proposed replacement to that +payout mechanism, with the relevant parts in bold below:

+
    +
  • Unmined ZEC is now accounted for as +ZSF_BALANCE
    • +
  • Transaction includes optional contributions to ZSF via a +ZSF_DEPOSIT field
    • +
  • Thus, at Every New Block: +
      +
    • Miner still rewarded from +ZSF_BALANCE
      • +
    • Transaction fees (inputs - outputs), including +the ZF_DEPOSIT amount
      • +
    • +
+

This design gives similar clarity and algorithmic control benefits, +while also allowing other sources of funds for Block Rewards in addition +to newly issued ZEC, via ZSF Deposits.

+

For example, an end-user wallet application could have an option to +contribute a portion of a transaction to the ZSF, which would be +included in a ZSF_DEPOSIT field in the transaction, to be +taken into account by the Zcash nodes.

+

This ZIP is explicitly agnostic as to the recipients of block rewards +so that acceptance or adoption of the Sustainability Fund does not +introduce or bundle reallocation decisions with the primary +proposal.

+

This quite simple alternation has – in our opinion – a multitude of +benefits:

+
    +
  1. Long Term Consensus Sustainability: This mechanism +supports long-term consensus sustainability by addressing concerns about +the sustainability of the network design shared by Bitcoin-like systems +through the establishment of deposits into the Sustainability Fund to +augment and eventually replace block rewards, ensuring long-term +sustainability as the issuance rate of Zcash drops and newly issued ZEC +decreases over time.
    2. +
  2. Benefits to ZEC Holders: Deposits to the ZSF slow +down the payout of ZEC, temporarily reducing its available supply, +benefiting current holders of unencumbered active ZEC in proportion to +their holdings without requiring them to opt into any scheme, +introducing extra risk, active oversight, or accounting complexity.
    3. +
  3. Network Sustainability: This mechanism involves +temporarily reducing the supply of ZEC similar to asset burning in +Ethereum’s EIP-1559, but with potential long-term sustainability +benefits as the redistribution of deposits contributes to issuance +rewards and network development, making it an attractive option for +current and future Zcash users.
    4. +
  4. Reduce “Governance Attack Surface”: The proposal’s +policies aim to enhance predictability, financial sustainability, and +minimize governance capture risks, ensuring Zcash’s successful evolution +as a global currency with a growing userbase and stakeholdership.
    5. +
  5. Ecosystem Benefits of Longer Time Horizons: A +reliable and long-term functioning Zcash blockchain allows users to make +secure long-term plans, leading to a sustainable and virtuous adoption +cycle, rather than being influenced by short-term trends.
    6. +
  6. Consensus Continuity During Lulls: Rate-limited +payouts from the Sustainability Fund help maintain blockchain security +during periods of low activity by utilizing savings from high activity +periods, whereas direct miner rewards tied to short-term activity may +favor miners with significant savings reserves or access to credit, +reducing mining competitiveness and overall ecosystem certainty about +mining capacity.
    7. +
  7. Mitigate Payment-to-Self Vulnerabilities: The risk +of miners benefiting from “spoofing” transactions and the desire for a +fixed eventual supply goal lead to considering alternatives like the +Sustainability Fund, which pays out fees over a long enough time horizon +to prevent recouping costs, allowing Zcash to remain closer to its +supply goal and offering an alternative to other protocol designs that +destroy or burn funds.
    8. +
  8. Recovery of “Soft-Burned” Funds: In some instances, +such as miners not claim all available rewards, some ZEC goes +unaccounted for though not formally burned. This proposal would recover +it through the ZSF_BALANCE mechanism described below.
    9. +
+

Disclaimer 1: Long term success depends on the specific +mechanisms of deposits, the quantities involved, and broader economic +considerations. For such as if the payout rate is both sufficient and +not excessive enough to threaten sustainability.

+

Specification

+

In practice, The Zcash Sustainability Fund is a single global balance +maintained by the node state and contributed to via a single transaction +field. This provides the economic and security support described in the +motivation section, while also importantly keeping the fund payouts +extremely simple to describe and implement.

+

The two modifications are: 1. The re-accounting of unmined ZEC as a +node state field called ZSF_BALANCE 2. The addition of a +transaction field called ZSF_DEPOSIT

+

Please note that a network upgrade is required for +this work to be fully implemented.

+

ZSF_BALANCE

+

Upon activation at height H, the ZEC issuance mechanism +is permanently suspended, the value of ZSF_BALANCE[H] is +set to the remainder of unissued ZEC. This must be done before the +Block Rewards Payout Rule is enforced for the block at +height H. This is not a pre-mine. This is +simply a re-accounting of unissued ZEC that comes with the benefit of +other possible sources of funding.

+

Consensus nodes are then required to track new per-block state:

+
    +
  • ZSF_BALANCE[H] : u64 [zatoshi]
    • +
+

The state is a single 64 bit integer (representing units of +zatoshi) at any given block height, H, +representing the Sustainability Fund balance at that height, +H. The ZSF_BALANCE can be calculated using the +following formula:

+

TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS

+

This formula holds for all future blocks. It is safe and semantically +consistent to consider all blocks prior to the activation height to have +a value of 0 in this field. This is not required by this +proposal but may be convenient in designs or implementations.

+

ZSF_BALANCE +Requirements

+
    +
  • The value of ZSF_BALANCE SHOULD equal 0 +for all blocks prior to the activation height H.
    • +
  • The above described formula +TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS +MUST hold for all future blocks.
    • +
  • Future protocol changes MUST NOT reduce or redistribute the funds in +the ZSF, and they may not increase the payout rate to a reasonable +approximation beyond the four year half-life constraint.
    • +
+

ZSF_DEPOSIT

+

Each transaction can dedicate some of its excess funds to the ZSF, +and the remainder becomes the miner fee, with any excess miner +fee/reward going to the ZSF

+

This is achieved by adding a new field to all transactions:

+
    +
  • ZSF_DEPOSIT : u64 [zatoshi]
    • +
+

The ZSF_BALANCE[H] for a block at height H +can be calculated given a value of ZSF_BALANCE[H-1] and the +set of transactions contained in that block. First, the +ZSF_DEPOSIT[H] is calculated based solely on +ZSF_BALANCE[H-1]. This is subtracted from the previous +block’s balance to be distributed as part of the block reward. Second, +the sum of all the ZSF_DEPOSIT fields of all transactions +in the block is added to the balance.

+

It is safe and consistent to treat older transactions using +pre-Sustainability Fund formats as if they have this field implicitly +present with a value of 0 where that simplifies designs or +implementations.

+

Note: this field is not generally considered an “output” because it +differs from other outputs in several significant ways:

+
    +
  • All ZSF_DEPOSIT fields contribute to a single global +balance rather than a user-specific output state,
    • +
  • Consensus validation can account for this field by updating +ZSF_BALANCE[H] and do not need to track any transaction +field specific state after this accounting in contrast to e.g. UTXOs +which must be tracked until spent.
    • +
  • This field does not contribute to the transaction graph of senders +or recipients whether transparent or protected by cryptography.
    • +
+

ZSF_DEPOSIT +Requirements

+
    +
  • There MUST be only one ZSF_DEPOSIT field per +transaction
    • +
  • ZIP 225 [3] MUST be updated to include ZSF_DEPOSIT. ZIP +244 MAY be updated as well.
    • +
  • Separate programming language implementations (C++, Rust, etc) MUST +guarantee that the calculations described above are consistent
    • +
+

Rationale

+

All technical decisions in this ZIP are balanced between the +necessary robustness of the ZSF mechanics, and simplicity of +implementation.

+

ZSF_BALANCE as node +state

+

Tracking the ZSF_BALANCE value as a node state using the +above formula is very simple in terms of implementation, and should work +correctly given that the node implementations calculate the value +according to the specifications.

+

Alternative: +ZSF_BALANCE as block header commitment

+

An alternative to node state could be to include the +ZSF_BALANCE field as a block header and require a block +header commitment.

+

Requiring block-header-rooted commitments of global fund balances +such as the Sustainability Fund ensures that any consensus deviating +bugs in accounting of this balance are immediately detected in the +earliest impacted block. It also removes some of the need for explorer +sites and other analytics services from tracking this value +independently, assuming the committed value is made available by common +APIs. This helps ensure that all explorers track and report the correct +value.

+

ZSF_DEPOSIT +as explicit transaction field

+

An explicit value distinguishes the ZEC destined to Sustainability +Fund deposits from the implicit transaction fee. Explicitness also +ensures any arithmetic flaws in any implementations are more likely to +be observed and caught immediately.

+

References

+

[1]: Key words for use in +RFCs to Indicate Requirement Levels

+

[2]: ZIP 200: Network +Upgrade Mechanism

+

[3]: ZIP 225: Version +5 Transaction Format

+ + From 236336ad2faad5cbed30b9c32c03212443fb972f Mon Sep 17 00:00:00 2001 From: Andrew Arnott Date: Thu, 17 Aug 2023 07:45:36 -0600 Subject: [PATCH 06/47] Remove stray " character from ZIP-321 --- zip-0321.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0321.rst b/zip-0321.rst index f595065b7..f71ec0e4c 100644 --- a/zip-0321.rst +++ b/zip-0321.rst @@ -260,7 +260,7 @@ forbidden in ``paramindex``. zcash:?amount=1.234&amount=2.345&address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU - zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU" + zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU Also invalid; duplicate ``amount=`` or ``amount.1=`` fields From 932b81d59d558eb44339df6eea6d27f8011cdc32 Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Tue, 22 Aug 2023 20:30:42 +0100 Subject: [PATCH 07/47] dk is already a byte sequence. --- zip-0316.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0316.rst b/zip-0316.rst index 2cc8c3dff..d4618b050 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -431,7 +431,7 @@ The following FVK or IVK Encodings are used in place of the * A Sapling IVK Encoding, also with Typecode :math:`\mathtt{0x02},` is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by - :math:`\mathsf{I2LEOSP}_{256}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` + :math:`\mathsf{dk}\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` * There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be From 02b7ce4c8a171b304657997b077debd0307b5845 Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Fri, 25 Aug 2023 19:27:33 +0100 Subject: [PATCH 08/47] ZIPs 32, 316, and 321: regenerate HTML. Signed-off-by: Daira Emma Hopwood --- zip-0032.html | 2 +- zip-0316.html | 2 +- zip-0321.html | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0032.html b/zip-0032.html index 2fc55b813..333d780e2 100644 --- a/zip-0032.html +++ b/zip-0032.html @@ -232,7 +232,7 @@
  • \(\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=\) - \(\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))\) + \(\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))\) \(||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))\) \(||\,\mathsf{ovk}\) \(||\,\mathsf{dk}\) diff --git a/zip-0316.html b/zip-0316.html index 6e29c0783..96a4ad61e 100644 --- a/zip-0316.html +++ b/zip-0316.html @@ -250,7 +250,7 @@ is an encoding of \((\mathsf{dk}, \mathsf{ivk})\) given by - \(\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).\) + \(\mathsf{dk}\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).\)
  • There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be diversified in an unlinkable way). The Typecode \(\mathtt{0x01}\) diff --git a/zip-0321.html b/zip-0321.html index 8d95df28c..28e9753d4 100644 --- a/zip-0321.html +++ b/zip-0321.html @@ -121,7 +121,7 @@

    Also invalid; address.0= and amount.0= are not permitted as leading 0s are forbidden in paramindex.

    zcash:?amount=1.234&amount=2.345&address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU
 
-zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU"
    +zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU

    Also invalid; duplicate amount= or amount.1= fields

    zcash:tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1%30
 zcash:tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?%61mount=1

From 497bcc13b12b5fc74830ac16aad104efcb4ee9cf Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Thu, 24 Aug 2023 15:40:46 +0000
Subject: [PATCH 09/47] Bump actions/checkout from 3.5.3 to 3.6.0

Bumps [actions/checkout](https://github.com/actions/checkout) from 3.5.3 to 3.6.0.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v3.5.3...v3.6.0)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] 
---
 .github/workflows/render.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.github/workflows/render.yml b/.github/workflows/render.yml
index 0cd8240a0..8ff554395 100644
--- a/.github/workflows/render.yml
+++ b/.github/workflows/render.yml
@@ -8,7 +8,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Git repository
-        uses: actions/checkout@v3.5.3
+        uses: actions/checkout@v3.6.0
 
       - name: Compile Zcash Protocol Specification
         uses: ./.github/actions/render-protocol-pdf

From 7d2929f21cb21c31715f60da281b1f9178cec455 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 13:29:31 +0200
Subject: [PATCH 10/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index c5ccbd028..68fe526f8 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -85,7 +85,7 @@ Please note that a **network upgrade is required** for this work to be fully imp
 
 ## `ZSF_BALANCE`
 
-Upon activation at height `H`, the ZEC issuance mechanism is permanently suspended, the value of `ZSF_BALANCE[H]` is set to the remainder of unissued ZEC. This must be done before the `Block Rewards Payout Rule` is enforced for the block at height `H`. **This is not a pre-mine.** This is simply a re-accounting of unissued ZEC that comes with the benefit of other possible sources of funding.
+The ZEC issuance mechanism is re-defined to remove funds from `ZSF_BALANCE`, which is initially set to `MAX_MONEY` at the genesis block.
 
 Consensus nodes are then required to track new per-block state:
 

From 9488fce1c67c145dc83d0b4e7d1e33e88320bb15 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 13:31:13 +0200
Subject: [PATCH 11/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 68fe526f8..87fff7a3a 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -38,12 +38,14 @@ This ZIP describes the motivation, the necessary changes for, and the implementa
 
 The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a `ZSF_BALANCE`, and for a new transaction field to be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
 
+This ZIP does not change the current ZEC issuance schedule. Any additional amounts paid into the sustainability fund are reserved for use in future ZIPs.
+
 # Motivation
 
 The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks sometihng like this:
 
 - At Every New Block:
-    - Miner rewarded via unissued ZEC
+    - Miner and funding streams rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
     - Transaction fees `(inputs - outputs)`
 
 The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in *bold* below:
@@ -51,7 +53,7 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
 - **Unmined ZEC is now accounted for as `ZSF_BALANCE`**
 - **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field**
 - Thus, at Every New Block:
-    - Miner still rewarded **from `ZSF_BALANCE`**
+    - Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
     - Transaction fees `(inputs - outputs)`, **including the `ZF_DEPOSIT` amount**
 
 This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.

From c7cad3edb364eb32aecdc29d3914bc0f79eacf06 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 13:35:28 +0200
Subject: [PATCH 12/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 87fff7a3a..a51c4f5bb 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -117,11 +117,9 @@ The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value o
 
 It is safe and consistent to treat older transactions using pre-Sustainability Fund formats as if they have this field implicitly present with a value of 0 where that simplifies designs or implementations.
 
-Note: this field is not generally considered an "output" because it differs from other outputs in several significant ways:
+#### Consensus Rule Changes
 
-- All `ZSF_DEPOSIT` fields contribute to a single global balance rather than a user-specific output state,
-- Consensus validation can account for this field by updating `ZSF_BALANCE[H]` and do not need to track any transaction field specific state after this accounting in contrast to e.g. UTXOs which must be tracked until spent.
-- This field does not contribute to the transaction graph of senders or recipients whether transparent or protected by cryptography.
+- Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction. Transparent outputs **and sustainability fund deposits** remove value from this pool.
 
 ### `ZSF_DEPOSIT` Requirements
 

From 884001107e4d2fad5252392f13085b83d29cb885 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 13:39:58 +0200
Subject: [PATCH 13/47] Update draft-zsf.md

Co-authored-by: Daira Emma Hopwood 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index a51c4f5bb..a346d8a2a 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -97,7 +97,7 @@ The state is a single 64 bit integer (representing units of `zatoshi`) at any gi
 
 `TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS`
 
-This formula holds for all future blocks. It is safe and semantically consistent to consider all blocks prior to the activation height to have a value of `0` in this field. This is not required by this proposal but may be convenient in designs or implementations.
+This formula holds for all blocks.
 
 ### `ZSF_BALANCE` Requirements
 

From e085c88a6dd02b13ac6069a3a46a3780082dadcc Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 13:57:29 +0200
Subject: [PATCH 14/47] Remove restriction on future protocol changes

---
 draft-zsf.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index a346d8a2a..af70cd4af 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -103,7 +103,6 @@ This formula holds for all blocks.
 
 - The value of `ZSF_BALANCE` SHOULD equal `0` for all blocks prior to the activation height `H`. 
 - The above described formula `TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS` MUST hold for all future blocks.
-- Future protocol changes MUST NOT reduce or redistribute the funds in the ZSF, and they may not increase the payout rate to a reasonable approximation beyond the four year half-life constraint.
 
 ## `ZSF_DEPOSIT`
 

From c48f5b1d025c8053fe093efb1d9cd888f63208cc Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 14:26:11 +0200
Subject: [PATCH 15/47] Slim down the motivation section

---
 draft-zsf.md | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index af70cd4af..4b028fa25 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -64,16 +64,9 @@ This ZIP is explicitly agnostic as to the recipients of block rewards so that ac
 
 This quite simple alternation has -- in our opinion -- a multitude of benefits:
 
-1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment and eventually replace block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
+1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
 2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.
-3. **Network Sustainability:** This mechanism involves temporarily reducing the supply of ZEC similar to asset burning in Ethereum's EIP-1559, but with potential long-term sustainability benefits as the redistribution of deposits contributes to issuance rewards and network development, making it an attractive option for current and future Zcash users.
-4. **Reduce "Governance Attack Surface":** The proposal's policies aim to enhance predictability, financial sustainability, and minimize governance capture risks, ensuring Zcash's successful evolution as a global currency with a growing userbase and stakeholdership.
-5. **Ecosystem Benefits of Longer Time Horizons:** A reliable and long-term functioning Zcash blockchain allows users to make secure long-term plans, leading to a sustainable and virtuous adoption cycle, rather than being influenced by short-term trends.
-6. **Consensus Continuity During Lulls:** Rate-limited payouts from the Sustainability Fund help maintain blockchain security during periods of low activity by utilizing savings from high activity periods, whereas direct miner rewards tied to short-term activity may favor miners with significant savings reserves or access to credit, reducing mining competitiveness and overall ecosystem certainty about mining capacity.
-7. **Mitigate Payment-to-Self Vulnerabilities:** The risk of miners benefiting from "spoofing" transactions and the desire for a fixed eventual supply goal lead to considering alternatives like the Sustainability Fund, which pays out fees over a long enough time horizon to prevent recouping costs, allowing Zcash to remain closer to its supply goal and offering an alternative to other protocol designs that destroy or burn funds.
-8. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below.
-
-_Disclaimer 1: Long term success depends on the specific mechanisms of deposits, the quantities involved, and broader economic considerations. For such as if the payout rate is both sufficient and not excessive enough to threaten sustainability._
+3. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below.
 
 # Specification
 

From af56e30d5137b97889c9fe15d1bf37c9f70fd853 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 15:13:28 +0200
Subject: [PATCH 16/47] Update the ZSF balance formula

---
 draft-zsf.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 4b028fa25..7967803b3 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -88,9 +88,9 @@ Consensus nodes are then required to track new per-block state:
 
 The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
 
-`TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS`
+`ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
 
-This formula holds for all blocks.
+where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height. 
 
 ### `ZSF_BALANCE` Requirements
 

From dbab6a63c7060ff2fa9f36bf806b4ebe5a2ce2c0 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 15:13:56 +0200
Subject: [PATCH 17/47] Remove redundant requirements

---
 draft-zsf.md | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 7967803b3..b7c9a9fcb 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -92,11 +92,6 @@ The state is a single 64 bit integer (representing units of `zatoshi`) at any gi
 
 where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height. 
 
-### `ZSF_BALANCE` Requirements
-
-- The value of `ZSF_BALANCE` SHOULD equal `0` for all blocks prior to the activation height `H`. 
-- The above described formula `TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS` MUST hold for all future blocks.
-
 ## `ZSF_DEPOSIT`
 
 Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF

From 15542d7737550e1e3bbcf11f831ed07df9049e42 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 15:51:43 +0200
Subject: [PATCH 18/47] ZSF_DEPOSIT in older non-coinbase transactions

Co-authored-by: teor 
---
 draft-zsf.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index b7c9a9fcb..7bc4b2aa7 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -102,7 +102,10 @@ This is achieved by adding a new field to all transactions:
 
 The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all transactions in the block is added to the balance.
 
-It is safe and consistent to treat older transactions using pre-Sustainability Fund formats as if they have this field implicitly present with a value of 0 where that simplifies designs or implementations.
+
+### Non-Coinbase Transactions
+
+If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is defined to be zero for non-coinbase transactions.
 
 #### Consensus Rule Changes
 

From f5462c7ed77226b3549eee02ef482075ab68a328 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 16:38:51 +0200
Subject: [PATCH 19/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 7bc4b2aa7..8f3e442c4 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -96,7 +96,7 @@ where Unclaimed(height) is the portion of the block subsidy that is unclaimed fo
 
 Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
 
-This is achieved by adding a new field to all transactions:
+This is achieved by adding a new field to the common transaction fields [#zip-0225-transaction-format]:
 
 - `ZSF_DEPOSIT : u64 [zatoshi]`
 

From 3437abe31ae21737f2717153eed0bcc7deb01531 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 16:39:00 +0200
Subject: [PATCH 20/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 8f3e442c4..af6d86b0c 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -113,7 +113,6 @@ If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is
 
 ### `ZSF_DEPOSIT` Requirements
 
-- There MUST be only one `ZSF_DEPOSIT` field per transaction
 - ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
 - Separate programming language implementations (C++, Rust, etc) MUST guarantee that the calculations described above are consistent
 

From 0374cb489c7c88ef8a323bdad96ed658d46f926d Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 16:39:48 +0200
Subject: [PATCH 21/47] Update draft-zsf.md

Co-authored-by: Daira Emma Hopwood 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index af6d86b0c..a83974dd3 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -98,7 +98,7 @@ Each transaction can dedicate some of its excess funds to the ZSF, and the remai
 
 This is achieved by adding a new field to the common transaction fields [#zip-0225-transaction-format]:
 
-- `ZSF_DEPOSIT : u64 [zatoshi]`
+- `zsfDeposit : u64 [zatoshi]`
 
 The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all transactions in the block is added to the balance.
 

From 8c7dd069f085ca9c16d861f2f745a1eb4b813bea Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 31 Aug 2023 16:45:12 +0200
Subject: [PATCH 22/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index a83974dd3..566b835d9 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -60,7 +60,6 @@ This design gives similar clarity and algorithmic control benefits, while also a
 
 For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes.
 
-This ZIP is explicitly agnostic as to the recipients of block rewards so that acceptance or adoption of the Sustainability Fund does not introduce or bundle reallocation decisions with the primary proposal.
 
 This quite simple alternation has -- in our opinion -- a multitude of benefits:
 

From dd179887c4c22b2fa212a4bc33aca116c5e94c82 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Fri, 1 Sep 2023 09:02:28 +0200
Subject: [PATCH 23/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 566b835d9..879b6e4c3 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -113,7 +113,6 @@ If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is
 ### `ZSF_DEPOSIT` Requirements
 
 - ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
-- Separate programming language implementations (C++, Rust, etc) MUST guarantee that the calculations described above are consistent
 
 # Rationale
 

From 73f879a930a00efeaf62fc2cbefc97f1d1acc58e Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Fri, 1 Sep 2023 09:05:09 +0200
Subject: [PATCH 24/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/draft-zsf.md b/draft-zsf.md
index 879b6e4c3..93ad4eb1f 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -110,6 +110,17 @@ If the `ZSF_DEPOSIT` field is not present in an older transaction version, it is
 
 - Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction. Transparent outputs **and sustainability fund deposits** remove value from this pool.
 
+### Coinbase Transactions
+
+Any excess miner fee/reward is sent to the ZSF.
+
+In new blocks, this deposit is tracked via the `ZSF_DEPOSIT` field in coinbase transactions. 
+
+If the `ZSF_DEPOSIT` field is not present in a coinbase transaction with an older transaction version, it is defined as the value of any unspent miner fee and miner reward. This re-defines these previously unspendable funds as ZSF deposits.
+
+#### Consensus Rule Changes
+
+-  The remaining value in the transparent transaction value pool of a coinbase transaction is **deposited in the sustainability fund**.
 ### `ZSF_DEPOSIT` Requirements
 
 - ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.

From 903c7d54f1cd364f588078b18a558e1b1ce7ebc0 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Fri, 1 Sep 2023 09:06:52 +0200
Subject: [PATCH 25/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 93ad4eb1f..09fbb4c81 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -133,9 +133,9 @@ All technical decisions in this ZIP are balanced between the necessary robustnes
 
 Tracking the `ZSF_BALANCE` value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications.
 
-### Alternative: `ZSF_BALANCE` as block header commitment
+### Committing to `ZsfBalanceAfter` in the block header
 
-An alternative to node state could be to include the `ZSF_BALANCE` field as a block header and require a block header commitment.
+The `ZsfBalanceAfter` node state has a block header commitment as specified above.
 
 Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value.
 

From d7e5b28c251b1623183c844bab940a93205fa3b9 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Fri, 1 Sep 2023 10:33:55 +0200
Subject: [PATCH 26/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/draft-zsf.md b/draft-zsf.md
index 09fbb4c81..a630785dc 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -88,7 +88,9 @@ Consensus nodes are then required to track new per-block state:
 The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
 
 `ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
+The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block commitment in the block header, at the end of the `hashBlockCommitments` chain in [ZIP-244](https://zips.z.cash/zip-0244#block-header-changes).
 
+TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
 where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height. 
 
 ## `ZSF_DEPOSIT`

From 06b77c8154cf49af7e27b7362277039c99bc84f4 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Fri, 1 Sep 2023 10:43:54 +0200
Subject: [PATCH 27/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/draft-zsf.md b/draft-zsf.md
index a630785dc..d8fb581de 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -145,6 +145,11 @@ Requiring block-header-rooted commitments of global fund balances such as the Su
 
 An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately.
 
+# Deployment
+
+This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors).
+
+The `ZsfBalanceAfter` node state commitment will be included in the `hashBlockCommitments` chain starting with the network upgrade activation block.
 # References
 
 **[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)**

From 1e2cec00c5caa841d7adf557dfc42941d4b55ded Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Fri, 1 Sep 2023 10:51:42 +0200
Subject: [PATCH 28/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index d8fb581de..75a3ad388 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -93,7 +93,19 @@ The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block c
 TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
 where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height. 
 
-## `ZSF_DEPOSIT`
+## Deposits into the Sustainability Fund
+
+Sustainability fund deposits can be made via a new `zsfDeposit` field. This can be done by:
+- ZEC fund holders, in non-coinbase transactions;
+- Zcash miners, in coinbase transactions.
+
+In transaction versions without this new field:
+- unclaimed miner fees and rewards in **coinbase transactions** are re-defined as deposits into the sustainability fund, and
+- there are no sustainability fund deposits from non-coinbase transactions.
+
+Note: older transaction versions can continue to be supported after a network upgrade. For example, NU5 supports both v4 and v5 transaction formats, for both coinbase and non-coinbase transactions.
+
+### `zsfDeposit` fields in transactions
 
 Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
 

From eb91d2b3f3fed32109730a95d8b84fedaca80153 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Fri, 1 Sep 2023 14:21:49 +0200
Subject: [PATCH 29/47] draft-zsf.md updates

---
 draft-zsf.md | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 75a3ad388..03b6934bd 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -42,11 +42,11 @@ This ZIP does not change the current ZEC issuance schedule. Any additional amoun
 
 # Motivation
 
-The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks sometihng like this:
+The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks like this:
 
 - At Every New Block:
-    - Miner and funding streams rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
-    - Transaction fees `(inputs - outputs)`
+    - Miner and funding streams are rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
+    - Miner is rewarded via Transaction fees `(inputs - outputs)`
 
 The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in *bold* below:
 
@@ -54,7 +54,7 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
 - **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field**
 - Thus, at Every New Block:
     - Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
-    - Transaction fees `(inputs - outputs)`, **including the `ZF_DEPOSIT` amount**
+    - Miner is rewarded via Transaction fees `(inputs - outputs)`, **including the `ZSF_DEPOSIT` amount**
 
 This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
 
@@ -88,14 +88,15 @@ Consensus nodes are then required to track new per-block state:
 The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
 
 `ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
+where `Unclaimed(height)` is the portion of the block subsidy that is unclaimed for the block at the given height. 
+
 The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block commitment in the block header, at the end of the `hashBlockCommitments` chain in [ZIP-244](https://zips.z.cash/zip-0244#block-header-changes).
 
 TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
-where Unclaimed(height) is the portion of the block subsidy that is unclaimed for the block at the given height. 
 
 ## Deposits into the Sustainability Fund
 
-Sustainability fund deposits can be made via a new `zsfDeposit` field. This can be done by:
+Sustainability fund deposits can be made via the new `zsfDeposit` field. This can be done by:
 - ZEC fund holders, in non-coinbase transactions;
 - Zcash miners, in coinbase transactions.
 
@@ -135,9 +136,11 @@ If the `ZSF_DEPOSIT` field is not present in a coinbase transaction with an olde
 #### Consensus Rule Changes
 
 -  The remaining value in the transparent transaction value pool of a coinbase transaction is **deposited in the sustainability fund**.
+
 ### `ZSF_DEPOSIT` Requirements
 
-- ZIP 225 [3] MUST be updated to include `ZSF_DEPOSIT`. ZIP 244 MAY be updated as well.
+- ZIP 230 [3] must be updated to include `ZSF_DEPOSIT`.
+- ZIP 244 [4] must be updated as well to include `ZSF_DEPOSIT`.
 
 # Rationale
 
@@ -168,4 +171,6 @@ The `ZsfBalanceAfter` node state commitment will be included in the `hashBlockCo
 
 **[2]: [ZIP 200: Network Upgrade Mechanism](https://zips.z.cash/zip-0200)**
 
-**[3]: [ZIP 225: Version 5 Transaction Format](https://zips.z.cash/zip-0225)**
+**[3]: [ZIP 230: v6 transactions, including ZSAs](https://github.com/zcash/zips/pull/687)**
+
+**[4]: [ZIP 244: Transaction Identifier Non-Malleability](https://zips.z.cash/zip-0244)**

From e5d2cca34b2e227ef088ea1fcaa1b323e06a7757 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 19 Sep 2023 09:39:33 -0400
Subject: [PATCH 30/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 03b6934bd..d1a4092b6 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -60,8 +60,7 @@ This design gives similar clarity and algorithmic control benefits, while also a
 
 For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes.
 
-
-This quite simple alternation has -- in our opinion -- a multitude of benefits:
+This quite simple alteration has -- in our opinion -- a multitude of benefits:
 
 1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
 2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.

From 85df0478b4fde633abd897b8594e2835bff96b31 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 19 Sep 2023 09:39:52 -0400
Subject: [PATCH 31/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index d1a4092b6..8f4d69361 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -54,7 +54,7 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
 - **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field**
 - Thus, at Every New Block:
     - Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
-    - Miner is rewarded via Transaction fees `(inputs - outputs)`, **including the `ZSF_DEPOSIT` amount**
+    - Miner is rewarded via Transaction fees `(inputs - outputs)`, **where `outputs` includes the `ZSF_DEPOSIT` amount**
 
 This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
 

From bb4835b98928e848d902a9e7dd8abb7446e2831a Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 19 Sep 2023 09:40:16 -0400
Subject: [PATCH 32/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 8f4d69361..83e2beba4 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -74,8 +74,6 @@ The two modifications are:
 1. The re-accounting of unmined ZEC as a node state field called `ZSF_BALANCE`
 2. The addition of a transaction field called `ZSF_DEPOSIT`
 
-Please note that a **network upgrade is required** for this work to be fully implemented.
-
 ## `ZSF_BALANCE`
 
 The ZEC issuance mechanism is re-defined to remove funds from `ZSF_BALANCE`, which is initially set to `MAX_MONEY` at the genesis block.

From 450d47ba63fcc99a32a755973d53aa2202d6cf67 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 19 Sep 2023 09:40:36 -0400
Subject: [PATCH 33/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 83e2beba4..37af1ea75 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -56,8 +56,6 @@ The Zcash Sustainability Fund is a proposed replacement to that payout mechanism
     - Miner and funding streams rewarded the same constant amount, **but from `ZSF_BALANCE`** (this constant amount still halves at specified heights)
     - Miner is rewarded via Transaction fees `(inputs - outputs)`, **where `outputs` includes the `ZSF_DEPOSIT` amount**
 
-This design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
-
 For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a `ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash nodes.
 
 This quite simple alteration has -- in our opinion -- a multitude of benefits:

From ccd9eba4328521cac66f2dfa57a5af98c259fa98 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 19 Sep 2023 09:40:49 -0400
Subject: [PATCH 34/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/draft-zsf.md b/draft-zsf.md
index 37af1ea75..62336c795 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -160,6 +160,7 @@ An explicit value distinguishes the ZEC destined to Sustainability Fund deposits
 This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors).
 
 The `ZsfBalanceAfter` node state commitment will be included in the `hashBlockCommitments` chain starting with the network upgrade activation block.
+
 # References
 
 **[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)**

From eac8efabf3b8c15d6660bd11b8cc73245fa44647 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 19 Sep 2023 09:41:04 -0400
Subject: [PATCH 35/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 62336c795..953a3b252 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -34,7 +34,7 @@ issuance of ZEC to every block's creator -- part of the consensus rules.
 
 # Abstract 
 
-This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network  -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
+This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
 
 The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a `ZSF_BALANCE`, and for a new transaction field to be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
 

From d6cd39f665a9573fdfa6ec2da729e4bcd0724598 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 19 Sep 2023 09:41:29 -0400
Subject: [PATCH 36/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 953a3b252..cc505ce70 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -6,11 +6,7 @@ Owners: Jason McGee 
         Tomek Piotrowski 
         Mariusz Pilarek 
 Original-Authors: Nathan Wilcox
-Credits: Nathan Wilcox
-         Mark Henderson
-         Jason McGee
-         Tomek Piotrowski
-         Mariusz Pilarek
+Credits:
 Status: Draft
 Category: Ecosystem
 Created: 2023-08-

From 2e5f3902ef33002b646d64ed564648743ea9fb3b Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Wed, 27 Sep 2023 12:03:48 -0400
Subject: [PATCH 37/47] Update draft-zsf.md

Co-authored-by: teor 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index cc505ce70..1e8d60676 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -79,7 +79,7 @@ Consensus nodes are then required to track new per-block state:
 The state is a single 64 bit integer (representing units of `zatoshi`) at any given block height, ``H``, representing the Sustainability Fund balance at that height, ``H``. The `ZSF_BALANCE` can be calculated using the following formula:
 
 `ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))`
-where `Unclaimed(height)` is the portion of the block subsidy that is unclaimed for the block at the given height. 
+where `Unclaimed(height)` is the portion of the block subsidy and miner fees that are unclaimed for the block at the given height. 
 
 The block at height `H` commits to `ZsfBalanceAfter(H)` as part of a new block commitment in the block header, at the end of the `hashBlockCommitments` chain in [ZIP-244](https://zips.z.cash/zip-0244#block-header-changes).
 

From 904c7afb9cd15d2619058427dde3fc22031b9bf3 Mon Sep 17 00:00:00 2001
From: Mark Henderson 
Date: Wed, 27 Sep 2023 12:10:18 -0400
Subject: [PATCH 38/47] chore: ZIP html

---
 draft-zsf.html | 337 +++++++++++++------------------------------------
 draft-zsf.md   |   3 +-
 2 files changed, 91 insertions(+), 249 deletions(-)

diff --git a/draft-zsf.html b/draft-zsf.html
index 8c9545b25..7c7ee08d6 100644
--- a/draft-zsf.html
+++ b/draft-zsf.html
@@ -1,273 +1,116 @@
-
-
-
-    Draft zsf: Establish the Zcash Sustainability Fund on the Protocol Level
-    
-    
-    
-
-
-
    ZIP: 
+
    ZIP: 
 Title: Establish the Zcash Sustainability Fund on the Protocol Level
 Owners: Jason McGee <jason@shieldedlabs.com>
         Mark Henderson <mark@equilibrium.co>
         Tomek Piotrowski <tomek@eiger.co>
         Mariusz Pilarek <mariusz@eiger.co>
 Original-Authors: Nathan Wilcox
-Credits: Nathan Wilcox
-         Mark Henderson
-         Jason McGee
-         Tomek Piotrowski
-         Mariusz Pilarek
+Credits:
 Status: Draft
 Category: Ecosystem
 Created: 2023-08-
-License: BSD-2-Clause
    
-
    Terminology
    
-
    The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”,
-“OPTIONAL”, and “REQUIRED” 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. [2]
    
-
    The term “Block Rewards” refers to the algorithmic issuance of ZEC to
-every block’s creator – part of the consensus rules.
    
-
    “Issuance” - The method by which unmined or unissued ZEC is converted
-to ZEC available to users of the network
    
-
    “We” - the ZIP authors, owners listed in the above front matter
    
-
    “MAX_MONEY” is the ZEC supply cap. For simplicity, this
-ZIP defines it to be 21,000,000 ZEC, although this is
-slightly larger than the actual supply cap of the original ZEC issuance
-mechanism.
    
-
    Abstract
    
-
    This ZIP describes the motivation, the necessary changes for, and the
-implementation specifications for the Zcash Sustainability Fund (ZSF).
-The ZSF is a proposed alteration to the block rewards system and
-accounting of unmined ZEC that allows for other sources of funding
-besides unissued ZEC. This new mechanism for deposits – that new
-applications or protocol designs can use to strengthen the long-term
-sustainability of the network – will likely be an important step for
-future economic upgrades, such as a transition to Proof of Stake or
-Zcash Shielded Assets, and other potential protocol fees and user
-applications.
    
-
    The changes in this ZIP are ultimately minimal, only requiring for
-the node to track state in the form of a ZSF_BALANCE, and
-for a new transaction field to be added, called
-ZSF_DEPOSIT. While wallet developer would be encouraged to
-add the ZSF_DEPOSIT field to their UIs, no changes or new
-behavior are absolutely required for developers or ZEC holders.
    
-
    Motivation
    
-
    The Zcash network’s operation and development relies fundamentally on
-the block reward system inherited from Bitcoin. This system currently
-looks sometihng like this:
    
+License: BSD-2-Clause
    
+
    Terminology
    
+
    The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" 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. [2]
    
+
    "Block Subsidy” - the algorithmic issuance of ZEC on block creation – part of the consensus rules. Split between the miner and the Dev Fund. Also known as Block Reward.
    
+
    "Issuance" - The method by which unmined or unissued ZEC is converted to ZEC available to users of the network
    
+
    "We" - the ZIP authors, owners listed in the above front matter
    
+
    "MAX_MONEY" is the ZEC supply cap. For simplicity, this ZIP defines it to be 21,000,000 ZEC, although this is slightly larger than the actual supply cap of the original ZEC issuance mechanism.
    
+
    Abstract
    
+
    This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits -- that new applications or protocol designs can use to strengthen the long-term sustainability of the network -- will likely be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
    
+
    The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a ZSF_BALANCE, and for a new transaction field to be added, called ZSF_DEPOSIT. While wallet developer would be encouraged to add the ZSF_DEPOSIT field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
    
+
    This ZIP does not change the current ZEC issuance schedule. Any additional amounts paid into the sustainability fund are reserved for use in future ZIPs.
    
+
    Motivation
    
+
    The Zcash network's operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks like this:
    
 
      
-
    • At Every New Block:
-
        
-
      • Miner rewarded via unissued ZEC
        • 
-
      • Transaction fees (inputs - outputs)
        • 
-
      • 
+
    • At Every New Block:
        
+
      • Miner and funding streams are rewarded a constant amount via unissued ZEC (this constant amount halves at specified heights)
        • 
+
      • Miner is rewarded via Transaction fees (inputs - outputs)
        • 
 
      
-
      The Zcash Sustainability Fund is a proposed replacement to that
-payout mechanism, with the relevant parts in bold below:
      
-
        
-
      • Unmined ZEC is now accounted for as
-ZSF_BALANCE
        • 
-
      • Transaction includes optional contributions to ZSF via a
-ZSF_DEPOSIT field
        • 
-
      • Thus, at Every New Block:
+
        • 
+
      
+
      The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in bold below:
      
 
        
-
      • Miner still rewarded from
-ZSF_BALANCE
        • 
-
      • Transaction fees (inputs - outputs), including
-the ZF_DEPOSIT amount
        • 
-
      • 
+
    • Unmined ZEC is now accounted for as ZSF_BALANCE
      • 
+
    • Transaction includes optional contributions to ZSF via a ZSF_DEPOSIT field
      • 
+
    • Thus, at Every New Block:
        
+
      • Miner and funding streams rewarded the same constant amount, but from ZSF_BALANCE (this constant amount still halves at specified heights)
        • 
+
      • Miner is rewarded via Transaction fees (inputs - outputs), where outputs includes the ZSF_DEPOSIT amount
        • 
+
      
+
      • 
 
    
-
    This design gives similar clarity and algorithmic control benefits,
-while also allowing other sources of funds for Block Rewards in addition
-to newly issued ZEC, via ZSF Deposits.
    
-
    For example, an end-user wallet application could have an option to
-contribute a portion of a transaction to the ZSF, which would be
-included in a ZSF_DEPOSIT field in the transaction, to be
-taken into account by the Zcash nodes.
    
-
    This ZIP is explicitly agnostic as to the recipients of block rewards
-so that acceptance or adoption of the Sustainability Fund does not
-introduce or bundle reallocation decisions with the primary
-proposal.
    
-
    This quite simple alternation has – in our opinion – a multitude of
-benefits:
    
-
      
-
    1. Long Term Consensus Sustainability: This mechanism
-supports long-term consensus sustainability by addressing concerns about
-the sustainability of the network design shared by Bitcoin-like systems
-through the establishment of deposits into the Sustainability Fund to
-augment and eventually replace block rewards, ensuring long-term
-sustainability as the issuance rate of Zcash drops and newly issued ZEC
-decreases over time.
      2. 
-
    2. Benefits to ZEC Holders: Deposits to the ZSF slow
-down the payout of ZEC, temporarily reducing its available supply,
-benefiting current holders of unencumbered active ZEC in proportion to
-their holdings without requiring them to opt into any scheme,
-introducing extra risk, active oversight, or accounting complexity.
      3. 
-
    3. Network Sustainability: This mechanism involves
-temporarily reducing the supply of ZEC similar to asset burning in
-Ethereum’s EIP-1559, but with potential long-term sustainability
-benefits as the redistribution of deposits contributes to issuance
-rewards and network development, making it an attractive option for
-current and future Zcash users.
      4. 
-
    4. Reduce “Governance Attack Surface”: The proposal’s
-policies aim to enhance predictability, financial sustainability, and
-minimize governance capture risks, ensuring Zcash’s successful evolution
-as a global currency with a growing userbase and stakeholdership.
      5. 
-
    5. Ecosystem Benefits of Longer Time Horizons: A
-reliable and long-term functioning Zcash blockchain allows users to make
-secure long-term plans, leading to a sustainable and virtuous adoption
-cycle, rather than being influenced by short-term trends.
      6. 
-
    6. Consensus Continuity During Lulls: Rate-limited
-payouts from the Sustainability Fund help maintain blockchain security
-during periods of low activity by utilizing savings from high activity
-periods, whereas direct miner rewards tied to short-term activity may
-favor miners with significant savings reserves or access to credit,
-reducing mining competitiveness and overall ecosystem certainty about
-mining capacity.
      7. 
-
    7. Mitigate Payment-to-Self Vulnerabilities: The risk
-of miners benefiting from “spoofing” transactions and the desire for a
-fixed eventual supply goal lead to considering alternatives like the
-Sustainability Fund, which pays out fees over a long enough time horizon
-to prevent recouping costs, allowing Zcash to remain closer to its
-supply goal and offering an alternative to other protocol designs that
-destroy or burn funds.
      8. 
-
    8. Recovery of “Soft-Burned” Funds: In some instances,
-such as miners not claim all available rewards, some ZEC goes
-unaccounted for though not formally burned. This proposal would recover
-it through the ZSF_BALANCE mechanism described below.
      9. 
+
      For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a ZSF_DEPOSIT field in the transaction, to be taken into account by the Zcash nodes.
      
+
      This quite simple alteration has -- in our opinion -- a multitude of benefits:
      
+
        
+
      1. Long Term Consensus Sustainability: This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
        2. 
+
      2. Benefits to ZEC Holders: Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.
        3. 
+
      3. Recovery of "Soft-Burned" Funds: In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the ZSF_BALANCE mechanism described below.
        4. 
 
      
-
      Disclaimer 1: Long term success depends on the specific
-mechanisms of deposits, the quantities involved, and broader economic
-considerations. For such as if the payout rate is both sufficient and
-not excessive enough to threaten sustainability.
      
-
      Specification
      
-
      In practice, The Zcash Sustainability Fund is a single global balance
-maintained by the node state and contributed to via a single transaction
-field. This provides the economic and security support described in the
-motivation section, while also importantly keeping the fund payouts
-extremely simple to describe and implement.
      
-
      The two modifications are: 1. The re-accounting of unmined ZEC as a
-node state field called ZSF_BALANCE 2. The addition of a
-transaction field called ZSF_DEPOSIT
      
-
      Please note that a network upgrade is required for
-this work to be fully implemented.
      
-
      ZSF_BALANCE
      
-
      Upon activation at height H, the ZEC issuance mechanism
-is permanently suspended, the value of ZSF_BALANCE[H] is
-set to the remainder of unissued ZEC. This must be done before the
-Block Rewards Payout Rule is enforced for the block at
-height H. This is not a pre-mine. This is
-simply a re-accounting of unissued ZEC that comes with the benefit of
-other possible sources of funding.
      
+
      Specification
      
+
      In practice, The Zcash Sustainability Fund is a single global balance maintained by the node state and contributed to via a single transaction field. This provides the economic and security support described in the motivation section, while also importantly keeping the fund payouts extremely simple to describe and implement.
      
+
      The two modifications are:
+1. The re-accounting of unmined ZEC as a node state field called ZSF_BALANCE
+2. The addition of a transaction field called ZSF_DEPOSIT
      
+
      ZSF_BALANCE
      
+
      The ZEC issuance mechanism is re-defined to remove funds from ZSF_BALANCE, which is initially set to MAX_MONEY at the genesis block.
      
 
      Consensus nodes are then required to track new per-block state:
      
 
        
 
      • ZSF_BALANCE[H] : u64 [zatoshi]
        • 
 
      
-
      The state is a single 64 bit integer (representing units of
-zatoshi) at any given block height, H,
-representing the Sustainability Fund balance at that height,
-H. The ZSF_BALANCE can be calculated using the
-following formula:
      
-
      TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS
      
-
      This formula holds for all future blocks. It is safe and semantically
-consistent to consider all blocks prior to the activation height to have
-a value of 0 in this field. This is not required by this
-proposal but may be convenient in designs or implementations.
      
-
      ZSF_BALANCE
-Requirements
      
+
      The state is a single 64 bit integer (representing units of zatoshi) at any given block height, H, representing the Sustainability Fund balance at that height, H. The ZSF_BALANCE can be calculated using the following formula:
      
+
      ZsfBalanceAfter(height) = MAX_MONEY + sum_{h = 0}^{height} (ZsfDeposit(height) + Unclaimed(height) - BlockSubsidy(height))
+where Unclaimed(height) is the portion of the block subsidy and miner fees that are unclaimed for the block at the given height. 
      
+
      The block at height H commits to ZsfBalanceAfter(H) as part of a new block commitment in the block header, at the end of the hashBlockCommitments chain in ZIP-244.
      
+
      TODO ZIP editors: consider introducing a chain state commitment hash tree. (When we get closer to the network upgrade, we will have a better idea what commitments that network upgrade needs.)
      
+
      Deposits into the Sustainability Fund
      
+
      Sustainability fund deposits can be made via the new zsfDeposit field. This can be done by:
+- ZEC fund holders, in non-coinbase transactions;
+- Zcash miners, in coinbase transactions.
      
+
      In transaction versions without this new field:
+- unclaimed miner fees and rewards in coinbase transactions are re-defined as deposits into the sustainability fund, and
+- there are no sustainability fund deposits from non-coinbase transactions.
      
+
      Note: older transaction versions can continue to be supported after a network upgrade. For example, NU5 supports both v4 and v5 transaction formats, for both coinbase and non-coinbase transactions.
      
+
      zsfDeposit fields in transactions
      
+
      Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF
      
+
      This is achieved by adding a new field to the common transaction fields [#zip-0225-transaction-format]:
      
 
        
-
      • The value of ZSF_BALANCE SHOULD equal 0
-for all blocks prior to the activation height H.
        • 
-
      • The above described formula
-TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS
-MUST hold for all future blocks.
        • 
-
      • Future protocol changes MUST NOT reduce or redistribute the funds in
-the ZSF, and they may not increase the payout rate to a reasonable
-approximation beyond the four year half-life constraint.
        • 
+
      • zsfDeposit : u64 [zatoshi]
        • 
 
      
-
      ZSF_DEPOSIT
      
-
      Each transaction can dedicate some of its excess funds to the ZSF,
-and the remainder becomes the miner fee, with any excess miner
-fee/reward going to the ZSF
      
-
      This is achieved by adding a new field to all transactions:
      
+
      The ZSF_BALANCE[H] for a block at height H can be calculated given a value of ZSF_BALANCE[H-1] and the set of transactions contained in that block. First, the ZSF_DEPOSIT[H] is calculated based solely on ZSF_BALANCE[H-1]. This is subtracted from the previous block's balance to be distributed as part of the block reward. Second, the sum of all the ZSF_DEPOSIT fields of all transactions in the block is added to the balance.
      
+
      Non-Coinbase Transactions
      
+
      If the ZSF_DEPOSIT field is not present in an older transaction version, it is defined to be zero for non-coinbase transactions.
      
+
      Consensus Rule Changes
      
 
        
-
      • ZSF_DEPOSIT : u64 [zatoshi]
        • 
+
      • Transparent inputs to a transaction insert value into a transparent transaction value pool associated with the transaction. Transparent outputs and sustainability fund deposits remove value from this pool.
        • 
 
      
-
      The ZSF_BALANCE[H] for a block at height H
-can be calculated given a value of ZSF_BALANCE[H-1] and the
-set of transactions contained in that block. First, the
-ZSF_DEPOSIT[H] is calculated based solely on
-ZSF_BALANCE[H-1]. This is subtracted from the previous
-block’s balance to be distributed as part of the block reward. Second,
-the sum of all the ZSF_DEPOSIT fields of all transactions
-in the block is added to the balance.
      
-
      It is safe and consistent to treat older transactions using
-pre-Sustainability Fund formats as if they have this field implicitly
-present with a value of 0 where that simplifies designs or
-implementations.
      
-
      Note: this field is not generally considered an “output” because it
-differs from other outputs in several significant ways:
      
+
      Coinbase Transactions
      
+
      Any excess miner fee/reward is sent to the ZSF.
      
+
      In new blocks, this deposit is tracked via the ZSF_DEPOSIT field in coinbase transactions. 
      
+
      If the ZSF_DEPOSIT field is not present in a coinbase transaction with an older transaction version, it is defined as the value of any unspent miner fee and miner reward. This re-defines these previously unspendable funds as ZSF deposits.
      
+
      Consensus Rule Changes
      
 
        
-
      • All ZSF_DEPOSIT fields contribute to a single global
-balance rather than a user-specific output state,
        • 
-
      • Consensus validation can account for this field by updating
-ZSF_BALANCE[H] and do not need to track any transaction
-field specific state after this accounting in contrast to e.g. UTXOs
-which must be tracked until spent.
        • 
-
      • This field does not contribute to the transaction graph of senders
-or recipients whether transparent or protected by cryptography.
        • 
+
      • The remaining value in the transparent transaction value pool of a coinbase transaction is deposited in the sustainability fund.
        • 
 
      
-
      ZSF_DEPOSIT
-Requirements
      
+
      ZSF_DEPOSIT Requirements
      
 
        
-
      • There MUST be only one ZSF_DEPOSIT field per
-transaction
        • 
-
      • ZIP 225 [3] MUST be updated to include ZSF_DEPOSIT. ZIP
-244 MAY be updated as well.
        • 
-
      • Separate programming language implementations (C++, Rust, etc) MUST
-guarantee that the calculations described above are consistent
        • 
+
      • ZIP 230 [3] must be updated to include ZSF_DEPOSIT.
        • 
+
      • ZIP 244 [4] must be updated as well to include ZSF_DEPOSIT.
        • 
 
      
-
      Rationale
      
-
      All technical decisions in this ZIP are balanced between the
-necessary robustness of the ZSF mechanics, and simplicity of
-implementation.
      
-
      ZSF_BALANCE as node
-state
      
-
      Tracking the ZSF_BALANCE value as a node state using the
-above formula is very simple in terms of implementation, and should work
-correctly given that the node implementations calculate the value
-according to the specifications.
      
-
      Alternative:
-ZSF_BALANCE as block header commitment
      
-
      An alternative to node state could be to include the
-ZSF_BALANCE field as a block header and require a block
-header commitment.
      
-
      Requiring block-header-rooted commitments of global fund balances
-such as the Sustainability Fund ensures that any consensus deviating
-bugs in accounting of this balance are immediately detected in the
-earliest impacted block. It also removes some of the need for explorer
-sites and other analytics services from tracking this value
-independently, assuming the committed value is made available by common
-APIs. This helps ensure that all explorers track and report the correct
-value.
      
-
      ZSF_DEPOSIT
-as explicit transaction field
      
-
      An explicit value distinguishes the ZEC destined to Sustainability
-Fund deposits from the implicit transaction fee. Explicitness also
-ensures any arithmetic flaws in any implementations are more likely to
-be observed and caught immediately.
      
-
      References
      
-
      [1]: Key words for use in
-RFCs to Indicate Requirement Levels
      
-
      [2]: ZIP 200: Network
-Upgrade Mechanism
      
-
      [3]: ZIP 225: Version
-5 Transaction Format
      
-
-
+
      Rationale
      
+
      All technical decisions in this ZIP are balanced between the necessary robustness of the ZSF mechanics, and simplicity of implementation. 
      
+
      ZSF_BALANCE as node state
      
+
      Tracking the ZSF_BALANCE value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications.
      
+
      Committing to ZsfBalanceAfter in the block header
      
+
      The ZsfBalanceAfter node state has a block header commitment as specified above.
      
+
      Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value.
      
+
      ZSF_DEPOSIT as explicit transaction field
      
+
      An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately.
      
+
      Deployment
      
+
      This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors).
      
+
      The ZsfBalanceAfter node state commitment will be included in the hashBlockCommitments chain starting with the network upgrade activation block.
      
+
      References
      
+
      [1]: Key words for use in RFCs to Indicate Requirement Levels
      
+
      [2]: ZIP 200: Network Upgrade Mechanism
      
+
      [3]: ZIP 230: v6 transactions, including ZSAs
      
+
      [4]: ZIP 244: Transaction Identifier Non-Malleability
      
\ No newline at end of file
diff --git a/draft-zsf.md b/draft-zsf.md
index 1e8d60676..b8188ac1d 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -19,8 +19,7 @@ The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL",
 
 The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [2]
 
-The term "Block Rewards" refers to the algorithmic
-issuance of ZEC to every block's creator -- part of the consensus rules.
+"Block Subsidy” - the algorithmic issuance of ZEC on block creation – part of the consensus rules. Split between the miner and the Dev Fund. Also known as Block Reward.
 
 "Issuance" - The method by which unmined or unissued ZEC is converted to ZEC available to users of the network
 

From 78b6c5200da514a2a1096cd1c1b67633751c0b43 Mon Sep 17 00:00:00 2001
From: Mark Henderson 
Date: Fri, 29 Sep 2023 10:35:39 -0400
Subject: [PATCH 39/47] fix: date

---
 draft-zsf.html | 2 +-
 draft-zsf.md   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/draft-zsf.html b/draft-zsf.html
index 7c7ee08d6..4feb5732d 100644
--- a/draft-zsf.html
+++ b/draft-zsf.html
@@ -8,7 +8,7 @@
 Credits:
 Status: Draft
 Category: Ecosystem
-Created: 2023-08-
+Created: 2023-08-16
 License: BSD-2-Clause
      
 
      Terminology
      
 
      The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. [1]
      
diff --git a/draft-zsf.md b/draft-zsf.md
index b8188ac1d..08931eba4 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -9,7 +9,7 @@ Original-Authors: Nathan Wilcox
 Credits:
 Status: Draft
 Category: Ecosystem
-Created: 2023-08-
+Created: 2023-08-16
 License: BSD-2-Clause
 ```
 

From 09e70fefc1d3a0eb45a95f808d7bbfc053a30e05 Mon Sep 17 00:00:00 2001
From: Mark Henderson 
Date: Fri, 29 Sep 2023 10:41:45 -0400
Subject: [PATCH 40/47] fix: revert accidental changes to other files

---
 .github/workflows/render.yml | 2 +-
 protocol/protocol.tex        | 4 ++--
 zip-0032.html                | 4 ++--
 zip-0032.rst                 | 2 +-
 zip-0316.html                | 4 ++--
 zip-0316.rst                 | 2 +-
 zip-0321.html                | 4 ++--
 zip-0321.rst                 | 2 +-
 8 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/.github/workflows/render.yml b/.github/workflows/render.yml
index 8ff554395..0cd8240a0 100644
--- a/.github/workflows/render.yml
+++ b/.github/workflows/render.yml
@@ -8,7 +8,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Git repository
-        uses: actions/checkout@v3.6.0
+        uses: actions/checkout@v3.5.3
 
       - name: Compile Zcash Protocol Specification
         uses: ./.github/actions/render-protocol-pdf
diff --git a/protocol/protocol.tex b/protocol/protocol.tex
index 5b1c15610..532d0c933 100644
--- a/protocol/protocol.tex
+++ b/protocol/protocol.tex
@@ -11929,8 +11929,8 @@
 for either $\AuthSignPublic$ or $\NullifierKey$, or if $\AuthSignPublic \notin \SubgroupJstar$,
 or if $\NullifierKey \notin \SubgroupJ$.
 
-For \fullViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}.
-For \fullViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}.
+For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}.
+For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}.
 } %sapling
 
 
diff --git a/zip-0032.html b/zip-0032.html
index 333d780e2..c7d7ad4b3 100644
--- a/zip-0032.html
+++ b/zip-0032.html
@@ -232,7 +232,7 @@
                     
                     
    9. 
                         \(\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=\)
-                        \(\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))\)
+                        \(\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))\)
                         \(||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))\)
                         \(||\,\mathsf{ovk}\)
                         \(||\,\mathsf{dk}\)
@@ -1158,4 +1158,4 @@
         
     
 
-
\ No newline at end of file
+
diff --git a/zip-0032.rst b/zip-0032.rst
index 823fffa9c..fee192572 100644
--- a/zip-0032.rst
+++ b/zip-0032.rst
@@ -177,7 +177,7 @@ Sapling helper functions
 Define
 
 * :math:`\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk}) :=`:math:`\mathsf{I2LEOSP}_{256}(\mathsf{ask})`:math:`||\,\mathsf{I2LEOSP}_{256}(\mathsf{nsk})`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}`
-* :math:`\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=`:math:`\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))`:math:`||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}`
+* :math:`\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=`:math:`\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))`:math:`||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}`
 
 Sapling master key generation
 -----------------------------
diff --git a/zip-0316.html b/zip-0316.html
index 96a4ad61e..b1b05b514 100644
--- a/zip-0316.html
+++ b/zip-0316.html
@@ -250,7 +250,7 @@
                      is an encoding of
                         \((\mathsf{dk}, \mathsf{ivk})\)
                      given by
-                        \(\mathsf{dk}\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).\)
+                        \(\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).\)
                     
      10. 
                     
    10. There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be diversified in an unlinkable way). The Typecode
                         \(\mathtt{0x01}\)
@@ -1023,4 +1023,4 @@
         
     
 
-
\ No newline at end of file
+
diff --git a/zip-0316.rst b/zip-0316.rst
index d4618b050..f5ec2e1b7 100644
--- a/zip-0316.rst
+++ b/zip-0316.rst
@@ -431,7 +431,7 @@ The following FVK or IVK Encodings are used in place of the
 
 * A Sapling IVK Encoding, also with Typecode :math:`\mathtt{0x02},`
   is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by
-  :math:`\mathsf{dk}\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).`
+  :math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).`
 
 * There is no defined way to represent a Viewing Key for a Transparent
   P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be
diff --git a/zip-0321.html b/zip-0321.html
index 28e9753d4..a2d3498c0 100644
--- a/zip-0321.html
+++ b/zip-0321.html
@@ -121,7 +121,7 @@
                     
      Also invalid; address.0= and amount.0= are not permitted as leading 0s are forbidden in paramindex.
      
                     
      zcash:?amount=1.234&amount=2.345&address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU
 
-zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU
      
+zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU"

    Also invalid; duplicate amount= or amount.1= fields

    zcash:tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1%30
 zcash:tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?%61mount=1
@@ -247,4 +247,4 @@
         
     
 
-
\ No newline at end of file
+
diff --git a/zip-0321.rst b/zip-0321.rst
index f71ec0e4c..f595065b7 100644
--- a/zip-0321.rst
+++ b/zip-0321.rst
@@ -260,7 +260,7 @@ forbidden in ``paramindex``.
 
   zcash:?amount=1.234&amount=2.345&address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU
 
-  zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU
+  zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU"
 
 Also invalid; duplicate ``amount=`` or ``amount.1=`` fields
 

From 272b516560b5f909a89c120b18b04338415c2731 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Fri, 29 Sep 2023 10:42:52 -0400
Subject: [PATCH 41/47] fix: revert accidental changes


From 4c50af9f2a831d7692ce3de88158af11f60ba885 Mon Sep 17 00:00:00 2001
From: Mark Robert Henderson 
Date: Tue, 12 Mar 2024 15:17:02 -0400
Subject: [PATCH 42/47] Update draft-zsf.md

Co-authored-by: str4d 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 08931eba4..40f47d691 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -8,7 +8,7 @@ Owners: Jason McGee 
 Original-Authors: Nathan Wilcox
 Credits:
 Status: Draft
-Category: Ecosystem
+Category: Consensus / Ecosystem
 Created: 2023-08-16
 License: BSD-2-Clause
 ```

From 5c198985026d1be7102e4e8be6bfc2433d9fe10f Mon Sep 17 00:00:00 2001
From: Mark Henderson 
Date: Tue, 9 Apr 2024 13:36:22 -0400
Subject: [PATCH 43/47] feat: add ZIP number 233

---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 40f47d691..1b7708da0 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -1,5 +1,5 @@
 ```
-ZIP: 
+ZIP: 233
 Title: Establish the Zcash Sustainability Fund on the Protocol Level
 Owners: Jason McGee 
         Mark Henderson 

From adb46fb2313049df49e942844fcf79c200644463 Mon Sep 17 00:00:00 2001
From: Mark Henderson 
Date: Tue, 9 Apr 2024 13:41:02 -0400
Subject: [PATCH 44/47] lang: add block subsidy

---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index 1b7708da0..dd0e76833 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -33,7 +33,7 @@ This ZIP describes the motivation, the necessary changes for, and the implementa
 
 The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a `ZSF_BALANCE`, and for a new transaction field to be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
 
-This ZIP does not change the current ZEC issuance schedule. Any additional amounts paid into the sustainability fund are reserved for use in future ZIPs.
+This ZIP does not change the current ZEC block subsidy issuance schedule. Any additional amounts paid into the sustainability fund are reserved for use in future ZIPs.
 
 # Motivation
 

From ee8811993cc745614554c6efdf28a8b6bd665b75 Mon Sep 17 00:00:00 2001
From: Mark Henderson 
Date: Wed, 10 Jul 2024 21:43:19 -0400
Subject: [PATCH 45/47] Update draft-zsf.md

Co-authored-by: Arya 
---
 draft-zsf.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index dd0e76833..ce21ed915 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -57,7 +57,7 @@ This quite simple alteration has -- in our opinion -- a multitude of benefits:
 
 1. **Long Term Consensus Sustainability:** This mechanism supports long-term consensus sustainability by addressing concerns about the sustainability of the network design shared by Bitcoin-like systems through the establishment of deposits into the Sustainability Fund to augment block rewards, ensuring long-term sustainability as the issuance rate of Zcash drops and newly issued ZEC decreases over time.
 2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of ZEC, temporarily reducing its available supply, benefiting current holders of unencumbered active ZEC in proportion to their holdings without requiring them to opt into any scheme, introducing extra risk, active oversight, or accounting complexity.
-3. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claim all available rewards, some ZEC goes unaccounted for though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below.
+3. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not claiming all available rewards, some ZEC goes unaccounted for, though not formally burned. This proposal would recover it through the `ZSF_BALANCE` mechanism described below.
 
 # Specification
 

From e0e3f25295018bccc16e58b1894bcc132d511942 Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 22 Aug 2024 16:37:14 +0200
Subject: [PATCH 46/47] Remove the section about `ZsfBalanceAfter` persistence

---
 draft-zsf.md | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index ce21ed915..bbd6e35bb 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -140,12 +140,6 @@ All technical decisions in this ZIP are balanced between the necessary robustnes
 
 Tracking the `ZSF_BALANCE` value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications.
 
-### Committing to `ZsfBalanceAfter` in the block header
-
-The `ZsfBalanceAfter` node state has a block header commitment as specified above.
-
-Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value.
-
 ## `ZSF_DEPOSIT` as explicit transaction field
 
 An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately.

From 435fc73045c01c9631c20a4ad6e37abaa02aaacb Mon Sep 17 00:00:00 2001
From: Tomek Piotrowski 
Date: Thu, 22 Aug 2024 16:43:27 +0200
Subject: [PATCH 47/47] Remove the mention of zsf balance commitments

---
 draft-zsf.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/draft-zsf.md b/draft-zsf.md
index bbd6e35bb..0940a793a 100644
--- a/draft-zsf.md
+++ b/draft-zsf.md
@@ -148,8 +148,6 @@ An explicit value distinguishes the ZEC destined to Sustainability Fund deposits
 
 This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors).
 
-The `ZsfBalanceAfter` node state commitment will be included in the `hashBlockCommitments` chain starting with the network upgrade activation block.
-
 # References
 
 **[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)**