Step 1: Add mdbook scaffolding

.gitignore

@@ -31,3 +31,6 @@ protocol/saplinghtml/
 protocol/heartwood.pdf
 protocol/protocol.ver
 *~
+
+# mdbook build output
+book/

book.toml

@@ -0,0 +1,9 @@
+[book]
+title = "Zcash Improvement Proposals"
+authors = ["Zcash Contributors"]
+language = "en"
+multilingual = false
+src = "src"
+
+[build]
+build-dir = "book"

src/SUMMARY.md

@@ -0,0 +1,11 @@
+# Summary
+
+[Introduction](introduction.md)
+
+---
+
+# Consensus
+
+- [ZIP 233: Establish the Zcash Sustainability Fund](zip-0233.md)
+- [ZIP 234: Smooth Out The Block Subsidy Issuance](zip-0234.md)
+- [ZIP 253: Deployment of the NU6 Network Upgrade](zip-0253.md)

src/introduction.md

@@ -0,0 +1,46 @@
+# Zcash Improvement Proposals
+
+## What are ZIPs?
+
+Zcash Improvement Proposals (ZIPs) are the way to:
+
+- propose new features for the [Zcash cryptocurrency](https://z.cash/) and their rationale,
+- specify the implementation details of the feature,
+- collect community input on the proposal, and
+- document design decisions.
+
+## Contributing
+
+The authors of a ZIP are responsible for building consensus within the community
+and documenting / addressing dissenting opinions.
+
+Anyone can write a ZIP! We encourage community contributions and decentralization
+of work on the Zcash protocol. If you'd like to bounce ideas off people before formally
+writing a ZIP, we encourage it! Visit the
+[ZcashCommunity Discord chat](https://discord.gg/kdjfvps) to talk about your idea.
+
+Participation in the Zcash project is subject to a
+[Code of Conduct](https://github.com/zcash/zcash/blob/master/code_of_conduct.md).
+
+The Zcash protocol is documented in its
+[Protocol Specification](https://zips.z.cash/protocol/protocol.pdf).
+
+To start contributing, first read [ZIP 0](zip-0000.md) which documents the ZIP process.
+Then clone [this repo](https://github.com/zcash/zips) from GitHub, and start adding
+your draft ZIP, formatted either as reStructuredText or as Markdown, into the `zips/`
+directory.
+
+For example, if using reStructuredText, use a filename matching `zips/draft-*.rst`.
+Use `make` to check that you are using correct
+[reStructuredText](https://docutils.sourceforge.io/rst.html) or
+[Markdown](https://pandoc.org/MANUAL.html#pandocs-markdown) syntax,
+and double-check the generated `rendered/draft-*.html` file before filing a Pull Request.
+See [here](https://github.com/zcash/zips/blob/main/protocol/README.rst) for the project
+dependencies.
+
+## License
+
+Unless otherwise stated in this repository's individual files, the contents of this
+repository are released under the terms of the MIT license. See
+[COPYING](https://github.com/zcash/zips/blob/main/COPYING.rst) for more information or
+see <https://opensource.org/licenses/MIT>.

src/zip-0233.md

@@ -0,0 +1,242 @@
+```
+ZIP: 233
+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:
+Status: Draft
+Category: Consensus / Ecosystem
+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]
+
+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 block subsidy 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 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:
+    - 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**
+
+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. **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
+   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
+
+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[height] : u64 [zatoshi]`
+
+The state is a single 64 bit integer (representing units of `zatoshi`) at any
+given block height, $\mathsf{height}$, representing the Sustainability Fund
+balance at that height. The `ZSF_BALANCE` can be calculated using the following
+formula:
+
+$\mathsf{ZsfBalanceAfter}(\mathsf{height}) = \mathsf{MAX\_MONEY} + \sum_{h = 0}^{\mathsf{height}} (\mathsf{ZsfDeposit}(h) + \mathsf{Unclaimed}(h) - \mathsf{BlockSubsidy}(h))$
+
+where $\mathsf{Unclaimed}(\mathsf{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 $\mathsf{height}$ commits to
+$\mathsf{ZsfBalanceAfter}(\mathsf{height})$ 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.)
+
+## 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]:
+
+- `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.
+
+
+### 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
+
+- 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 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.
+
+## `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).
+
+# 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 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)**