diff --git a/README.rst b/README.rst index aba9f677d..6f0ca76e4 100644 --- a/README.rst +++ b/README.rst @@ -42,6 +42,32 @@ and double-check the generated ``rendered/draft-*.html`` file before filing a Pu See `here `__ for the project dependencies. +NU7 Candidate ZIPs +------------------ + +The following ZIPs are under consideration for inclusion in NU7: + +- `ZIP 226: Transfer and Burn of Zcash Shielded Assets `__ +- `ZIP 227: Issuance of Zcash Shielded Assets `__ +- `ZIP 230: Version 6 Transaction Format `__ +- `ZIP 231: Memo Bundles `__ +- `ZIP 233: Network Sustainability Mechanism: Burning `__ +- `ZIP 234: Network Sustainability Mechanism: Issuance Smoothing `__ +- `ZIP 235: Network Sustainability Mechanism: Burn 60% of Transaction Fees `__ +- `ZIP 2002: Explicit Fees `__ +- `ZIP 2003: Disallow version 4 transactions `__ +- `ZIP 2004: Remove the dependency of consensus on note encryption `__ + +In addition, `ZIP 317: Proportional Transfer Fee Mechanism `__ +may be updated. + +This list is only provided here for easy reference; no decision has been made +on whether to include each of these ZIPs. + +`ZIP 254: Deployment of the NU7 Network Upgrade `__ will define +which ZIPs are included in NU7. + + License ------- @@ -129,10 +155,12 @@ written. 227 Issuance of Zcash Shielded Assets Draft 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft - 231 Decouple Memos from Transaction Outputs Reserved - 233 Establish the Zcash Sustainability Fund on the Protocol Level Draft - 234 Smooth Out The Block Subsidy Issuance Draft + 231 Memo Bundles Draft + 233 Network Sustainability Mechanism: Burning Draft + 234 Network Sustainability Mechanism: Issuance Smoothing Draft + 235 Burn 60% of Transaction Fees Draft 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft + 254 Deployment of the NU7 Network Upgrade Draft 302 Standardized Memo Field Format Draft 303 Sprout Payment Disclosure Reserved 304 Sapling Address Signatures Draft @@ -156,6 +184,9 @@ written. 402 New Wallet Database Format Reserved 403 Verification Behaviour of zcashd Reserved 416 Support for Unified Addresses in zcashd Reserved + 2002 Explicit Fees Draft + 2003 Disallow version 4 transactions Draft + 2004 Remove the dependency of consensus on note encryption Draft guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft @@ -172,8 +203,6 @@ be deleted. - - @@ -253,9 +282,10 @@ Index of ZIPs - - - + + + + @@ -265,6 +295,7 @@ Index of ZIPs + @@ -313,6 +344,9 @@ Index of ZIPs + + +
Title
Explicit Fees
Disallow version 4 transactions
Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
Block Reward Allocation for Non-Direct Development Funding
Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
233 Establish the Zcash Sustainability Fund on the Protocol Level Draft
234 Smooth Out The Block Subsidy Issuance Draft
231 Memo Bundles Draft
233 Network Sustainability Mechanism: Burning Draft
234 Network Sustainability Mechanism: Issuance Smoothing Draft
235 Burn 60% of Transaction Fees Draft
236 Blocks should balance exactly Implemented (zcashd and zebrad)
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
253 Deployment of the NU6 Network Upgrade Implemented (zcashd and zebrad)
254 Deployment of the NU7 Network Upgrade Draft
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
302 Standardized Memo Field Format Draft
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
1015 Block Reward Allocation for Non-Direct Development Funding Proposed
2001 Lockbox Funding Streams Implemented (zcashd and zebrad)
2002 Explicit Fees Draft
2003 Disallow version 4 transactions Draft
2004 Remove the dependency of consensus on note encryption Draft
guide-markdown {Something Short and To the Point} Draft
guide {Something Short and To the Point} Draft
diff --git a/rendered/index.html b/rendered/index.html index 71399a3ae..91823acaf 100644 --- a/rendered/index.html +++ b/rendered/index.html @@ -24,6 +24,24 @@

To start contributing, first read ZIP 0 which documents the ZIP process. Then clone this repo 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 or Markdown syntax, and double-check the generated rendered/draft-*.html file before filing a Pull Request. See here for the project dependencies.

+

NU7 Candidate ZIPs

+

The following ZIPs are under consideration for inclusion in NU7:

+ +

In addition, ZIP 317: Proportional Transfer Fee Mechanism may be updated.

+

This list is only provided here for easy reference; no decision has been made on whether to include each of these ZIPs.

+

ZIP 254: Deployment of the NU7 Network Upgrade will define which ZIPs are included in NU7.

+

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 for more information or see https://opensource.org/licenses/MIT .

@@ -92,10 +110,12 @@ 227 Issuance of Zcash Shielded Assets Draft 228 Asset Swaps for Zcash Shielded Assets Reserved 230 Version 6 Transaction Format Draft - 231 Decouple Memos from Transaction Outputs Reserved - 233 Establish the Zcash Sustainability Fund on the Protocol Level Draft - 234 Smooth Out The Block Subsidy Issuance Draft + 231 Memo Bundles Draft + 233 Network Sustainability Mechanism: Burning Draft + 234 Network Sustainability Mechanism: Issuance Smoothing Draft + 235 Burn 60% of Transaction Fees Draft 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft + 254 Deployment of the NU7 Network Upgrade Draft 302 Standardized Memo Field Format Draft 303 Sprout Payment Disclosure Reserved 304 Sapling Address Signatures Draft @@ -119,6 +139,9 @@ 402 New Wallet Database Format Reserved 403 Verification Behaviour of zcashd Reserved 416 Support for Unified Addresses in zcashd Reserved + 2002 Explicit Fees Draft + 2003 Disallow version 4 transactions Draft + 2004 Remove the dependency of consensus on note encryption Draft guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft @@ -126,8 +149,6 @@

These are works-in-progress, and may never be assigned ZIP numbers if their ideas become obsoleted or abandoned. Do not assume that these drafts will exist in perpetuity; instead assume that they will either move to a numbered ZIP, or be deleted.

- - @@ -197,9 +218,10 @@ - - - + + + + @@ -209,6 +231,7 @@ + @@ -257,6 +280,9 @@ + + +
Title
Explicit Fees
Disallow version 4 transactions
Manufacturing Consent; Re-Establishing a Dev Fund for ECC, ZF, ZCG, Qedit, FPF, and ZecHub
Block Reward Allocation for Non-Direct Development Funding
Establishing a Hybrid Dev Fund for ZF, ZCG and a Dev Fund Reserve
227 Issuance of Zcash Shielded Assets Draft
228 Asset Swaps for Zcash Shielded Assets Reserved
230 Version 6 Transaction Format Draft
231 Decouple Memos from Transaction Outputs Reserved
233 Establish the Zcash Sustainability Fund on the Protocol Level Draft
234 Smooth Out The Block Subsidy Issuance Draft
231 Memo Bundles Draft
233 Network Sustainability Mechanism: Burning Draft
234 Network Sustainability Mechanism: Issuance Smoothing Draft
235 Burn 60% of Transaction Fees Draft
236 Blocks should balance exactly Implemented (zcashd and zebrad)
239 Relay of Version 5 Transactions Final
243 Transaction Signature Validation for Sapling Final
251 Deployment of the Canopy Network Upgrade Final
252 Deployment of the NU5 Network Upgrade Final
253 Deployment of the NU6 Network Upgrade Implemented (zcashd and zebrad)
254 Deployment of the NU7 Network Upgrade Draft
300 Cross-chain Atomic Transactions Proposed
301 Zcash Stratum Protocol Final
302 Standardized Memo Field Format Draft
1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active
1015 Block Reward Allocation for Non-Direct Development Funding Proposed
2001 Lockbox Funding Streams Implemented (zcashd and zebrad)
2002 Explicit Fees Draft
2003 Disallow version 4 transactions Draft
2004 Remove the dependency of consensus on note encryption Draft
guide-markdown {Something Short and To the Point} Draft
guide {Something Short and To the Point} Draft
diff --git a/rendered/zip-0231.html b/rendered/zip-0231.html index 877430c9b..65d0210f3 100644 --- a/rendered/zip-0231.html +++ b/rendered/zip-0231.html @@ -1,21 +1,731 @@ - ZIP 231: Decouple Memos from Transaction Outputs + ZIP 231: Memo Bundles - + + + -
- 
ZIP: 231
-Title: Decouple Memos from Transaction Outputs
+
ZIP: 231
+Title: Memo Bundles
 Owners: Jack Grigg <jack@electriccoin.co>
         Kris Nuttycombe <kris@electriccoin.co>
-        Daira-Emma Hopwood <daira-emma@electriccoin.co>
+        Daira-Emma Hopwood <daira@electriccoin.co>
+        Arya Solhi <arya@zfnd.org>
 Credits: Sean Bowe
          Nate Wilcox
-Status: Reserved
+Status: Draft
 Category: Consensus / Wallet
-Discussions-To: <https://github.com/zcash/zips/issues/627>

-
+Created: 2024-04-26 +License: MIT +

Terminology

+

The key words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” in this +document are to be interpreted as described in BCP 14 1 +when, and only when, they appear in all capitals.

+

The character § is used when referring to sections of the Zcash +Protocol Specification. 2

+

Abstract

+

Currently, the memo sent in a shielded output is limited to at most +512 bytes. This ZIP proposes to allow larger memos, and to enable memo +data to be shared between multiple recipients of a transaction.

+

Motivation

+

In Zcash transaction versions v2 to v5 inclusive, each Sapling or +Orchard shielded output contains a ciphertext comprised of a 52-byte +note plaintext, and a corresponding 512-byte memo field. 3 +Recipients can only decrypt the outputs sent to them, and thus can also +only observe the memo fields included with the outputs they can +decrypt.

+

The shielded transaction protocol hides the sender(s) (that is, the +addresses corresponding to the keys used to spend the input notes) from +all of the recipients. For certain kinds of transactions, it is +desirable to make one or more sender addresses available to one or more +recipients (for example, a reply address). In such circumstances it is +important to authenticate the sender addresses, to give the recipient a +guarantee that the address is controlled by a sender of the transaction; +failure to authenticate this address can enable phishing attacks. These +Authenticated Reply Addresses require zero-knowledge proofs, and for the +Orchard protocol these proofs are too large to fit into a 512-byte memo +field.

+

It is also desirable, for clients with more stringent bandwidth +constraints, to be able to transmit encrypted notes to the client +without including the encrypted memo data. In the current light client +protocol 4, this is done by truncating the note +ciphertext to just the part that encrypts the memo. However, that has +the effect of truncating the authentication tag, and so the resulting +decryption algorithm does not meet standard security notions for an +authenticated encryption scheme. It is a goal of this proposal to +rectify this, simplifying the security argument.

+

Instead of the memo data, this ZIP proposes that it is possible to +indicate whether a memo is present for the recipient. When using the +light client protocol, a recipient need not download full transaction +information if this indication tells them that they have not received +any memo in the transaction.

+

At present, it is not possible to transmit the same memo data to +multiple transaction recipients without redundantly encoding that data, +and sending memo data greater than 512 bytes requires sending multiple +outputs; the problem is compounded when attempting to send more than 512 +bytes to each recipient. By separating memo data from the decryption +capability for those memos, it admits a greater variety of applications +that utilize memo data, while decreasing the amount of data that needs +to be stored on-chain overall.

+

Requirements

+
    +
  • Recipients can receive memo data that is greater than 512 bytes in +length.
    • +
  • Multiple recipients, across any of the shielded pools, can be given +the capability to view the same memo data.
    • +
  • The exact number and exact lengths of distinct decryptable memos +should not be revealed, even to the transaction recipients, although an +upper bound on the total length of memo data that the observer does not +have the capability to view will be leaked to transaction recipients, +and the overall maximum possible length of memo data will be revealed +on-chain.
    • +
  • A recipient can determine whether or not they have been given the +capability to view any memo solely by decrypting the note +ciphertext.
    • +
  • Memo chunks within a transaction can be individually pruned from +block storage without preventing the transaction from being verified +when transmitting block data to peers.
    • +
  • The ciphertext of the note alone can be decrypted using a scheme +that meets a standard security notion for authenticated encryption, +without more than a small constant overhead in ciphertext size.
    • +
+

Non-requirements

+
    +
  • Recipients do not need to be able to receive multiple memos per +note. This capability can however be enabled under the existing proposal +by “chaining” memos, including the decryption key for another memo +within the memo that is decryptabble by a recipient.
    • +
+

Specification

+

Since this proposal is defined only for v6 and later transactions, it +is not necessary to consider Sprout JoinSplit outputs. The following +sections apply to both Sapling and Orchard outputs.

+

Changes to the +Zcash Protocol Specification

+

The following changes affecting the definitions of note plaintexts +and note ciphertexts, and the algorithms for encryption and +decryption.

+

In § 3.2.1 ‘Note Plaintexts and Memo Fields’:

+
    +

  • Change

    +
    +

    Each Sapling or Orchard note plaintext (denoted np) +consists of

    +

       (leadByte⦂𝔹𝕐,d⦂𝔹[ℓd],rseed⦂𝔹𝕐[𝟛𝟚],memo⦂𝔹𝕐[𝟝𝟙𝟚])

    +
    +

    to

    +
    +

    The form of a Sapling or Orchard note plaintext depends on the +version of the transaction in which it will be included; specifically +whether that version is pre-v6, or v6-onward.

    +

    Each pre-v6 Sapling or Orchard note plaintext (denoted np) +consists of

    +

       (leadByte⦂𝔹𝕐,d⦂𝔹[ℓd],rseed⦂𝔹𝕐[𝟛𝟚],memo⦂𝔹𝕐[𝟝𝟙𝟚])

    +

    Each v6-onward Sapling or Orchard note plaintext (denoted np) +consists of

    +

       (leadByte⦂𝔹𝕐,d⦂𝔹[ℓd],rseed⦂𝔹𝕐[𝟛𝟚],Kmemo⦂𝔹𝕐[𝟛𝟚])

    +
    • +
+

In § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ 5:

+
    +

  • Change the paragraph that describes “The encoding of a Sapling or +Orchard note plaintext” to refer to “The encoding of a pre-v6 Sapling or +Orchard note plaintext”.

    • +

  • Add a new paragraph at the end of the section:

    +
    +

    The encoding of a v6-onward Sapling or Orchard note plaintext +consists of:

    + +++++++ + + + + + + + + + +
    8-bit leadByte88-bit d64-bit v256-bit rseed32-byte Kmemo
    +
      +
    • A byte 0x03, indicating this version of the encoding of a v6-onward +Sapling or Orchard note plaintext.
      • +
    • 11 bytes specifying d.
      • +
    • 8 bytes specifying v.
      • +
    • 32 bytes specifying rseed.
      • +
    • 32 bytes specifying Kmemo.
      • +
    +

    A value consisting of 32 0xFF +bytes for Kmemo is used to +indicate that there is no memo for this note plaintext.

    +
    • +
+

In § 4.7.2 ‘Sending Notes (Sapling)’ 6 and +§ 4.7.3 ‘Sending Notes (Orchard)’ 7:

+
    +

  • Add a reference to this ZIP specifying the construction of the +memo bundle and derivation of Kmemo in the case of a v6-onward +note plaintext.

    • +

  • Change

    +
    +

    Let np = (leadByte,d,v,rseed,memo) .

    +
    +

    to

    +
    +

    Let np be the +encoding of a Sapling note plaintext using leadByte, d, +v, rseed, and either memo for a pre-v6 note plaintext or Kmemo for a v6-onward note +plaintext.

    +
    +

    replacing “Sapling” with Orchard in the case of § 4.7.3.

    • +
+

In § 4.20.1 ‘Encryption (Sapling and Orchard)’ 8:

+
    +

  • Change

    +
    +

    Let np = (leadByte,d,v,rseed,memo) +be the Sapling or Orchard note plaintext. np is +encoded as defined in § 5.5 ‘Encodings of Note Plaintexts and Memo +Fields’.

    +
    +

    to

    +
    +

    Let np be the +encoding of the Sapling or Orchard note plaintext (which may be pre-v6 +or v6-onward), as defined in § 5.5 ‘Encodings of Note Plaintexts and +Memo Fields’.

    +
    • +

  • Add another normative note to that section:

    +
    +
      +
    • Cenc will be of length +either 580 or 100 bytes, depending on whether np is a +pre-v6 or v6-onward note plaintext.
      • +
    +
    • +
+

In § 4.20.2 ‘Decryption using an Incoming Viewing Key (Sapling and +Orchard)’ 9 and § 4.20.3 ‘Decryption using a +Full Viewing Key (Sapling and Orchard)’ 10:

+
    +
  • Replace memo ⦂ 𝔹𝕐[𝟝𝟙𝟚] +with memoOrKey.
    • +
  • Specify that the type of memoOrKey +is 𝔹𝕐[𝟝𝟙𝟚] when decrypting a +pre-v6 note ciphertext, or 𝔹𝕐[𝟛𝟚] when decrypting a v6-onward +note ciphertext. In the latter case, it is used as Kmemo to decrypt the memo bundle +as described in subsequent sections of this ZIP.
    • +
+

Memo bundle

+

A memo bundle consists of a sequence of 256-byte memo chunks, each +individually encrypted. These memo chunks represent zero or more +encrypted memos.

+

Each transaction may contain a single memo bundle, and a memo bundle +may contain at most memo_chunk_limit memo chunks. This +limits the total amount of memo data that can be conveyed within a +single transaction to memo_chunk_limit * 256 bytes.

+

memo_chunk_limit is a parameter to this specification, +to be decided upon by the community. The authors of this ZIP propose a +maximum of 64 chunks, resulting in a maximum total memo data length of +16 KiB.

+

Memo bundles are encoded in transactions in a prunable manner: each +memo chunk can be replaced by its representative digest.

+

Memo encryption

+

During transaction construction, each output with memo data is +assigned a 32-byte memo key Kmemo. These keys SHOULD be +generated randomly, and MUST NOT be used to encrypt more than one memo +within a single transaction. If an output has no memo data, it is +assigned the memo key consisting of 32 0xFF +bytes.

+

In note plaintexts of v6-onward transactions, the 512-byte memo field +is replaced by Kmemo .

+

The transaction builder generates a 32-byte salt value salt from a CSPRNG. A new salt MUST be +generated for each memo bundle.

+

The symmetric encryption key for a memo is derived from its Kmemo as follows:

+

   encryption_key = PRFKmemoexpand([0xE0] || salt)

+

The first byte 0xE0 +should be added to the documentation of inputs to PRFexpand in § 4.1.2 ‘Pseudo +Random Functions’ 11.

+

If the generated key is 32 0xFF +bytes, the transaction constructor MAY repeat this procedure with a +different salt, in order to avoid the recipient misinterpreting the +output as having no memo data. Since that has negligible probability, it +alternatively MAY omit this check.

+

Each memo is padded to a multiple of 256 bytes with zeroes, and split +into 256-byte chunks. Each memo chunk is encrypted with ChaCha20Poly1305 +[^rfc-8439] as follows:

+

   IETF_AEAD_CHACHA20_POLY1305(encryption_key,nonce,memo_chunk)

+

where nonce = I2BEOSP88(counter)||[final_chunk] .

+

This is a variant of the STREAM construction 12.

+
    +
  • counter is a big-endian chunk +counter starting at zero and incrementing by one for each subsequent +chunk within a particular memo.
    • +
  • final_chunk is the byte 0x01 +for the final memo chunk, and 0x00 +for all preceding chunks.
    • +
+

Finally, the encrypted memo chunks for all memos are combined into a +single sequence using an order-preserving shuffle. Memo chunks from +different memos MAY be interleaved in any order, but memo chunks from +the same memo MUST have the same relative order. The following diagram +shows an example shuffle of three memos:

+
[
+    (memo_a, 0),
+    (memo_b, 0),
+    (memo_a, 1),
+    (memo_c, 0),
+    (memo_c, 1),
+    (memo_a, 2),
+]
+

Memo decryption

+

When a recipient decrypts a shielded output, they obtain a memo key +Kmemo. From this they derive +encryption_key as above, and then proceed as follows:

+
    +
  • Set counter = 0 and +final_chunk = 0x00.
    • +
  • Attempt to decrypt each memo chunk in order. Pruned memo chunks are +skipped.
    • +
  • Each time decryption succeeds for a memo chunk, increment +counter by 1, and then continue attempting to decrypt +subsequent chunks.
    • +
  • Once all memo chunks have been trial-decrypted once, set +final_chunk = 0x01 and then attempt to decrypt the memo +chunks again, starting immediately after the last successfully-decrypted +chunk (or at the start if none were), and without incrementing +counter. +
      +
    • This step can be made secret-independent by attempting to decrypt +every memo chunk again, and ignoring the results of all chunks up to and +including the last successfully-decrypted chunk.
      • +
    • +
  • If no memo chunk decrypts successfully with +final_chunk = 0x01, discard any memo chunks that were +decrypted, and return nothing. Otherwise, concatenate the decrypted memo +chunks in order and return the concatenation as the memo.
    • +
+

If any chunk of the memo encrypted to memo_key has been +pruned, the decryption process above returns nothing (as +final_chunk will be set to 0x01 with the wrong +counter value), ensuring that a malformed memo is not returned.

+

Encoding in transactions

+ ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BytesNameData TypeDescription
1fAllPruneduint81 if all chunks have been pruned, otherwise 0.
32nonceOrHashbyte[32]The nonce for deriving encryption keys, or the overall hash.
† variesnMemoChunkscompactSizeThe number of memo chunks.
† variesprunedbyte[ceiling(nMemoChunks/8)]Bitflags indicating the type of each entry in +vMemoChunks.
† variesvMemoChunksMemoChunk[nMemoChunks]A sequence of encrypted memo chunks.
+

† These fields are present if and only if +fAllPruned == 0.

+

If fAllPruned == 0, then:

+
    +
  • nonceOrHash represents the nonce for deriving +encryption keys.
    • +
  • Each bit of pruned, in little-endian order, indicates +the type of the corresponding entry in vMemoChunks. A bit +value of 0 indicates that the entry will be of type +byte[272] representing an encrypted memo chunk. A bit value +of 1 indicates the entry will be a byte[32] and contains +the memo_chunk_digest for a pruned chunk.
    • +
+

If fAllPruned == 1, then:

+
    +
  • nonceOrHash represents the overall hash for the memo +bundle as defined in Transaction +sighash.
    • +
  • The nMemoChunks, pruned, and +vMemoChunks fields will be absent.
    • +
+

Transaction sighash

+
memo_chunk_digest = H(AEAD(MemoChunk, memo_key))
+memo_bundle_digest = H(concat(memo_chunk_digests))
+

The memo bundle digest structure is a performance optimization for +the case where all memo chunks in a transaction have been pruned.

+

TODO: finish this to be a modification to the equivalent of ZIP 244 +for transaction v6.

+

Transaction fees

+

(This section will become a modification to ZIP 317.)

+

A memo bundle may contain two free chunks if there are any shielded +outputs in the transaction. Otherwise, each memo chunk requires +marginal_fee as defined in ZIP 317 13.

+

Network protocol

+

Nodes must reject GetData responses having an +fAllPruned value that is nonzero, or any byte of +pruned that is nonzero.

+

Open issues

+

Limit on the number of memo +chunks

+

memo_chunk_limit == 64 is recommended. This results in a +maximum of 16 KiB of memo data per transaction.

+

Rationale

+

Memo bundle size restriction

+

Restricting the total amount of memo data in a bundle, for example to +16 KiB, limits the rate at which the chain size can grow cheaply (from a +computational perspective; memo bundles are much easier to produce than +proofs or signatures).

+

The current behaviour for previous transaction versions (no limit on +the number of memos) is not altered by this ZIP, because memos in those +transactions are tied to individual shielded outputs (incurring their +computational cost), and are not natively aggregatable.

+

Memo chunk size

+

TODO: this table needs to be recalculated with a 16 KiB limit.

+

With 10 KiB limit on amount of memo data as the constant in this +table, the maximum number of unique memos you can create, and the cost +in bytes of that memo data plus auth when using a 32-byte memo key, +is:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Memo size
Chunk size≤ 256 bytes512 bytes
========================================================
Pre-23120 @ 10240 ( 0.00%)20 @ 10240 ( 0.00%)
51220 @ 11220 (+ 9.57%)20 @ 11220 (+ 9.57%)
25640 @ 12200 (+19.14%)20 @ 11540 (+12.70%)
256 20-out20 @ 6100 (-40.43%)
+

In the “256 20-out” case you have a distinguisher compared to old +transactions, in that you can tell the transaction is sending at most +256 bytes per recipient rather than 512 if it is sending the max number +of memos. But that’s inherently baked into the decision to use a smaller +memo chunk size (and it is still possible for the chunks to all be a +single memo sent to all outputs, or anything in between).

+

Memo key size

+

If we used a 16-byte memo key instead of 32 bytes, the transaction +size overhead becomes:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Memo size
Chunk size≤ 256 bytes512 bytes
========================================================
Pre-23120 @ 10240 ( 0.00%)20 @ 10240 ( 0.00%)
51220 @ 10900 (+ 6.45%)20 @ 10900 (+ 6.45%)
25640 @ 11560 (+12.89%)20 @ 11220 (+ 9.57%)
256 20-out20 @ 5780 (-43.55%)
+

The decrease in overhead is relatively modest in most cases, but more +noticeable for small memos with a 256-byte memo chunk.

+

However, 128-bit keys don’t meet Zcash’s target security level of 125 +bits, as argued in 14.

+

The benefits of 256-bit keys are:

+
    +
  • They incur only a small transaction size overhead above the minimum +key size that would meet the target security level.
    • +
  • This key length matches what we already use elsewhere for symmetric +keys.
    • +
+

Encryption format

+

Including a per-transaction salt in +the derivation of encryptionkey gives protection +against accidental (or intentional) reuse of Kmemo reuse across multiple +transactions. We do not protect against Kmemo reuse within a transaction; +it is up to the transaction builder to ensure that the same Kmemo is not used to encrypt two +different memos (and if they did so, normal clients would either never +observe the second memo, or would decrypt parts of each memo and get a +nonsensical and potentially insecure “spliced” memo).

+

We do not include commitments to the shielded outputs in the +derivation of encryptionkey +for two reasons:

+
    +
  • It would force the transaction builder to fully define all shielded +outputs before encrypting the memos, which might prevent potential use +cases of PCZTs 15.
    • +
  • We don’t want to unnecessarily prevent the ability to create a +transaction with a memo bundle and no shielded outputs, as there may be +use cases for, e.g. a fully-transparent transaction with encrypted memo, +or a ZSA issuance transaction with exposed memo data using a well-known +Kmemo.
    • +
+

Pruned encoding

+

The separation of memo data from note data, and the new ability to +easily store variable-length memo data, opens up an attack vector +against node operators for storing arbitrary data. The transaction +digest commitments to the memo bundle are structured such that if a node +operator is presented with a memo key (i.e. they are given the +capability to decrypt a particular memo), they can identify and prune +the corresponding memo chunks, while still enabling the transaction to +be validated as part of its corresponding block and broadcast over the +network.

+

The transaction encoding permits pruning at the individual chunk +level in order to facilitate pruning an individual memo from a +transaction without affecting the other memos. This enables node +operators to be responsive to, for example, GDPR deletion requests.

+

Note that broadcasting a partially-pruned transaction means that the +pruned chunks no longer contribute to the upper bound on memo data.

+

The prunable structure does not introduce a censorship axis; memo +bundles do not reveal which memo chunks correspond to which memos, and +therefore a network adversary cannot selectively censor individual +memos. They can censor any/all chunks within specific transactions, +however shielded transactions do not reveal their senders, recipients, +or amounts, and thus also cannot be individually targeted for +censorship.

+

Transaction fees

+

Making the fee linear in the number of chunks has the following +properties:

+
    +
  • The required fee to add more memo chunks scales at the same rate as +adding logical actions, so it isn’t a cheaper mechanism for an adversary +to bloat chain size.
    • +
  • A “baseline transaction” (one spent note, one output to an external +recipient with a memo, one change output without a memo) has the same +fee as before.
    • +
  • A “broadcast transaction” (many outputs to different recipients all +given the same memo) is the same fee as before (but a smaller +transaction).
    • +
  • A “many memos transaction” (many outputs to different recipients all +with unique memos) is at most around twice the fee as before.
    • +
+

Combined with the memo bundle size restriction, the maximum +additional fee for a memo bundle over prior transactions is 0.0019 +ZEC.

+

Reference implementation

+

TBD

+

References

+

[^rfc-8439] RFC +8439: ChaCha20 and Poly1305 for IETF Protocols

+
+
+
    +

  1. Information on BCP 14 — +“RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and +“RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key +Words”↩︎

    2. +

  2. Zcash +Protocol Specification, Version 2024.5.1 [NU6] or later↩︎

    3. +

  3. Zcash Protocol Specification, +Version 2024.5.1 [NU6]. Section 3.2.1: Note Plaintexts and Memo +Fields↩︎

    4. +

  4. ZIP 307: Light +Client Protocol for Payment Detection↩︎

    5. +

  5. Zcash Protocol +Specification, Version 2024.5.1 [NU6]. Section 5.5: Encodings of Note +Plaintexts and Memo Fields↩︎

    6. +

  6. Zcash Protocol Specification, +Version 2024.5.1 [NU6]. Section 4.7.2: Sending Notes (Sapling)↩︎

    7. +

  7. Zcash Protocol Specification, +Version 2024.5.1 [NU6]. Section 4.7.3: Sending Notes (Orchard)↩︎

    8. +

  8. Zcash Protocol +Specification, Version 2024.5.1 [NU6]. Section 4.20.1: Encryption +(Sapling and Orchard)↩︎

    9. +

  9. Zcash Protocol Specification, +Version 2024.5.1 [NU6]. Section 4.20.2: Decryption using an Incoming +Viewing Key (Sapling and Orchard)↩︎

    10. +

  10. Zcash Protocol Specification, +Version 2024.5.1 [NU6]. Section 4.20.3: Decryption using a Full Viewing +Key (Sapling and Orchard)↩︎

    11. +

  11. Zcash Protocol Specification, +Version 2024.5.1 [NU6]. Section 4.1.2: Pseudo Random Functions↩︎

    12. +

  12. Online Authenticated-Encryption +and its Nonce-Reuse Misuse-Resistance↩︎

    13. +

  13. ZIP 317: +Proportional Transfer Fee Mechanism↩︎

    14. +

  14. Zcash Protocol +Specification, Version 2024.5.1 [NU6]. Section 8.7: In-band secret +distribution↩︎

    15. +

  15. zcash/zips issue #693: +Standardize a protocol for creating shielded transactions offline↩︎

    16. +
+
- \ No newline at end of file + diff --git a/rendered/zip-0233.html b/rendered/zip-0233.html index e9c1b5254..6d30c9629 100644 --- a/rendered/zip-0233.html +++ b/rendered/zip-0233.html @@ -1,18 +1,19 @@ - ZIP 233: Establish the Zcash Sustainability Fund on the Protocol Level + ZIP 233: Network Sustainability Mechanism: Burning 
ZIP: 233
-Title: Establish the Zcash Sustainability Fund on the Protocol Level
-Owners: Jason McGee <jason@shieldedlabs.com>
-        Mark Henderson <mark@equilibrium.co>
+Title: Network Sustainability Mechanism: Burning
+Owners: Jason McGee <jason@shieldedlabs.net>
+        Zooko Wilcox <zooko@shieldedlabs.net>
         Tomek Piotrowski <tomek@eiger.co>
         Mariusz Pilarek <mariusz@eiger.co>
+        Paul Dann <paul@eiger.co>
 Original-Authors: Nathan Wilcox
 Credits:
 Status: Draft
@@ -25,219 +26,125 @@ 
Terminology

 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.
+
“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.

+
“Issuance” - The method by which ZEC becomes available for
+circulation on the network.

+
“We” - the ZIP Owners and Authors, listed in the above front
+matter.

+
“MAX_MONEY” is the total ZEC supply cap, defined as
+21,000,000 ZEC. This is slightly larger than the supply cap for the
+current issuance mechanism, but is the value used in existing critical
+consensus checks.

 
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.

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

 
Motivation

-
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:

+
This mechanism seeks to address concerns about the sustainability of
+the network design shared by Bitcoin-like systems:

 
    
-
  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 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.
    4. 
+
  4. Long Term Consensus Sustainability: By enabling the
+burning of funds, the network gains the ability to create “headroom”
+between the chain value and MAX_MONEY. This lays necessary
+groundwork for extending the miner reward system, which currently has a
+clear final end date.
    5. 
+
  5. Benefits to ZEC Holders: Burning funds reduces the
+supply of ZEC, benefiting network users in proportion to their holdings
+without requiring them to opt into any scheme, introducing extra risk,
+active oversight, or accounting complexity.
    6. 
 

 
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, 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 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 height commits
-to ZsfBalanceAfter(height) 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
+
The modifications required are:

+
    
+
  1. The addition of a transaction field representing an amount to burn
+for a given transaction.
    2. 
+
  2. The inclusion of the burn amount in the calculated total output
+value for a given transaction.
    3. 
+
  3. Consensus rules to ensure the burned amount is no longer available
+for circulation on the network.
    4. 
+

+
Transaction Format

+
The following field is added to the v6 transaction format [3]:

+
++++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+






BytesNameData TypeDescription
8burnAmountuint64The amount of input value to be burned, in zatoshis.

+
Note: Older transaction versions can continue to be
+supported after a network upgrade, but burning is not possible for these
+transactions. For example, NU5 supports both v4 and v5 transaction
 formats, for both coinbase and non-coinbase transactions.

-
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.
    • 
-

+
Consensus Rules

+
The burned value must now be considered when calculating the total
+output value of a transaction. It should be treated similarly to a
+transparent output, except that there is no way for this value to be
+used as an input in a future transaction.

+
Digests

+
The transaction digest algorithm defined in ZIP 244 [4] is to be
+modified for v6 transactions as follows:

+
Section T.1: header_digest [5] is specified in draft-txv6-sighash [6]
+to read:

+

+
A BLAKE2b-256 hash of the following values:

+
T.1a: version             (4-byte little-endian version identifier including ``fOverwintered`` flag)
+T.1b: version_group_id    (4-byte little-endian version group identifier)
+T.1c: consensus_branch_id (4-byte little-endian consensus branch id)
+T.1d: lock_time           (4-byte little-endian ``nLockTime`` value)
+T.1e: expiry_height       (4-byte little-endian block height)
+T.1f: burn_amount         (8-byte little-endian burn amount value)

+
The personalization field of this hash is set to:

+
ZTxIdHeadersHash

+

 
Rationale

 
All technical decisions in this ZIP are balanced between the
-necessary robustness of the ZSF mechanics, and simplicity of
+necessary robustness of the NSM 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.

+
New transaction field for
+burn amount

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

 
Deployment

-
This ZIP is proposed to activate with Network Upgrade (TODO ZIP
-editors).

+
This ZIP is proposed to activate with Network Upgrade 7.

 
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

+
[2]: ZIP 200: Network Upgrade
+Mechanism

+
[3]: ZIP 230: Version 6 Transaction
+Format

+
[4]: ZIP 244: Transaction Identifier
+Non-Malleability

+
[5]: ZIP 244:
+Transaction Identifier Non-Malleability. Section T.1: Header
+Digest

+
[6]: Draft Tx v6
+Sighash

 
 
diff --git a/rendered/zip-0234.html b/rendered/zip-0234.html
index 5da8eb546..683aecc53 100644
--- a/rendered/zip-0234.html
+++ b/rendered/zip-0234.html
@@ -1,18 +1,19 @@
 
 
 
-    ZIP 234: Smooth Out The Block Subsidy Issuance
+    ZIP 234: Network Sustainability Mechanism: Issuance Smoothing
     
     
     
 
 
 
ZIP: 234
-Title: Smooth Out The Block Subsidy Issuance
-Owners: Jason McGee <jason@shieldedlabs.com>
-        Mark Henderson <mark@equilibrium.co>
+Title: Network Sustainability Mechanism: Issuance Smoothing
+Owners: Jason McGee <jason@shieldedlabs.net>
+        Zooko Wilcox <zooko@shieldedlabs.net>
         Tomek Piotrowski <tomek@eiger.co>
         Mariusz Pilarek <mariusz@eiger.co>
+        Paul Dann <paul@eiger.co>
 Original-Authors: Nathan Wilcox
 Credits:
 Status: Draft
@@ -25,169 +26,188 @@ 
Terminology

 described in RFC 2119. [1]

 
“Network upgrade” - to be interpreted as described in ZIP 200.
 [2]

-
“Block Subsidy” - to be interpreted as described in the Zcash
-Protocol Specification (TODO ZIP Editors: link from comment).

-
“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors:
-work out if this definition is correct or can be removed).

-
“ZsfBalanceAfter(h)” is the total ZEC available in the
-Zcash Sustainability Fund (ZSF) after the transactions in block
-h, described in ZIP draft-zsf.md. In this ZIP, the
-Sustainability Fund is used to pay out Block Subsidies from unmined ZEC,
-and other fund deposits.

+
“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 ZEC becomes available for
+circulation on the network.

 
Let PostBlossomHalvingInterval be as defined in
 [#protocol-diffadjustment]_.

+
“Money Reserve” - MAX_MONEY - ChainValue, where
+ChainValue includes all ZEC available on the network,
+across all value pools.

 
Abstract

 
This ZIP proposes a change to how nodes calculate the block
 subsidy.

 
Instead of following a step function around the 4-year halving
-intervals inherited from Bitcoin, we propose a slow exponential
-“smoothing” of the curve. The new issuance scheme would approximate the
-current issuance over 4-year intervals.

-
This ZIP depends on the ZIP introducing the Zcash Sustainability Fund
-(ZIP-XXX).

+intervals inherited from Bitcoin, we propose a smooth logarithmic curve,
+defined as a fixed portion of the current value of the Money Reserve at
+a given block height.

+
The new issuance scheme would approximate the current issuance over
+4-year intervals, assuming no ZEC is burned during that time, and
+retains the overall supply cap of MAX_MONEY.

 
Motivation

+
Key Objectives:

+
    
+
  1. We want to introduce an automated mechanism that allows users of the
+network to contribute to the long-term sustainability of the
+network.
    2. 
+
  2. We want to enable ZEC that has been burned to be recreated in the
+future to benefit network sustainability.
    3. 
+
  3. We want to retain the existing ZEC supply cap of 21 million.
    4. 
+
  4. We want the issuance rate to remain similar to the historical rate
+for Zcash (and before that, Bitcoin).
    5. 
+
  5. We want issuance to be easy for all network users to understand and
+predict.
    6. 
+
  6. We want the new issuance to activate at a block with as minimal a
+delta from the current issuance as possible.
    7. 
+

 
The current Zcash economic model, inherited from Bitcoin, includes a
-halving mechanism which dictates the issuance of new coins. While this
+halving mechanism that dictates the issuance of new coins. While this
 has been foundational, halvings can lead to abrupt changes in the rate
 of new coins being introduced to the market. Such sudden shifts can
 potentially disrupt the network’s economic model, potentially impacting
 its security and stability. Furthermore, the halvings schedule is fixed
 and does not provide any way to “recycle” funds into future
 issuance.

-
To address this, we propose issuing a fixed portion of the pending
-funds-to-be-issued in each block. This has the effect of smoothing out
-the issuance curve of ZEC, ensuring a more consistent and predictable
-rate of coin issuance, while still preserving the overall supply cap of
-21,000,000 coins. This mechanism by itself (without other anticipated
-changes) seeks to preserve the core aspects of Zcash’s issuance policy
-and aims to enhance predictability and avoid sudden changes. By making
-this shift, the average block subsidy over time will remain predictable
-with very gradual changes.

-
However, we anticipate schemes proposed in [#draft-zsf]_ where the
-amount of funds-to-be-issued may increase. In that scenario, this
-issuance mechanism would distribute that increase starting in the
-immediately following block and subsequent blocks. Because this
-distribution mechanism has an exponential decay, such increases will be
-spread out in miniscule amounts to future blocks over a long time
-period. This issuance mechanism thus provides a way for potential
-increases or decreases of issuance while constraining those changes to
-be small on a short time scale to avoid unexpected disruptions.

-
Additionally, the current Bitcoin-style issuance does not take into
-account the current balance of ZsfBalanceAfter(h). If
-[#draft-zsf]_ were to activate without a change to the issuance
-mechanism, then some funds would never be disbursed after they are
-deposited back into the ZSF.

+
This new NSM-based issuance scheme solves these problems by ensuring
+a more consistent and predictable rate of coin issuance, while
+preserving the core aspects of Zcash’s issuance policy and the 21
+million coin cap. At the same time, it introduces the first mechanism to
+recreate and distribute ZEC that has been removed from circulation, as
+well as unclaimed transaction fees, across future block subsidies.

 
Requirements

 
Smoothing the issuance curve is possible using an exponential decay
 formula that satisfies the following requirements:

-
Issuance Requirements

 
    
-
  1. The issuance can be summarised into a reasonably simple
+
  2. The issuance can be summarized into a reasonably simple
 explanation
    3. 
 
  3. Block subsidies approximate a continuous function
    4. 
-
  4. If there are funds in the ZSF, then the block subsidy must be
-non-zero, preventing any final “unmined” zatoshis
    5. 
+
  5. If the Money Reserve is greater than 0, then the block subsidy must
+be non-zero, preventing any final “unmined” zatoshis
    6. 
 
  6. For any 4 year period, all paid out block subsidies are
-approximately equal to half of the ZSF at the beginning of that 4 year
-period, if there are no deposits into the ZSF during those 4 years
    7. 
+approximately equal to half of the Money Reserve at the beginning of
+that 4 year period, if no ZEC is burned during those 4 years
+
  7. Decrease the short-term impact of the deployment of this ZIP on
+block reward recipients, and minimize the potential reputation risk to
+Zcash of changing the block reward amount.
    8. 
 

 
TODO daira: add a requirement that makes the initial total issuance
 match the previous total issuance

 
Specification

-
Goals

-
We want to decrease the short-term impact of the deployment of this
-ZIP on block reward recipients, and minimise the potential reputational
-risk to Zcash of changing the block reward amount.

-
Constants

-
Define constants:

-
“BLOCK_SUBSIDY_FRACTION” = 4126 / 10,000,000,000 or
+
Parameters

+
BLOCK_SUBSIDY_FRACTION = 4126 / 10,000,000,000 or
 0.0000004126

-
“DEPLOYMENT_BLOCK_HEIGHT” = 2726400

+
DEPLOYMENT_BLOCK_HEIGHT = TBD

+
The block height will be chosen by the following criteria:

+
    
+
  • It is after NU7 activation height.
    • 
+
  • It is calculated to be the lowest height after the the second
+halving at which the NSM issuance would be less than the current
+BTC-style issuance neglecting any burnt ZEC (ie. assuming the
+amount of ZEC burnt is exactly 0).
    • 
+

+
This selection is intended to achieve Key Objective 6 while still
+being a constant height. An alternative would be to have a dynamic
+“latch” style activation which would calculate the activation height by
+testing the “less than” conditional with every block after the second
+halving. We prefer the pre-defined constant height parameter to give
+everyone more time certainty at the cost of issuance
+level certainty. The difference in up-front calculation versus
+dynamic calculation is whether or not burns are accounted for (since
+future burns cannot be calculated up-front). This means with the
+pre-defined constant parameter approach, issuance will jump up
+some amount at activation. This amount should be equivalent to all ZEC
+burnt prior to that height times BLOCK_SUBSIDY_FRACTION.
+For example, if a total of 100,000 ZEC were burnt prior to the
+pre-defined constant activation height, then at activation the issuance
+would be larger than BTC-style issuance by
+100_000 ZEC * BLOCK_SUBSIDY_FRACTION which we calculate
+equals 0.04126 ZEC. This example is chosen to demonstrate
+that a very large burn amount (much larger than expected) would elevate
+issuance by a relatively small amount. For this reason, we believe a
+pre-defined constant is a better approach to achieving Key Objective 6
+than a “dynamic latch” logic because it is so much simpler to implement
+and reason about.

+
MoneyReserveAfter(block_height) = The value of the Money
+Reserve after the specified block height.

 
Issuance Calculation

 
At the DEPLOYMENT_BLOCK_HEIGHT, nodes should switch from
 the current issuance calculation, to the following:

-
Given the block height h define a function
-BlockSubsidy(h), such that:

-
BlockSubsidy(h) = Block subsidy for a given
-h, that satisfies above requirements.

-
Using an exponential decay function for BlockSubsidy
-satisfies requirements R1 and R2
-above:

-
BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)

-
Finally, to satisfy R3 above we always round up to
-the next zatoshi.

-
BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))

+
BlockSubsidy(block_height) = ceiling(BLOCK_SUBSIDY_FRACTION * MoneyReserveAfter(block_height - 1))

 
Rationale

+
    
+
  • Using an exponential decay function satisfies Requirements
+1 and 2 above.
    • 
+
  • We round up to the next zatoshi to satisfy Requirement
+3 above.
    • 
+

 
BLOCK_SUBSIDY_FRACTION

-
Let IntendedZSFFractionRemainingAfterFourYears =
-0.5.

+
Let IntendedMoneyReserveFractionRemainingAfterFourYears
+= 0.5.

 
The value 4126 / 10_000_000_000 satisfies the
 approximation within +0.002%:

-
(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears

-
Meaning after a period of 4 years around half of
-ZSF_BALANCE will be paid out as block subsidies, thus
-satisfying R4.

-
The largest possible amount in the ZSF is MAX_MONEY, in the
-theoretically possible case that all issued funds are deposited back
-into the ZSF. If this happened, the largest interim sum in the block
-subsidy calculation would be MAX_MONEY * 4126 + 10000000000.

+
(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedMoneyReserveFractionRemainingAfterFourYears

+
Meaning after a period of 4 years around half of Money Reserve will
+be issued as block subsidies, thus satisfying Requirement
+4.

+
The largest possible value in the Money Reserve is
+MAX_MONEY, in the theoretically possible case that all
+issued funds are burned. If this happened, the largest interim sum in
+the block subsidy calculation would be
+MAX_MONEY * 4126 / 10000000000.

 
This uses 62.91 bits, which is just under the 63 bit limit for 64-bit
 signed two’s-complement integer amount types.

 
The numerator could be brought closer to the limit by using a larger
 denominator, but the difference in the amount issued would be very
 small. So we chose a power-of-10 denominator for simplicity.

 
TODO for ZIP owners: How many ZEC per day?

-
DEPLOYMENT_BLOCK_HEIGHT

-
The deployment should happen at the next halving, which is block
-2726400.

-
Since there is a planned halving at this point, there will already be
-a significant “shock” caused by the drop in issuance caused by the
-halving. This reduces surprise and thus increases security. Also, due to
-the nature of the smoothed curve having a portion of the curve above the
-respective step function line at times, this will maximally
-reduce the issuance shock at the
-DEPLOYMENT_BLOCK_HEIGHT.

 
Visualization of the
 Smoothed Curve

-
The following graph illustrates compares issuance for the current
-halving-based step function vs the smoothed curve.

+
The following graph compares issuance for the current halving-based
+step function vs the smoothed curve.

 

 A graph showing a comparison of the halving-based step function vs the smoothed curve
 
 

-
The graph below shows the balance of the ZSF assuming smooth issuance
-is implemented.

+
The graph below shows the balance of the Money Reserve assuming
+smooth issuance is implemented.

 

 
-
+alt="A graph showing the balance of the Money Reserve assuming smooth issuance is implemented" />
+
 

 
Deployment

 
The implementation of this ZIP MUST be deployed at the same time or
-after the Zcash Sustainability Fund is established (ZIP-XXX).

+after the Network Sustainability Mechanism Burning function is deployed
+(ZIP-0233).

 
Appendix: Simulation

-
The ZSF
-simulator allows us to simulate the effects of this ZIP on the ZSF
-balance and the block subsidy, as well as generate plots like the ones
+
The NSM
+Simulator allows us to simulate the effects of this ZIP on the Money
+Reserve and the block subsidy, as well as generate plots like the ones
 above. Its output:

 
Last block is 47917869 in ~113.88 years

-
indicates that, assuming no ZEC is ever deposited to the ZSF, its
-balance will be depleted after 113.88 years, and the block subsidy will
+
indicates that, assuming that no ZEC is ever burned, the Money
+Reserve will be depleted after 113.88 years, and the block subsidy will
 be 0 ZEC after that point.

-
This fragment of the output

+
This fragment of the output:

 
Halving  1 at block  1680000:
-  ZSF subsidies:    262523884819889 (~ 2625238.848 ZEC,        1.563 ZEC per block)
+  NSM subsidies:    262523884819889 (~ 2625238.848 ZEC,        1.563 ZEC per block)
   legacy subsidies: 262500000000000 (~ 2625000.000 ZEC,        1.562 ZEC per block)
-  difference:           23884819889 (~         238 ZEC),         ZSF/legacy: 1.0001

+  difference:           23884819889 (~         238 ZEC),         NSM/legacy: 1.0001

 
shows that the difference between the smoothed out and the current
-issuance schemes is 238 ZEC after 1680000 blocks (aroound 4 years).

+issuance schemes is 238 ZEC after 1680000 blocks (around 4 years).

+
Appendix: Considerations
+for the Future

+
Future protocol changes may not increase the payout rate to a
+reasonable approximation beyond the four year half-life constraint.

 
References

 
[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119

-
[2] ZIP-200: https://zips.z.cash/zip-0200

-
[3] ZIP-XXX: Placeholder for the ZSF ZIP

+
[2] ZIP-200: Network Upgrade Mechanism

+
[3] ZIP_233: Network Sustainability Mechanism:
+Burning

 
 
diff --git a/rendered/zip-0235.html b/rendered/zip-0235.html
new file mode 100644
index 000000000..6cc81095b
--- /dev/null
+++ b/rendered/zip-0235.html
@@ -0,0 +1,140 @@
+
+
+
+    ZIP 235: Burn 60% of Transaction Fees
+    
+    
+    
+
+
+
ZIP: 235
+Title: Burn 60% of Transaction Fees
+Owners: Jason McGee <jason@shieldedlabs.net>
+        Zooko Wilcox <zooko@shieldedlabs.net>
+        Tomek Piotrowski <tomek@eiger.co>
+        Mariusz Pilarek <mariusz@eiger.co>
+        Paul Dann <paul@eiger.co>
+Original-Authors: Nathan Wilcox
+Credits:
+Status: Draft
+Category: Ecosystem
+Created: 2023-09-21
+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 ZEC becomes available for
+circulation on the network.

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

+
Abstract

+
We propose to burn 60% of transaction fees, while the remaining 40%
+be directed as before, providing a deflationary effect, and building the
+groundwork for long-term support of the Zcash network via the new block
+subsidy rules proposed by ZIP-234.

+
Motivation

+
ZIP-233 (“Network Sustainability Mechanism: Burning”) describes a
+method by which ZEC can be burned to support network sustainability.

+
By introducing a requirement that a certain proportion of transaction
+fees be burned, we ensure that ZEC will be removed from circulating
+supply to contribute to the long-term sustainability of the network as
+described below:

+
Benefits to the Network

+
    
+
  1. Network Sustainability: This mechanism involves
+temporarily reducing the supply of ZEC, similar to asset burning in
+Ethereum’s EIP-1559, but with long-term sustainability benefits, as the
+burned funds effectively boost future mining rewards, making it an
+attractive option for current and future Zcash users.
    2. 
+
  2. Incentivizing Transaction Inclusion: By maintaining
+a 40% share of transaction fees for miners, we continue incentivizing
+miners to prioritize including transactions in their blocks. This helps
+ensure the continued efficient processing of transactions and supports a
+robust and responsive network.
    3. 
+
  3. Aligning Interests: Burning transaction fees aligns
+the interests of miners with the long-term health of the network,
+incentivizing them to prioritize security and efficiency. As miners
+focus on maintaining a robust network, overall adoption and usage can
+increase, leading to higher transaction volumes in the long run. This
+structure discourages short-term profit-seeking behaviors, as miners
+benefit more from a stable and thriving ecosystem than from engaging in
+malicious activities that could undermine the network’s reputation and
+security.
    4. 
+
  4. Future-Proofing the Network: Burning a portion of
+transaction fees is a forward-looking approach that prepares the Zcash
+network for future challenges and opportunities. It establishes a
+financial buffer that can be instrumental in addressing unforeseen
+issues and seizing strategic advantages as the Zcash ecosystem
+evolves.
    5. 
+

+
Requirements

+
    
+
  • For each block, at least 60% (rounded down) of the total fees are to
+be burned.
    • 
+
  • No restrictions are placed on the destination of the remaining
+proportion of fees.
    • 
+
  • Any fractions are rounded in favor of the miner.
    • 
+

+
Specification

+
Consensus Rule Changes

+
For a given block, the coinbase transaction MUST have a
+burnAmount that is greater than or equal to
+floor(transactionFees * 6 / 10).

+
Previous transaction versions are not supported for coinbase
+transactions, due to there being no explicit mechanism to burn the
+required funds.

+
Deployment

+
The implementation of this ZIP MUST be deployed at the same time or
+after ZIP-233 (“NSM: Burning”), and ZIP-234 (“NSM: Issuance
+Smoothing”).

+
Rationale

+
We believe the proposed changes to be relatively low-impact in terms
+of implementation and protocol changes. Additionally, transaction fees
+are currently small enough that the reduction in miner fees is unlikely
+to be a concern.

+
Estimated impact on miners

+
Over 100,000 blocks starting at block 2235515, there were 316130
+transactions. 60608 of them are categorized as ‘sandblasting’
+transactions. The remaining transactions have an average of 5.46 logical
+actions (see ZIP-317 [4]).

+
The total fees paid to miners from those transactions, assuming the
+ZIP-317 regime, would be 87.86 ZEC. 100,000 blocks is approximately 3
+months of blocks. Extrapolating to a year, we would expect 351.44 ZEC in
+fees paid to miners over a year.

+
If 60% of these fees burned, that would be 210.864 ZEC per year.
+[5]

+
Considerations for the
+Future

+
If transaction fees were to increase, further modifications can
+easily be proposed to alter the 60%/40% split. Finding the optimal fee
+split may require an iterative approach involving adjustments based on
+real-world data and network dynamics.

+
Looking further into the future, there may come a time when the
+transaction fees become greater than the block subsidy issuance. At that
+time we may need to reconsider the 60/40 split. However, this will
+likely not be the case for the next 8-10 years due to forecasts based on
+issuance models and network traffic.

+
Further ZIPs may be proposed to burn ZEC in various ways to support
+network sustainability, including but not limited to:

+
    
+
  • ZSA fees
    • 
+
  • Fees and donations specific to decentralized applications
    • 
+
  • “Storage fees” for any future data availability
    • 
+
  • Cross-chain bridge usage / Cross-chain messaging
    • 
+
  • Note sorting micro-transactional fees
    • 
+

+
References

+
[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119

+
[2] ZIP 200: Network Upgrade Mechanism

+
[3] ZIP 233: Establish the Zcash Sustainability
+Fund on the Protocol Level

+
[4] ZIP 317: Proportional Transfer Fee
+Mechanism

+
[5] https://github.com/eigerco/zsf-fee-estimator

+
+
diff --git a/rendered/zip-0253.html b/rendered/zip-0253.html
index 6aff55a18..ebe35ea36 100644
--- a/rendered/zip-0253.html
+++ b/rendered/zip-0253.html
@@ -103,48 +103,49 @@ 
Backward compatibility

 valid across the NU6 activation, since signatures MUST use the
 appropriate consensus branch ID.

 
References

-

 

 
    
-
  1. Information on BCP 14 —
 “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and
 “RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
 Words”↩︎
    2. 
-
  2. ZIP 200: Network Upgrade
-Mechanism
    ZIP 200:
+Network Upgrade Mechanism↩︎
    3. 
-
  3. Zcash Protocol
-Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and
-Testnet↩︎
    4. 
-
  4. Zcash Protocol
-Specification, Version 2024.5.1 or later
    Zcash Protocol Specification,
+Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet↩︎
    5. 
+
  5. Zcash
+Protocol Specification, Version 2024.5.1 or later↩︎
    6. 
-
  6. ZIP 200: Network Upgrade
-Mechanism↩︎
    7. 
-
  7. ZIP 236: Blocks should balance
-exactly
    ZIP 200:
+Network Upgrade Mechanism↩︎
    8. 
-
  8. ZIP 1015: Block Reward Allocation
-for Non-Direct Development Funding↩︎
    9. 
-
  9. ZIP 2001: Lockbox Funding
-Streams
    ZIP 236:
+Blocks should balance exactly↩︎
    10. 
-
  10. ZIP 201: Network Peer Management
-for Overwinter
    ZIP 1015:
+Block Reward Allocation for Non-Direct Development Funding↩︎
    11. 
+
  11. ZIP 2001:
+Lockbox Funding Streams↩︎
    12. 
-
  12. ZIP 207: Funding Streams↩︎
    13. 
-
  13. ZIP 214: Consensus rules for a
-Zcash Development Fund
    ZIP 201:
+Network Peer Management for Overwinter↩︎
    14. 
+
  14. ZIP 207:
+Funding Streams↩︎
    15. 
-
  15. ZIP 200: Network Upgrade
-Mechanism
    ZIP 214:
+Consensus rules for a Zcash Development Fund↩︎
    16. 
+
  16. ZIP 200:
+Network Upgrade Mechanism↩︎
    17. 
 

 

diff --git a/rendered/zip-0254.html b/rendered/zip-0254.html
new file mode 100644
index 000000000..63c5e528b
--- /dev/null
+++ b/rendered/zip-0254.html
@@ -0,0 +1,115 @@
+
+
+
+    ZIP 254: Deployment of the NU7 Network Upgrade
+    
+    
+    
+
+
+
ZIP: 254
+Title: Deployment of the NU7 Network Upgrade
+Owners: Arya <arya@zfnd.org>
+Status: Draft
+Category: Consensus / Network
+Created: 2024-10-31
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/839>

+
Terminology

+
The key word “MUST” in this document are to be interpreted as
+described in BCP 14 1 when, and only when, they appear in
+all capitals.

+
The term “network upgrade” in this document is to be interpreted as
+described in ZIP 200 2.

+
The terms “Testnet” and “Mainnet” are to be interpreted as described
+in section 3.12 of the Zcash Protocol Specification 3.

+
Abstract

+
This proposal defines the deployment of the NU7 network upgrade.

+
Specification

+
NU7 deployment

+
The primary sources of information about NU7 consensus protocol
+changes are:

+
    
+
  • The Zcash Protocol Specification 4.
    • 
+
  • ZIP 200: Network Upgrade Mechanism 5.
    • 
+

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

+
The following network upgrade constants 7 are
+defined for the NU7 upgrade:

+

+
CONSENSUS_BRANCH_ID

+

+0x77190AD8
+

+
ACTIVATION_HEIGHT (NU7)

+

+Testnet: TBD
+

+

+Mainnet: TBD
+

+
MIN_NETWORK_PROTOCOL_VERSION (NU7)

+

+Testnet: 170130
+

+

+Mainnet: 170140
+

+

+
For each network (Testnet and Mainnet), nodes compatible with NU7
+activation on that network MUST advertise a network protocol version
+that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU7)
+for that activation.

+
Backward compatibility

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

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

+
References

+

+

+
    
+
  1. Information on BCP 14 —
+“RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and
+“RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
+Words”↩︎
    2. 
+
  2. ZIP 200:
+Network Upgrade Mechanism↩︎
    3. 
+
  3. Zcash Protocol Specification,
+Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet↩︎
    4. 
+
  4. Zcash
+Protocol Specification, Version 2024.5.1 or later↩︎
    5. 
+
  5. ZIP 200:
+Network Upgrade Mechanism↩︎
    6. 
+
  6. ZIP 201:
+Network Peer Management for Overwinter↩︎
    7. 
+
  7. ZIP 200:
+Network Upgrade Mechanism↩︎
    8. 
+

+

+
+
diff --git a/rendered/zip-2004.html b/rendered/zip-2004.html
new file mode 100644
index 000000000..4b10b1705
--- /dev/null
+++ b/rendered/zip-2004.html
@@ -0,0 +1,166 @@
+
+
+
+    ZIP 2004: Remove the dependency of consensus on note encryption
+    
+    
+
+
+    

+        
ZIP: 2004
+Title: Remove the dependency of consensus on note encryption
+Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+Status: Draft
+Category: Consensus
+Created: 2024-10-22
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/917>
+Pull-Request: <https://github.com/zcash/zips/pull/918>

+        
Terminology 

+            
The key word "MUST" in this document is to be interpreted as described in BCP 14 1 when, and only when, it appears in all capitals.

+            
The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 4

+            
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification. 3

+            
The character § is used when referring to sections of the Zcash Protocol Specification 2.

+        

+        
Abstract 

+            
ZIP 213 6 added the ability for coinbase outputs to be shielded. An unfortunate side effect of this was to make consensus dependent on the details of note encryption. This has unnecessarily complicated the specification and implementation of consensus rules.

+            
This proposal disentangles note encryption from consensus, by instead requiring coinbase outputs for v6 and later transaction versions to be unencrypted. The disentanglement will be complete once earlier transaction versions are no longer allowed on the network, which is likely to happen in some later upgrade.

+        

+        
Motivation 

+            
In the original design of Zcash, the consensus protocol was carefully isolated from the details of note encryption. This property, which was preserved through the Overwinter, Sapling, and Blossom upgrades, reduces the complexity and attack surface of the consensus protocol. It also potentially allows changes to note encryption to be made outside network upgrades.

+            
A dependency on note encryption crept into the consensus protocol as a result of the changes to support shielded coinbase outputs in ZIP 213 6, deployed in the Heartwood network upgrade. These changes added the requirement that it must be possible to decrypt Sapling and Orchard outputs in coinbase transactions using a sequence of 32 zero bytes as the outgoing viewing key.

+            
The complexity impact of this change was overlooked. This became apparent during the design of ZIP 212 5 for the Heartwood network upgrade. In fact for a time there were separate and slightly diverging implementations of note decryption for the consensus checks in zcashd, and in librustzcash. This could have led to a chain fork between zcashd and zebrad before the implementations were reconciled.

+            
This ZIP restores the originally intended design property.

+        

+        
Requirements 

+            
The consensus rule change specified in this ZIP must, from transaction version 6 onward, make the implementation and specification of shielded coinbase outputs independent of note encryption.

+        

+        
Specification 

+            
Changes to the protocol specification 

+                
In § 5.4.3 'Symmetric Encryption', rename
+                    \(Sym\)
+                 to
+                    \(NoteSym\)
+                 and add the following text:

+                

+                    

+                        
Let
+                            \(\mathsf{NullSym.}\mathbf{K} := \mathbb{B}^{[256]}\)
+                        ,

+                        

+                            \(\mathsf{NullSym.}\mathbf{P} := \mathbb{B^Y}^{\mathbb{N}}\)
+                        , and
+                            \(\mathsf{NullSym.}\mathbf{C} := \mathbb{B^Y}^{\mathbb{N}}\)
+                        .

+                    

+                    
Let
+                        \(\mathsf{NullSym.Encrypt_K}(\mathsf{P}) := \mathsf{P} || [0x00]^{16}\)
+                    .

+                    
Define
+                        \(\mathsf{NullSym.Decrypt_K}(\mathsf{C})\)
+                     as follows:

+                    
    
+                        
  • If the last 16 bytes of
+                            \(\mathsf{C}\)
+                         are not
+                            \([0x00]^{16}\)
+                        , return
+                            \(\bot\)
+                        . Otherwise discard those 16 bytes and return the remaining prefix of
+                            \(\mathsf{C}\)
+                        .
    • 
+                    

+                    
Note: These definitions intentionally ignore the key;
+                        \(\mathsf{NullSym}\)
+                     is not a secure authenticated encryption scheme. It MUST be used only for notes in shielded coinbase outputs, which are intended to be visible as cleartext.

+                

+                
In § 4.20 'In-band secret distribution (Sapling and Orchard)', change:

+                

+                    
let
+                        \(\mathsf{Sym}\)
+                     be the encryption scheme instantiated in § 5.4.3 'Symmetric Encryption'.

+                

+                
to

+                

+                    
let
+                        \(\mathsf{NoteSym}\)
+                     and
+                        \(\mathsf{NullSym}\)
+                     be as instantiated in § 5.4.3 'Symmetric Encryption'.

+                    
[Pre-NU7] let
+                        \(\mathsf{Sym}\)
+                     be
+                        \(\mathsf{NoteSym}\)
+                    .

+                    
[NU7 onward] if the note to be decrypted is in an output of a version 6 or later coinbase transaction, let
+                        \(\mathsf{Sym}\)
+                     be
+                        \(\mathsf{NullSym}\)
+                    , otherwise let it be
+                        \(\mathsf{NoteSym}\)
+                    .

+                

+            

+        

+        
Deployment 

+            
This ZIP is proposed to be deployed with the next transaction version change, which is assumed to be v6.

+        

+        
Reference implementation 

+            
TBD.

+        

+        
Acknowledgements 

+            
The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP.

+        

+        
References 

+            
+                
+                    
+                        
+                        
+                    
+                
+            
1Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"

+            
+                
+                    
+                        
+                        
+                    
+                
+            
2Zcash Protocol Specification, Version 2024.5.1 or later

+            
+                
+                    
+                        
+                        
+                    
+                
+            
3Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet

+            
+                
+                    
+                        
+                        
+                    
+                
+            
4ZIP 200: Network Upgrade Mechanism

+            
+                
+                    
+                        
+                        
+                    
+                
+            
5ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext

+            
+                
+                    
+                        
+                        
+                    
+                
+            
6ZIP 213: Shielded Coinbase

+        

+    

+
+
\ No newline at end of file
diff --git a/rendered/zip-guide-markdown.html b/rendered/zip-guide-markdown.html
index bd3f10743..19abb4347 100644
--- a/rendered/zip-guide-markdown.html
+++ b/rendered/zip-guide-markdown.html
@@ -212,38 +212,42 @@ 
Reference implementation

 
{This section is entirely optional; if present, it usually gives
 links to zcashd or zebrad PRs.}

 
References

-

 

 
    
-
  1. Information on BCP 14 —
 “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and
 “RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
 Words”↩︎
    2. 
-
  2. Zcash Protocol
-Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎
    3. 
-
  3. Zcash
-Protocol Specification, Version 2022.3.8. Section 3.3: The Block
-Chain↩︎
    4. 
-
  4. Zcash Protocol
-Specification, Version 2022.3.8 or later
    Zcash Protocol Specification,
+Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎
    5. 
+
  5. Zcash Protocol Specification,
+Version 2022.3.8. Section 3.3: The Block Chain↩︎
    6. 
+
  6. Zcash
+Protocol Specification, Version 2022.3.8 or later↩︎
    7. 
-
  7. Zcash
-Protocol Specification, Version 2022.3.8. Section 1: Introduction↩︎
    8. 
-
  8. Zcash Protocol
-Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎
    9. 
-
  9. ZIP 0: ZIP Process↩︎
    10. 
-
  10. KaTeX - The fastest math
-typesetting library for the web
    Zcash Protocol Specification,
+Version 2022.3.8. Section 1: Introduction↩︎
    11. 
+
  11. Zcash Protocol Specification,
+Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎
    12. 
+
  12. ZIP 0: ZIP
+Process↩︎
    13. 
+
  13. KaTeX -
+The fastest math typesetting library for the web↩︎
    14. 
-
  14. The
 Hunting of the Snark. Lewis Carroll, with illustrations by Henry
 Holiday. MacMillan and Co. London. March 29, 1876.