diff --git a/README.rst b/README.rst index ea74f770f..e9376841c 100644 --- a/README.rst +++ b/README.rst @@ -123,7 +123,7 @@ Released ZIPs 321 Payment Request URIs Proposed 401 Addressing Mempool Denial-of-Service Active 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 1015 Block Subsidy Allocation for Non-Direct Development Funding Proposed 2001 Lockbox Funding Streams Implemented (zcashd and zebrad) @@ -342,7 +342,7 @@ Index of ZIPs 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 1015 Block Subsidy 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 diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 5f76e4b77..e719ee1ae 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -650,7 +650,11 @@ \newcommand{\labelcolor}{cream} \iftoggle{isnusix}{ - \providecommand{\baseurl}{https://zips.z.cash/protocol/protocol.pdf} + \iftoggle{darkmode}{ + \providecommand{\baseurl}{https://zips.z.cash/protocol/protocol-dark.pdf} + }{ + \providecommand{\baseurl}{https://zips.z.cash/protocol/protocol.pdf} + } \toggletrue{isnufive} \newcommand{\setnusix}{\color{\nusixcolor}} \newcommand{\nusix}[1]{\texorpdfstring{{\setnusix{#1}}}{#1}} diff --git a/protocol/zcash.bib b/protocol/zcash.bib index ec823e03d..da172b9ff 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -1519,7 +1519,7 @@ @misc{ZIP-1014 @misc{ZIP-1015, presort={ZIP-1015}, author={Jason McGee and @Peacemonger and Kris Nuttycombe}, - title={Block Reward Allocation for Non-Direct Development Funding}, + title={Block Subsidy Allocation for Non-Direct Development Funding}, howpublished={Zcash Improvement Proposal 1015. Created August~26, 2024.}, url={https://zips.z.cash/zip-1015}, urldate={2024-09-24} diff --git a/rendered/index.html b/rendered/index.html index 3c6e50835..f06b03aa4 100644 --- a/rendered/index.html +++ b/rendered/index.html @@ -88,7 +88,7 @@ 321 Payment Request URIs Proposed 401 Addressing Mempool Denial-of-Service Active 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 1015 Block Subsidy Allocation for Non-Direct Development Funding Proposed 2001 Lockbox Funding Streams Implemented (zcashd and zebrad)

Draft ZIPs

@@ -278,7 +278,7 @@ 1012 Dev Fund to ECC + ZF + Major Grants Obsolete 1013 Keep It Simple, Zcashers: 10% to ECC, 10% to ZF Obsolete 1014 Establishing a Dev Fund for ECC, ZF, and Major Grants Active - 1015 Block Reward Allocation for Non-Direct Development Funding Proposed + 1015 Block Subsidy 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 diff --git a/rendered/protocol/protocol-dark.pdf b/rendered/protocol/protocol-dark.pdf index fa1e45a63..980574e9b 100644 Binary files a/rendered/protocol/protocol-dark.pdf and b/rendered/protocol/protocol-dark.pdf differ diff --git a/rendered/protocol/protocol.pdf b/rendered/protocol/protocol.pdf index d9be9d18c..f2e608236 100644 Binary files a/rendered/protocol/protocol.pdf and b/rendered/protocol/protocol.pdf differ diff --git a/rendered/zip-0207.html b/rendered/zip-0207.html index cebc673ba..6be0e0d5d 100644 --- a/rendered/zip-0207.html +++ b/rendered/zip-0207.html @@ -36,7 +36,7 @@

Motivation

Motivation for the Zcash Development Fund is considered in ZIP 1014 20.

This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP was reintroduced for that purpose in the Canopy upgrade in order to reuse specification, analysis, and implementation effort.

-

As of NU6, ZIP 1015 21 directs part of the block reward to a reserve, the distribution of which is to be determined via a future ZIP. ZIP 2001 22 modified this ZIP to augment the funding stream mechanism with a common mechanism to implement this proposal.

+

As of NU6, ZIP 1015 21 directs part of the block subsidy to a reserve, the distribution of which is to be determined via a future ZIP. ZIP 2001 22 modified this ZIP to augment the funding stream mechanism with a common mechanism to implement this proposal.

Requirements

The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 17 to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 20, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.

@@ -451,7 +451,7 @@ 21 - ZIP 1015: Block Reward Allocation for Non-Direct Development Funding <zip-1015.rst> + ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding <zip-1015.rst> diff --git a/rendered/zip-0213.html b/rendered/zip-0213.html index f40ada08c..cc6874324 100644 --- a/rendered/zip-0213.html +++ b/rendered/zip-0213.html @@ -23,7 +23,7 @@

This proposal defines modifications to the Zcash consensus rules that enable coinbase funds to be mined to Sapling (and later Orchard) addresses. It does not disable the use of transparent addresses in coinbase transactions.

Motivation

-

Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions inside each block that are allowed to have no inputs. These transactions are created by miners during block creation, and collect the block reward and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the Founders' Reward (and potentially for funding streams 4).

+

Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions inside each block that are allowed to have no inputs. These transactions are created by miners during block creation, and collect the block subsidy and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the Founders' Reward (and potentially for funding streams 4).

On the path to deprecating and removing Bitcoin-inherited transparent addresses within the Zcash network, a required step is to be able to create coinbase transactions that have no transparent outputs. However, Zcash was launched with a consensus rule preventing coinbase transactions from containing shielded outputs, instead enforcing that coinbase funds could not be spent in transactions with transparent outputs. This was partly in order to reduce the complexity of the original Zcash modifications to the Bitcoin Core codebase, but also because at the time, shielded transactions required significant memory and CPU resources to create.

The Sapling network upgrade 3 deployed architectural changes and performance improvements that make shielding funds directly in the coinbase transaction feasible. In order to reduce the complexity of the Sapling network upgrade, the existing consensus rules preventing coinbase transactions from containing shielded outputs were extended to cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in order to enable miners to start using Sapling addresses. It will also be possible for miners to use Orchard addresses starting from activation of the NU5 upgrade 6.

diff --git a/rendered/zip-0214.html b/rendered/zip-0214.html index f92bedcbc..75a60ab89 100644 --- a/rendered/zip-0214.html +++ b/rendered/zip-0214.html @@ -29,7 +29,7 @@

Abstract

Revision 0 of this ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.

-

Revision 1 of this ZIP describes consensus rule changes related to funding of Zcash development via block rewards, to be enacted at Network Upgrade 6 and lasting for 1 year.

+

Revision 1 of this ZIP describes consensus rule changes related to funding of Zcash development via block subsidies, to be enacted at Network Upgrade 6 and lasting for 1 year.

Applicability

This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other block chains using Zcash technology.

@@ -467,7 +467,7 @@

Rationale for Revision 0

14 - ZIP 1015: Block Reward Allocation for Non-Direct Development Funding + ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding diff --git a/rendered/zip-0230.html b/rendered/zip-0230.html index 6f12ff6a4..53ec3ae06 100644 --- a/rendered/zip-0230.html +++ b/rendered/zip-0230.html @@ -36,18 +36,18 @@

Abstract

This proposal defines a new Zcash peer-to-peer transaction format, which includes data that supports the Orchard-ZSA protocol and all operations related to Zcash Shielded Assets (ZSAs). The new format adds and describes new fields containing ZSA-specific elements. Like the existing v5 transaction format, it keeps well-bounded regions of the serialized form to serve each pool of funds.

This ZIP also depends upon and defines modifications to the computation of the values TxId Digest, Signature Digest, and Authorizing Data Commitment defined by ZIP 244 9.

-

This ZIP additionally defines the fee mechanism associated with the Orchard Zcash Shielded Assets (OrchardZSA) protocol as described in ZIP 226 7 and ZIP 227 8. The fee mechanism is defined in terms of modifications to the Proportionak Transfer Fee Mechanism 10.

+

This ZIP additionally defines the fee mechanism associated with the Orchard Zcash Shielded Assets (OrchardZSA) protocol as described in ZIP 226 7 and ZIP 227 8. The fee mechanism is defined in terms of modifications to the Proportionak Transfer Fee Mechanism 11.

Motivation

The Orchard-ZSA protocol requires serialized data elements that are distinct from any previous Zcash transaction. Since ZIP 244 was activated in NU5, the v5 and later serialized transaction formats are not consensus-critical. Thus, this ZIP defines format that can easily accommodate future extensions, where elements or a given pool are kept separate.

-

The upgrade to the OrchardZSA protocol will also need to define a fee structure consistent with the objectives of ZIP 317 10. This involves adaptation for the transfer protocol 7, as well as additional considerations for the issuance protocol 8 such as fees for asset issuance. Specifically, the OrchardZSA Transfer and Burn mechanism should follow the same fee mechanism in order to not discriminate between transfer bundle types. When it comes to Issuance of ZSA, however, there should be a disincentive that will stop users from flooding the chain with useless asset identifiers. In the case of Issuance, the computational power needed to verify the bundle is not large. The transaction size, however, can be an issue as the number of output notes can be large. Furthermore, as defined in ZIP 227 8, there is an additional data structure in the global state that needs to be maintained as part of the consensus. This motivates further the addition of an Issuance-specific fee.

+

The upgrade to the OrchardZSA protocol will also need to define a fee structure consistent with the objectives of ZIP 317 11. This involves adaptation for the transfer protocol 7, as well as additional considerations for the issuance protocol 8 such as fees for asset issuance. Specifically, the OrchardZSA Transfer and Burn mechanism should follow the same fee mechanism in order to not discriminate between transfer bundle types. When it comes to Issuance of ZSA, however, there should be a disincentive that will stop users from flooding the chain with useless asset identifiers. In the case of Issuance, the computational power needed to verify the bundle is not large. The transaction size, however, can be an issue as the number of output notes can be large. Furthermore, as defined in ZIP 227 8, there is an additional data structure in the global state that needs to be maintained as part of the consensus. This motivates further the addition of an Issuance-specific fee.

Requirements

The new format must fully support the Orchard-ZSA protocol.

The new format should lend itself to future extension or pruning to add or remove value pools.

The computation of the non-malleable transaction identifier hash must include all newly incorporated elements except those that attest to transaction validity.

The computation of the commitment to authorizing data for a transaction must include all newly incorporated elements that attest to transaction validity.

-

In addition to the requirements of ZIP 317 10, the fee mechanism for the OrchardZSA protocol should satisfy the following requirements:

+

In addition to the requirements of ZIP 317 11, the fee mechanism for the OrchardZSA protocol should satisfy the following requirements:

OrchardZSA Fee Calculation

-

In addition to the parameters defined in the Fee calculation section of ZIP 317 11, the OrchardZSA protocol upgrade defines the following additional parameters:

+

In addition to the parameters defined in the Fee calculation section of ZIP 317 12, the OrchardZSA protocol upgrade defines the following additional parameters:

@@ -693,7 +693,7 @@
-

The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 6 and the global state. They are defined in the Fee calculation section of ZIP 317 11. Note that +

The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 6 and the global state. They are defined in the Fee calculation section of ZIP 317 12. Note that \(nOrchardActions\) , that is used in the computation of \(logical\_actions\) @@ -721,6 +721,9 @@

An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. In the context of transparent transactions, such a fee allows miners to “tap into” the ZSA value of the transactions, rather than the ZEC value of transactions. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it.

+

Deployment

+

Version 6 transactions are proposed to be allowed on the network starting from Network Upgrade 7. 10

+

Reference implementation

TODO

@@ -797,10 +800,18 @@ - +
+ + + +
10ZIP 254: Deployment of the NU7 Network Upgrade
+ + + + @@ -808,7 +819,7 @@
11 ZIP 317: Proportional Transfer Fee Mechanism
- + diff --git a/rendered/zip-0231.html b/rendered/zip-0231.html index c0607bf03..1fc75b6b6 100644 --- a/rendered/zip-0231.html +++ b/rendered/zip-0231.html @@ -25,9 +25,15 @@

Terminology

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. The term “network upgrade” in this document is to be interpreted as +described in ZIP 200. 2

+

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

+

The terms “Mainnet” and “Testnet” are to be interpreted as described +in § 3.12 ‘Mainnet and Testnet’. 4

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 @@ -35,8 +41,8 @@

Abstract

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 +note plaintext, and a corresponding 512-byte memo field. 5 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.

@@ -54,8 +60,8 @@

Motivation

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 +protocol 6, 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 @@ -107,158 +113,6 @@

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

- -

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

-
1112 ZIP 317: Proportional Transfer Fee Mechanism, Fee calculation
------- - - - - - - - - - -
8-bit leadByte88-bit d64-bit v256-bit rseed32-byte 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:

- -

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

- -

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:

-

Memo bundle

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

Memo encryption

class="math inline">0xE0 should be added to the documentation of inputs to PRFexpand in § 4.1.2 ‘Pseudo -Random Functions’ 11.

+Random Functions’ 7.

If the generated key is 32 0xFF bytes, the transaction constructor MAY repeat this procedure with a @@ -305,15 +159,15 @@

Memo encryption

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 -12 as follows:

+8 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 13.

+class="math inline">nonce = I2BEOSP88(counter) || [final_chunk] .

+

This is a variant of the STREAM construction 9.

Note: These definitions intentionally ignore the key; @@ -90,14 +87,14 @@

[Pre-NU7] let \(\mathsf{Sym}\) be - \(\mathsf{NoteSym}\) + \(\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}\) + \(\mathsf{NullSym}\!\) , otherwise let it be - \(\mathsf{NoteSym}\) + \(\mathsf{NoteSym}\!\) .

These changes apply identically to Mainnet and Testnet.

@@ -105,7 +102,7 @@

Deployment

-

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

+

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

Reference implementation

TBD.

@@ -162,6 +159,14 @@ + + + + + + + +
7ZIP 230: Version 6 Transaction Format
diff --git a/rendered/zip-guide-markdown.html b/rendered/zip-guide-markdown.html index 19abb4347..bd3f10743 100644 --- a/rendered/zip-guide-markdown.html +++ b/rendered/zip-guide-markdown.html @@ -212,42 +212,38 @@

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↩︎

    5. -

  5. Zcash Protocol Specification, -Version 2022.3.8. Section 1: Introduction↩︎

    6. -

  6. Zcash Protocol Specification, -Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎

    7. -

  7. ZIP 0: ZIP -Process

    Zcash Protocol +Specification, Version 2022.3.8. Section 3.12: Mainnet and Testnet↩︎

    8. +

  8. Zcash +Protocol Specification, Version 2022.3.8. Section 3.3: The Block +Chain↩︎

    9. -

  9. KaTeX - -The fastest math typesetting library for the web

    Zcash Protocol +Specification, Version 2022.3.8 or later↩︎

    10. +

  10. 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.` .. [#zip-0253] `ZIP 253: Deployment of the NU6 Network Upgrade ` .. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants ` -.. [#zip-1015] `ZIP 1015: Block Reward Allocation for Non-Direct Development Funding ` +.. [#zip-1015] `ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding ` .. [#zip-2001] `ZIP 2001: Lockbox Funding Streams ` diff --git a/zips/zip-0213.rst b/zips/zip-0213.rst index 5914317a9..5a522430e 100644 --- a/zips/zip-0213.rst +++ b/zips/zip-0213.rst @@ -38,7 +38,7 @@ Motivation Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions inside each block that are allowed to have no inputs. These transactions are created by -miners during block creation, and collect the block reward and transaction fees into new +miners during block creation, and collect the block subsidy and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the Founders' Reward (and potentially for funding streams [#zip-0207]_). diff --git a/zips/zip-0214.rst b/zips/zip-0214.rst index e9e47979f..974bdd7d9 100644 --- a/zips/zip-0214.rst +++ b/zips/zip-0214.rst @@ -61,8 +61,8 @@ proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years. `Revision 1`_ of this ZIP describes consensus rule changes related to funding -of Zcash development via block rewards, to be enacted at Network Upgrade 6 and -lasting for 1 year. +of Zcash development via block subsidies, to be enacted at Network Upgrade 6 +and lasting for 1 year. Applicability @@ -413,4 +413,4 @@ References .. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade `_ .. [#zip-0253] `ZIP 253: Deployment of the NU6 Network Upgrade `_ .. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants `_ -.. [#zip-1015] `ZIP 1015: Block Reward Allocation for Non-Direct Development Funding `_ +.. [#zip-1015] `ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding `_ diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst index 90199da29..eef1b6d00 100644 --- a/zips/zip-0230.rst +++ b/zips/zip-0230.rst @@ -457,6 +457,13 @@ In the context of transparent transactions, such a fee allows miners to “tap i However when transactions are shielded, any design that lifts value from the transaction would also leak information about it. +Deployment +========== + +Version 6 transactions are proposed to be allowed on the network starting from +Network Upgrade 7. [#zip-0254]_ + + Reference implementation ======================== @@ -475,5 +482,6 @@ References .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets `_ .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ +.. [#zip-0254] `ZIP 254: Deployment of the NU7 Network Upgrade `_ .. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism `_ .. [#zip-0317-fee-calc] `ZIP 317: Proportional Transfer Fee Mechanism, Fee calculation `_ diff --git a/zips/zip-0231.md b/zips/zip-0231.md index 924a8fc99..3d1c96231 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -19,9 +19,15 @@ The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 [^BCP14] 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. [^zip-0200] + The character § is used when referring to sections of the Zcash Protocol Specification. [^protocol] +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [^protocol-networks] + # Abstract @@ -80,8 +86,8 @@ while decreasing the amount of data that needs to be stored on-chain overall. - 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. + 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 @@ -106,101 +112,6 @@ 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 $\mathbf{np}$) consists of - > - > $\hspace{2em}(\mathsf{leadByte} ⦂ \mathbb{B^{Y}}, \mathsf{d} ⦂ \mathbb{B^{[\ell_{\mathsf{d}}]}}, \mathsf{rseed} ⦂ \mathbb{B^{Y[32]}}, \mathsf{memo} ⦂ \mathbb{B^{Y[512]}})$ - - 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 $\mathbf{np}$) consists of - > - > $\hspace{2em}(\mathsf{leadByte} ⦂ \mathbb{B^{Y}}, \mathsf{d} ⦂ \mathbb{B^{[\ell_{\mathsf{d}}]}}, \mathsf{rseed} ⦂ \mathbb{B^{Y[32]}}, \mathsf{memo} ⦂ \mathbb{B^{Y[512]}})$ - > - > Each v6-onward Sapling or Orchard note plaintext (denoted $\mathbf{np}$) consists of - > - > $\hspace{2em}(\mathsf{leadByte} ⦂ \mathbb{B^{Y}}, \mathsf{d} ⦂ \mathbb{B^{[\ell_{\mathsf{d}}]}}, \mathsf{rseed} ⦂ \mathbb{B^{Y[32]}}, \mathsf{K^{memo}} ⦂ \mathbb{B^{Y[32]}})$ - -In § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ [^protocol-noteptencoding]: - -* 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 $\mathsf{leadByte}$ | 88-bit $\mathsf{d}$ | 64-bit $\mathsf{v}$ | 256-bit $\mathsf{rseed}$ | 32-byte $\mathsf{K^{memo}}$ | - > - > * A byte 0x03, indicating this version of the encoding of a v6-onward - > Sapling or Orchard note plaintext. - > * 11 bytes specifying $\mathsf{d}$. - > * 8 bytes specifying $\mathsf{v}$. - > * 32 bytes specifying $\mathsf{rseed}$. - > * 32 bytes specifying $\mathsf{K^{memo}}$. - > - > A value consisting of 32 $\mathtt{0xFF}$ bytes for $\mathsf{K^{memo}}$ is used - > to indicate that there is no memo for this note plaintext. - -In § 4.7.2 ‘Sending Notes (Sapling)’ [^protocol-saplingsend] and -§ 4.7.3 ‘Sending Notes (Orchard)’ [^protocol-orchardsend]: - -* Add a reference to this ZIP specifying the construction of the memo bundle and - derivation of $\mathsf{K^{memo}}$ in the case of a v6-onward note plaintext. - -* Change - - > Let $\mathbf{np} = (\mathsf{leadByte}, \mathsf{d}, \mathsf{v}, \mathsf{rseed}, \mathsf{memo})\!$. - - to - - > Let $\mathbf{np}$ be the encoding of a Sapling note plaintext using $\mathsf{leadByte}$, $\mathsf{d}$, - > $\mathsf{v}$, $\mathsf{rseed}$, and either $\mathsf{memo}$ for a pre-v6 note plaintext or - > $\mathsf{K^{memo}}$ 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)’ [^protocol-saplingandorchardinband]: - -* Change - - > Let $\mathbf{np} = (\mathsf{leadByte}, \mathsf{d}, \mathsf{v}, \mathsf{rseed}, \mathsf{memo})$ - > be the Sapling or Orchard note plaintext. $\mathbf{np}$ is encoded as defined - > in § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’. - - to - - > Let $\mathbf{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: - - > * $\mathsf{C^{enc}}$ will be of length either 580 or 100 bytes, depending on whether - > $\mathbf{np}$ is a pre-v6 or v6-onward note plaintext. - -In § 4.20.2 ‘Decryption using an Incoming Viewing Key (Sapling and Orchard)’ [^protocol-decryptivk] -and § 4.20.3 ‘Decryption using a Full Viewing Key (Sapling and Orchard)’ [^protocol-decryptovk]: - -* Replace $\mathsf{memo} ⦂ \mathbb{B^{Y[512]}}$ with $\mathsf{memoOrKey}$. -* Specify that the type of $\mathsf{memoOrKey}$ is $\mathbb{B^{Y[512]}}$ when - decrypting a pre-v6 note ciphertext, or $\mathbb{B^{Y[32]}}$ when decrypting a - v6-onward note ciphertext. In the latter case, it is used as $\mathsf{K^{memo}}$ - 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 @@ -248,12 +159,12 @@ as follows: $\hspace{2em}\mathsf{IETF\_AEAD\_CHACHA20\_POLY1305}(\mathsf{encryption\_key}, \mathsf{nonce}, \mathsf{memo\_chunk})$ -where $\mathsf{nonce} = \mathsf{I2BEOSP}_{88}(\mathsf{counter}) || [\mathsf{final\_chunk}]\!$. +where $\mathsf{nonce} = \mathsf{I2BEOSP}_{88}(\mathsf{counter}) \,||\, [\mathsf{final\_chunk}]\!$. This is a variant of the STREAM construction [^stream]. -- $\mathsf{counter}$ is a big-endian chunk counter starting at zero and incrementing by - one for each subsequent chunk within a particular memo. +- $\mathsf{counter}$ is a big-endian chunk counter starting at zero and incrementing + by one for each subsequent chunk within a particular memo. - $\mathsf{final\_chunk}$ is the byte $\mathtt{0x01}$ for the final memo chunk, and $\mathtt{0x00}$ for all preceding chunks. @@ -350,6 +261,105 @@ in ZIP 317 [^zip-0317]. Nodes must reject `GetData` responses having an `fAllPruned` value that is nonzero, or any byte of `pruned` that is nonzero. +## 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 $\mathbf{np}$) consists of + > + > $\hspace{2em}(\mathsf{leadByte} ⦂ \mathbb{B^{Y}}, \mathsf{d} ⦂ \mathbb{B^{[\ell_{\mathsf{d}}]}}, \mathsf{rseed} ⦂ \mathbb{B^{Y[32]}}, \mathsf{memo} ⦂ \mathbb{B^{Y[512]}})$ + + 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 $\mathbf{np}$) consists of + > + > $\hspace{2em}(\mathsf{leadByte} ⦂ \mathbb{B^{Y}}, \mathsf{d} ⦂ \mathbb{B^{[\ell_{\mathsf{d}}]}}, \mathsf{rseed} ⦂ \mathbb{B^{Y[32]}}, \mathsf{memo} ⦂ \mathbb{B^{Y[512]}})$ + > + > Each v6-onward Sapling or Orchard note plaintext (denoted $\mathbf{np}$) consists of + > + > $\hspace{2em}(\mathsf{leadByte} ⦂ \mathbb{B^{Y}}, \mathsf{d} ⦂ \mathbb{B^{[\ell_{\mathsf{d}}]}}, \mathsf{rseed} ⦂ \mathbb{B^{Y[32]}}, \mathsf{K^{memo}} ⦂ \mathbb{B^{Y[32]}})$ + +In § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ [^protocol-noteptencoding]: + +* 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 $\mathsf{leadByte}$ | 88-bit $\mathsf{d}$ | 64-bit $\mathsf{v}$ | 256-bit $\mathsf{rseed}$ | 32-byte $\mathsf{K^{memo}}$ | + > + > * A byte 0x03, indicating this version of the encoding of a v6-onward + > Sapling or Orchard note plaintext. + > * 11 bytes specifying $\mathsf{d}$. + > * 8 bytes specifying $\mathsf{v}$. + > * 32 bytes specifying $\mathsf{rseed}$. + > * 32 bytes specifying $\mathsf{K^{memo}}$. + > + > A value consisting of 32 $\mathtt{0xFF}$ bytes for $\mathsf{K^{memo}}$ is used + > to indicate that there is no memo for this note plaintext. + +In § 4.7.2 ‘Sending Notes (Sapling)’ [^protocol-saplingsend] and +§ 4.7.3 ‘Sending Notes (Orchard)’ [^protocol-orchardsend]: + +* Add a reference to this ZIP specifying the construction of the memo bundle and + derivation of $\mathsf{K^{memo}}$ in the case of a v6-onward note plaintext. + +* Change + + > Let $\mathbf{np} = (\mathsf{leadByte}, \mathsf{d}, \mathsf{v}, \mathsf{rseed}, \mathsf{memo})\!$. + + to + + > Let $\mathbf{np}$ be the encoding of a Sapling note plaintext using $\mathsf{leadByte}$, $\mathsf{d}$, + > $\mathsf{v}$, $\mathsf{rseed}$, and either $\mathsf{memo}$ for a pre-v6 note plaintext or + > $\mathsf{K^{memo}}$ 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)’ [^protocol-saplingandorchardinband]: + +* Change + + > Let $\mathbf{np} = (\mathsf{leadByte}, \mathsf{d}, \mathsf{v}, \mathsf{rseed}, \mathsf{memo})$ + > be the Sapling or Orchard note plaintext. $\mathbf{np}$ is encoded as defined + > in § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’. + + to + + > Let $\mathbf{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: + + > * $\mathsf{C^{enc}}$ will be of length either 580 or 100 bytes, depending on whether + > $\mathbf{np}$ is a pre-v6 or v6-onward note plaintext. + +In § 4.20.2 ‘Decryption using an Incoming Viewing Key (Sapling and Orchard)’ [^protocol-decryptivk] +and § 4.20.3 ‘Decryption using a Full Viewing Key (Sapling and Orchard)’ [^protocol-decryptovk]: + +* Replace $\mathsf{memo} ⦂ \mathbb{B^{Y[512]}}$ with $\mathsf{memoOrKey}$. +* Specify that the type of $\mathsf{memoOrKey}$ is $\mathbb{B^{Y[512]}}$ when + decrypting a pre-v6 note ciphertext, or $\mathbb{B^{Y[32]}}$ when decrypting a + v6-onward note ciphertext. In the latter case, it is used as $\mathsf{K^{memo}}$ + to decrypt the memo bundle as described in [Memo bundle]. + +## Applicability + +All of these changes apply identically to Mainnet and Testnet. + # Open issues @@ -358,6 +368,10 @@ or any byte of `pruned` that is nonzero. `memo_chunk_limit == 64` is recommended. This results in a maximum of 16 KiB of memo data per transaction. +## Interaction with ZIP 302 [^zip-0302] + +TBD + # Rationale @@ -486,6 +500,11 @@ Combined with the memo bundle size restriction, the maximum additional fee for a memo bundle over prior transactions is 0.0019 ZEC. +# Deployment + +This ZIP is proposed to activate with Network Upgrade 7. [^zip-0254] + + # Reference implementation TBD @@ -499,6 +518,8 @@ TBD [^protocol-noteptconcept]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2.1: Note Plaintexts and Memo Fields](protocol/protocol.pdf#noteptconcept) +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + [^protocol-abstractprfs]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.2: Pseudo Random Functions](protocol/protocol.pdf#abstractprfs) [^protocol-saplingsend]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.7.2: Sending Notes (Sapling)](protocol/protocol.pdf#saplingsend) @@ -515,7 +536,9 @@ TBD [^protocol-inbandrationale]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 8.7: In-band secret distribution](protocol/protocol.pdf#inbandrationale) -[^stream]: [Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance](https://eprint.iacr.org/2015/189) +[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) + +[^zip-0254]: [ZIP 254: Deployment of the NU7 Network Upgrade](zip-0254.rst) [^zip-0302]: [ZIP 302: Standardized Memo Field Format](zip-0302.rst) @@ -523,6 +546,8 @@ TBD [^zip-0317]: [ZIP 317: Proportional Transfer Fee Mechanism](zip-0317.rst) +[^stream]: [Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance](https://eprint.iacr.org/2015/189) + [^pczt]: [zcash/zips issue #693: Standardize a protocol for creating shielded transactions offline](https://github.com/zcash/zips/issues/693) [^rfc-8439]: [RFC 8439: ChaCha20 and Poly1305 for IETF Protocols](https://www.rfc-editor.org/rfc/rfc8439.html) diff --git a/zips/zip-0233.md b/zips/zip-0233.md index eaeea1aba..cb14919c2 100644 --- a/zips/zip-0233.md +++ b/zips/zip-0233.md @@ -15,35 +15,49 @@ License: BSD-2-Clause Discussions-To: ``` + # 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 key word "MUST" in this document is to be interpreted as described in +BCP 14 [^BCP14] 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. [^zip-0200] + +The character § is used when referring to sections of the Zcash Protocol +Specification. [^protocol] + +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [^protocol-networks] + +"ZEC/TAZ" refers to the native currency of Zcash on a given network, i.e. +ZEC on Mainnet and TAZ on Testnet. -The term "network upgrade" in this document is to be interpreted as described in -ZIP 200. [2] +"Block Subsidy" - The algorithmic issuance of ZEC/TAZ on block creation, as +defined by consensus. This is split between the miner and Funding Streams. -"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/TAZ becomes available for circulation +on the network. [TODO: there is a potential terminology conflict between +this and issuance as defined in ZIP 227.] -"Issuance" - The method by which ZEC becomes available for circulation on the -network. +"Burning" - The method by which ZEC/TAZ becomes unavailable for circulation +on the network. -"We" - the ZIP Owners and Authors, listed in the above front matter. +$\mathsf{MAX\_MONEY}$, as defined in § 5.3 ‘Constants’ [^protocol-constants], +is the total ZEC/TAZ supply cap measured in zatoshi, corresponding to +21,000,000 ZEC. This is slightly larger than the supply cap for the current +issuance mechanism, but is the value used in existing critical consensus +checks. -"`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 -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”. +This ZIP proposes the introduction of a mechanism to voluntarily burn funds, +removing those funds entirely from circulation on the network. This mechanism, +in combination with ZIP 234 [^zip-0234] and ZIP 235 [^zip-0235], 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 @@ -52,69 +66,78 @@ design shared by Bitcoin-like systems: 1. **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. + $\mathsf{MAX\_MONEY}$. This lays necessary groundwork for extending the + block subsidy system, which currently has a clear final end date. 2. **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. + # Specification -The modifications required are: - -1. The addition of a transaction field representing an amount to burn for a - given transaction. -2. The inclusion of the burn amount in the calculated total output value for a - given transaction. -3. Consensus rules to ensure the burned amount is no longer available for - circulation on the network. - -## Transaction Format - -The following field is added to the v6 transaction format [3]: - -+-------+----------------+------------+------------------------------------------------------+ -| Bytes | Name | Data Type | Description | -+=======+================+============+======================================================+ -| 8 | ``burnAmount`` | ``uint64`` | The 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. - -## 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 -> ``` +## Burn amount + +Each transaction gains a $\mathsf{burn\_amount}$ property, specifying the +value in zatoshis that is burned when the transaction is mined. The burned value +subtracts from the remaining value in the "transparent transaction value pool" +as described in § 3.4 ‘Transactions and Treestates’ [^protocol-transactions]. + +$\mathsf{burn\_amount}$ does not result in an output being produced in any +chain value pool, and therefore from the point at which the transaction is +applied to the global chain state, $\mathsf{burn\_amount}$ is subtracted from the +issued supply. It is unavailable for circulation on the network at least through +to the end of the block in which the transaction is mined. ZIP 234 [^zip-0234] +specifies a potential mechanism by which the burned funds would again become +available. + +## Changes to ZIP 230 [^zip-0230] + +The following field is appended to the Common Transaction Fields of the v6 +transaction format after `nExpiryHeight` [^zip-0230-transaction-format]: + +| Bytes | Name | Data Type | Description | +|-------|--------------|-----------|----------------------------------------------------------| +| 8 | `burnAmount` | `uint64` | The value to be burned in this transaction, in zatoshis. | + +The $\mathsf{burn\_amount}$ of a transaction is defined to be the value of the +`burnAmount` field if present, and otherwise 0. + +Notes: + +* If both this ZIP and ZIP 2002 are selected for inclusion in the same Network + Upgrade, then the ambiguity in ordering of the fields added by these ZIPs + would need to be resolved. +* Older transaction versions can continue to be supported after a network upgrade, + but burning is not possible for these transactions. For example, NU5 supports + both v4 and v5 transaction formats, for both coinbase and non-coinbase transactions. + +## Changes to the Zcash Protocol Specification + +Make a change to § 3.4 ‘Transactions and Treestates’ [^protocol-transactions] +implementing the specification in [Burn amount]. + +In § 7.1 ‘Transaction Encoding and Consensus’ [^protocol-txnconsensus], add: + +> [NU7 onward] $\mathsf{burn\_amount}$ MUST be in the range $\{ 0 .. \mathsf{MAX\_MONEY} \}$. + +## Modifications relative to ZIP 244 [^zip-0244] + +Relative to the sighash algorithm defined in ZIP 244, the sighash algorithm +that applies to v6 transactions differs by appending the encoding of +$\mathsf{burn\_amount}$ to the Common Transaction Fields that are the input +to the digest in T.1: `header_digest` [^zip-0244-t-1-header-digest]: + +> T.1f: burn_amount (8-byte little-endian burn amount) + +Note: If both this ZIP and ZIP 2002 are selected for inclusion in the same +Network Upgrade, then the ambiguity in ordering of the fields added by these +ZIPs would need to be resolved. + +## Applicability + +All of these changes apply identically to Mainnet and Testnet. + # Rationale @@ -127,22 +150,38 @@ 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 7. +This ZIP is proposed to activate with Network Upgrade 7. [^zip-0254] + # References -**[1]: [Key words for use in RFCs to Indicate Requirement -Levels](https://www.rfc-editor.org/rfc/rfc2119.html)** +[^BCP14]: [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"](https://www.rfc-editor.org/info/bcp14) + +[^protocol]: [Zcash Protocol Specification, Version 2024.5.1 [NU6] or later](protocol/protocol.pdf) + +[^protocol-transactions]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.4: Transactions And Treestates](protocol/protocol.pdf#transactions) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^protocol-constants]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants](protocol/protocol.pdf#constants) + +[^protocol-txnconsensus]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1.2 Transaction Consensus Rules](protocol/protocol.pdf#txnconsensus) + +[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) + +[^zip-0230]: [ZIP 230: Version 6 Transaction Format](zip-0230.rst) + +[^zip-0230-transaction-format]: [ZIP 230: Version 6 Transaction Format. Section 'Transaction Format'](zip-0230#transaction-format) -**[2]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst)** +[^zip-0234]: [ZIP 234: Network Sustainability Mechanism: Issuance Smoothing](zip-0234.rst) -**[3]: [ZIP 230: Version 6 Transaction Format](zip-0230.rst)** +[^zip-0235]: [ZIP 235: Burn 60% of Transaction Fees](zip-0235.rst) -**[4]: [ZIP 244: Transaction Identifier Non-Malleability](zip-0244.rst)** +[^zip-0244]: [ZIP 244: Transaction Identifier Non-Malleability](zip-0244.rst) -**[5]: [ZIP 244: Transaction Identifier Non-Malleability. Section T.1: Header -Digest](zip-0244.rst#t-1-header-digest)** +[^zip-0244-t-1-header-digest]: [ZIP 244: Transaction Identifier Non-Malleability. Section T.1: header_digest](zip-0244.rst#t-1-header-digest) -**[6]: [Draft Tx v6 Sighash](zips/draft-txv6-sighash)** +[^zip-0254]: [ZIP 254: Deployment of the NU7 Network Upgrade](zip-0254.rst) diff --git a/zips/zip-0234.md b/zips/zip-0234.md index f8db92969..56bc883f7 100644 --- a/zips/zip-0234.md +++ b/zips/zip-0234.md @@ -12,27 +12,50 @@ Status: Draft Category: Consensus Created: 2023-08-23 License: BSD-2-Clause +Discussions-To: ``` + # 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 key word "MUST" in this document is to be interpreted as described in +BCP 14 [^BCP14] 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. [^zip-0200] + +The character § is used when referring to sections of the Zcash Protocol +Specification. [^protocol] + +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [^protocol-networks] + +The symbol "$\,\cdot\,$" means multiplication, as described in § 2 ‘Notation’. +[^protocol-notation] + +"ZEC/TAZ" refers to the native currency of Zcash on a given network, i.e. +ZEC on Mainnet and TAZ on Testnet. + +The terms "Block Subsidy", "Issuance", and "Burning" are to be interpreted +as described in ZIP 233. [^zip-0233] -"Network upgrade" - to be interpreted as described in ZIP 200. [2] +Let $\mathsf{PostBlossomHalvingInterval}$ be as defined in [^protocol-diffadjustment]. -"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. +$\mathsf{MAX\_MONEY}$, as defined in § 5.3 ‘Constants’ [^protocol-constants], +is the total ZEC/TAZ supply cap measured in zatoshi, corresponding to +21,000,000 ZEC. This is slightly larger than the supply cap for the current +issuance mechanism, but is the value used in existing critical consensus +checks. -"Issuance" - The method by which ZEC becomes available for circulation on the -network. +"Issued Supply" - The Issued Supply at a given height of a block chain is +the total ZEC/TAZ value in all chain value pool balances at that height, as +calculated by $\mathsf{IssuedSupply}(\mathsf{height})$ defined in +§ 4.17 ‘Chain Value Pool Balances’. [^protocol-chainvaluepoolbalances] -Let `PostBlossomHalvingInterval` be as defined in [#protocol-diffadjustment]_. +"Money Reserve" - The Money Reserve at a given height of a block chain is +the total ZEC/TAZ value remaining to be issued, as calculated by +$\mathsf{MAX\_MONEY} - \mathsf{IssuedSupply}(\mathsf{height})\!$. -"Money Reserve" - `MAX_MONEY - ChainValue`, where `ChainValue` includes all ZEC -available on the network, across all value pools. # Abstract @@ -43,8 +66,9 @@ 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`. +intervals, assuming no ZEC/TAZ is burned during that time, and retains the +overall supply cap of `MAX_MONEY`. + # Motivation @@ -71,7 +95,7 @@ Furthermore, the halvings schedule is fixed and does not provide any way to 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 +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. @@ -81,87 +105,96 @@ future block subsidies. Smoothing the issuance curve is possible using an exponential decay formula that satisfies the following requirements: -1. The issuance can be summarized into a reasonably simple explanation -2. Block subsidies approximate a continuous function +1. The issuance can be summarized into a reasonably simple explanation. +2. Block subsidies approximate a continuous function. 3. If the Money Reserve is greater than 0, then the block subsidy must be - non-zero, preventing any final "unmined" zatoshis -4. For any 4 year period, all paid out block subsidies are approximately equal - to half of the Money Reserve at the beginning of that 4 year period, if no - ZEC is burned during those 4 years -5. Decrease the short-term impact of the deployment of this ZIP on block reward + non-zero, preventing any final "unmined" zatoshis. +4. For any 4-year period, all paid out block subsidies are approximately equal + to half of the Money Reserve at the beginning of that 4-year period, if no + ZEC is burned during those 4 years. +5. Decrease the short-term impact of the deployment of this ZIP on block subsidy recipients, and minimize the potential reputation risk to Zcash of changing - the block reward amount. - -TODO daira: add a requirement that makes the initial total issuance match the previous total issuance + the block subsidy amount. +6. The immediate change in issuance when this mechanism activates should be + minimal. # Specification ## Parameters -`BLOCK_SUBSIDY_FRACTION` = 4126 / 10,000,000,000 or `0.0000004126` +$\mathtt{BLOCK\_SUBSIDY\_FRACTION} = 4126 / 10\_000\_000\_000 = 0.0000004126$ `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 +- It is calculated to be the lowest height after the second halving at which the NSM issuance would be less than the current BTC-style issuance - _neglecting_ any burnt ZEC (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. + _neglecting_ any burnt ZEC (i.e. assuming the amount of ZEC burnt is + exactly 0). + +This selection is intended to achieve Key Objective 6 while still being at +a constant, predictable height. An alternative would be to have a dynamic +"latch"-style activation, which would calculate the activation height by +testing the "less than" conditional with every block after the second halving. +We prefer the pre-defined constant height parameter, to give everyone more +_time_ certainty at the cost of _issuance level_ certainty. + +The difference in up-front calculation versus dynamic calculation is in +whether or not burns are accounted for (since future burns cannot be +calculated up-front). This means with the pre-defined constant parameter +approach, issuance will jump _up_ some amount at activation. This amount +should be equivalent to all ZEC burnt prior to that height times +$\mathtt{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\text{ ZEC} \cdot \mathtt{BLOCK\_SUBSIDY\_FRACTION}\!$, +which we calculate equals $0.04126$ ZEC. This example is chosen to +demonstrate that a very large burn amount (much larger than expected) would +elevate issuance by a relatively small amount. For this reason, we believe +a pre-defined constant is a better approach to achieving Key Objective 6 +than a "dynamic latch" logic because it is so much simpler to implement +and reason about. + +$\mathsf{MoneyReserveAfter}(\mathsf{height}) \;\,=$ The value of the Money Reserve +after the specified block height. ## Issuance Calculation At the `DEPLOYMENT_BLOCK_HEIGHT`, nodes should switch from the current issuance calculation, to the following: -`BlockSubsidy(block_height) = ceiling(BLOCK_SUBSIDY_FRACTION * MoneyReserveAfter(block_height - 1))` +$\mathsf{BlockSubsidy}(\mathsf{height}) = \mathsf{ceiling}(\mathtt{BLOCK\_SUBSIDY\_FRACTION} \cdot \mathsf{MoneyReserveAfter}(\mathsf{height} - 1))$ + +## Applicability + +All of these changes apply identically to Mainnet and Testnet. + # 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` +## BLOCK_SUBSIDY_FRACTION -Let `IntendedMoneyReserveFractionRemainingAfterFourYears` = 0.5. +Let $\mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears} = 0.5\!$. -The value `4126 / 10_000_000_000` satisfies the approximation within +0.002%: +The value $4126 / 10\_000\_000\_000$ satisfies the approximation within $\pm 0.002\%$: -`(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedMoneyReserveFractionRemainingAfterFourYears` +$(1 - \mathtt{BLOCK\_SUBSIDY\_FRACTION})^\mathsf{PostBlossomHalvingInterval} \approx \mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears}$ -Meaning after a period of 4 years around half of Money Reserve will be issued as -block subsidies, thus satisfying **Requirement 4**. +This implies that after a period of 4 years around half of Money Reserve will +have been issued as block subsidies, thus satisfying **Requirement 4**. -The largest possible value in the Money Reserve is `MAX_MONEY`, in the +The largest possible value in the Money Reserve is $\mathsf{MAX\_MONEY}$, in the theoretically possible case that all issued funds are burned. If this happened, -the largest interim sum in the block subsidy calculation would be `MAX_MONEY * -4126 / 10000000000`. +the largest interim sum in the block subsidy calculation would be +$\mathsf{MAX\_MONEY} \cdot 4126 / 10\_000\_000\_000\!$. -This uses 62.91 bits, which is just under the 63 bit limit for 64-bit signed -two's-complement integer amount types. +This uses 62.91 bits, which is just under the 63-bit limit for signed +two's complement 64-bit 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 @@ -181,10 +214,6 @@ is implemented. ![A graph showing the balance of the Money Reserve assuming smooth issuance is implemented](../rendered/assets/images/zip-0234-balance.png) -# Deployment - -The implementation of this ZIP MUST be deployed at the same time or after the -Network Sustainability Mechanism Burning function is deployed (ZIP-0233). # Appendix: Simulation @@ -212,15 +241,37 @@ Halving 1 at block 1680000: shows that the difference between the smoothed out and the current 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. + +# Deployment + +This ZIP is proposed to activate with Network Upgrade 7. [^zip-0254] +It MUST be deployed at the same time or after ZIP 233 ("NSM: Burning" [^zip-0233]). + + # References -[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119 +[^BCP14]: [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"](https://www.rfc-editor.org/info/bcp14) + +[^protocol]: [Zcash Protocol Specification, Version 2024.5.1 [NU6] or later](protocol/protocol.pdf) + +[^protocol-notation]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 2: Notation](protocol/protocol.pdf#notation) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^protocol-chainvaluepoolbalances]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.17 Chain Value Pool Balances](protocol/protocol.pdf#chainvaluepoolbalances) + +[^protocol-constants]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants](protocol/protocol.pdf#constants) + +[^protocol-diffadjustment]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.7.3 Difficulty Adjustment](protocol/protocol.pdf#diffadjustment) + +[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) -[2] [ZIP-200: Network Upgrade Mechanism](zip-0200.rst) +[^zip-0233]: [ZIP 233: Network Sustainability Mechanism: Burning](zip-0233.md) -[3] [ZIP_233: Network Sustainability Mechanism: Burning](zip-0233.md) +[^zip-0254]: [ZIP 254: Deployment of the NU7 Network Upgrade](zip-0254.rst) diff --git a/zips/zip-0235.md b/zips/zip-0235.md index 026a77679..20de9bd7e 100644 --- a/zips/zip-0235.md +++ b/zips/zip-0235.md @@ -15,35 +15,43 @@ License: BSD-2-Clause Discussions-To: ``` + # 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 key word "MUST" in this document is to be interpreted as described in +BCP 14 [^BCP14] 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. [^zip-0200] + +The character § is used when referring to sections of the Zcash Protocol +Specification. [^protocol] -The term “network upgrade” in this document is to be interpreted as described in -ZIP 200. [2] +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [^protocol-networks] -"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. +The symbol "$\,\cdot\,$" means multiplication, as described in § 2 ‘Notation’. +[^protocol-notation] -"Issuance" - The method by which ZEC becomes available for circulation on the -network. +"ZEC/TAZ" refers to the native currency of Zcash on a given network, i.e. +ZEC on Mainnet and TAZ on Testnet. + +The terms "Block Subsidy", "Issuance", and "Burning" are to be interpreted +as described in ZIP 233. [^zip-0233] -“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. +This ZIP proposes to burn 60% of transaction fees, while the remaining 40% is +directed as before, providing a deflationary effect, and building the groundwork +for long-term support of the Zcash network via the new block subsidy rules +proposed by ZIP 234 [^zip-0234]. + # Motivation -ZIP-233 ("Network Sustainability Mechanism: Burning") describes a method by -which ZEC can be burned to support network sustainability. +ZIP 233 ("Network Sustainability Mechanism: Burning" [^zip-0233]) 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 @@ -52,10 +60,10 @@ 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. + supply of ZEC, similar to asset burning in Ethereum’s EIP-1559 [^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. **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 @@ -75,28 +83,30 @@ to the long-term sustainability of the network as described below: instrumental in addressing unforeseen issues and seizing strategic advantages as the Zcash ecosystem evolves. + # Requirements * For each block, at least 60% (rounded down) of the total fees are to be -burned. + burned. * No restrictions are placed on the destination of the remaining proportion of -fees. + 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)`. +For a given block, the coinbase transaction MUST have a $\mathsf{burn\_amount}$, +as defined in [^zip-0233], that is greater than or equal to +$\mathsf{floor}(\mathsf{transactionFees} \cdot 6 / 10)\!$. -Previous transaction versions are not supported for coinbase transactions, due -to there being no explicit mechanism to burn the required funds. +The version of a coinbase transaction MUST be v6 or later [^zip-0230]. -# Deployment +## Applicability + +All of these changes apply identically to Mainnet and Testnet. -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 @@ -105,18 +115,29 @@ implementation and protocol changes. Additionally, transaction fees are currently small enough that the reduction in miner fees is unlikely to be a concern. +## Rationale for requiring the coinbase transaction to be v6 or later + +There is no explicit mechanism in prior transaction versions to burn the +required funds. Since $\mathsf{burn\_amount} = 0$ for transaction versions +prior to v6, absent the rule about the coinbase transaction version it +would be technically possible to satisfy the constraint on $\mathsf{burn\_amount}$ +with earlier versions than v6, but only when $\mathsf{transactionFees} = 0$. +That would introduce a corner case in the transaction consensus rules that +is not useful, since it is expected that the $\mathsf{transactionFees}$ +will normally be non-zero. + ## 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]). +transactions have an average of 5.46 logical actions (see ZIP 317 [^zip-0317]). -The total fees paid to miners from those transactions, assuming the ZIP-317 +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] +If 60% of these fees burned, that would be 210.864 ZEC per year. [^zsf-fee-estimator] ## Considerations for the Future @@ -139,14 +160,32 @@ sustainability, including but not limited to: - Cross-chain bridge usage / Cross-chain messaging - Note sorting micro-transactional fees + +# Deployment + +The implementation of this ZIP MUST be deployed at the same time or after +ZIP 233 ("NSM: Burning" [^zip-0233]), and ZIP 234 ("NSM: Issuance Smoothing" +[^zip-0234]). + + # References -[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119 +[^BCP14]: [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"](https://www.rfc-editor.org/info/bcp14) + +[^protocol]: [Zcash Protocol Specification, Version 2024.5.1 [NU6] or later](protocol/protocol.pdf) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) + +[^zip-0230]: [ZIP 230: Version 6 Transaction Format](zip-0230.rst) + +[^zip-0233]: [ZIP 233: Network Sustainability Mechanism: Burning](zip-0233.rst) -[2] ZIP 200: [Network Upgrade Mechanism](zip-0200.rst) +[^zip-0234]: [ZIP 234: Network Sustainability Mechanism: Issuance Smoothing](zip-0234.rst) -[3] ZIP 233: [Establish the Zcash Sustainability Fund on the Protocol Level](zip-0233.md) +[^zip-0317]: [ZIP 317: Proportional Transfer Fee Mechanism](zip-0317.rst) -[4] ZIP 317: [Proportional Transfer Fee Mechanism](zip-0317.rst) +[^zsf-fee-estimator]: [GitHub repository eigerco/zsf-fee-estimator](https://github.com/eigerco/zsf-fee-estimator) -[5] https://github.com/eigerco/zsf-fee-estimator +[^eip-1559]: [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) diff --git a/zips/zip-0254.md b/zips/zip-0254.md index 723339e1a..783cf7857 100644 --- a/zips/zip-0254.md +++ b/zips/zip-0254.md @@ -8,20 +8,27 @@ License: MIT Discussions-To: + # Terminology -The key word "MUST" in this document are to be interpreted as described in -BCP 14 [^BCP14] when, and only when, they appear in all capitals. +The key word "MUST" in this document is to be interpreted as described in +BCP 14 [^BCP14] 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. [^zip-0200] + +The character § is used when referring to sections of the Zcash Protocol +Specification. [^protocol] -The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [^zip-0200]. +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [^protocol-networks] -The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.12 of the Zcash Protocol Specification [^protocol-networks]. # Abstract This proposal defines the deployment of the NU7 network upgrade. + # Specification ## NU7 deployment @@ -31,9 +38,11 @@ The primary sources of information about NU7 consensus protocol changes are: * The Zcash Protocol Specification [^protocol]. * ZIP 200: Network Upgrade Mechanism [^zip-0200]. -The network handshake and peer management mechanisms defined in ZIP 201 [^zip-0201] also apply to this upgrade. +The network handshake and peer management mechanisms defined in ZIP 201 +[^zip-0201] also apply to this upgrade. -The following network upgrade constants [^zip-0200] are defined for the NU7 upgrade: +The following network upgrade constants [^zip-0200] are defined for the +NU7 upgrade: CONSENSUS_BRANCH_ID : `0x77190AD8` @@ -46,13 +55,21 @@ 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. +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 -# 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. -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. -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 diff --git a/zips/zip-1015.rst b/zips/zip-1015.rst index 059441908..b94dc5830 100644 --- a/zips/zip-1015.rst +++ b/zips/zip-1015.rst @@ -1,7 +1,7 @@ :: ZIP: 1015 - Title: Block Reward Allocation for Non-Direct Development Funding + Title: Block Subsidy Allocation for Non-Direct Development Funding Owners: Jason McGee @Peacemonger (Zcash Forum) Kris Nuttycombe @@ -68,7 +68,7 @@ Starting at Zcash's second halving in November 2024, under pre-existing consensus rules 100% of the block subsidies would be allocated to miners, and no further funds would be automatically allocated to any other entities. Consequently, unless the community takes action to approve new -block-reward-based funding, existing teams dedicated to development or outreach +block-subsidy-based funding, existing teams dedicated to development or outreach or furthering charitable, educational, or scientific purposes would likely need to seek other sources of funding; failure to obtain such funding would likely impair their ability to continue serving the Zcash ecosystem. Setting aside a diff --git a/zips/zip-2001.rst b/zips/zip-2001.rst index 5c588261e..410f6475f 100644 --- a/zips/zip-2001.rst +++ b/zips/zip-2001.rst @@ -67,8 +67,8 @@ that a funding stream may deposit funds into the deferred pool. Specification ============= -Modifications to ZIP 207 [#zip-0207]_ -------------------------------------- +Changes to ZIP 207 [#zip-0207]_ +------------------------------- The following paragraph is added to the section **Motivation**: @@ -147,9 +147,7 @@ added: Changes to support deferred funding streams are to be deployed with NU6. [#zip-0253]_ - - -Modifications to the protocol specification +Changes to the Zcash Protocol Specification ------------------------------------------- In section **4.17 Chain Value Pool Balances** [#protocol-chainvaluepoolbalances]_ diff --git a/zips/zip-2002.rst b/zips/zip-2002.rst index f05c4ee31..49d392e26 100644 --- a/zips/zip-2002.rst +++ b/zips/zip-2002.rst @@ -16,17 +16,17 @@ Terminology =========== -The key word "MUST" in this document is to be interpreted as described in BCP 14 [#BCP14]_ -when, and only when, it appears in all capitals. +The key word "MUST" in this document is to be interpreted as described in BCP 14 +[#BCP14]_ 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. [#zip-0200]_ -The terms "Testnet" and "Mainnet" are to be interpreted as described in section -3.12 of the Zcash Protocol Specification. [#protocol-networks]_ +The character § is used when referring to sections of the Zcash Protocol +Specification. [#protocol]_ -The character § is used when referring to sections of the Zcash Protocol Specification -[#protocol]_. +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [#protocol-networks]_ Abstract @@ -59,18 +59,20 @@ inputs to the transaction. Requirements ============ -There must not be any potentially error-prone calculations needed to compute the -fee for a given transaction. That is, the fee must be obvious from the encoding -of the transaction. +Parties that see a transaction, even in isolation, reliably know its fee. +That is, the fee must be explicit in the encoding of the transaction, +and no potentially error-prone calculations or additional chain data are +needed to compute it. Specification ============= -Transaction Format ------------------- +Changes to ZIP 230 [#zip-0230]_ +------------------------------- -The following field is added to the v6 transaction format [#zip-0230-transaction-format]_. +The following field is appended to the Common Transaction Fields of the v6 +transaction format after ``nExpiryHeight`` [#zip-0230-transaction-format]_: +-------+---------+------------+------------------------------------------------------+ | Bytes | Name | Data Type | Description | @@ -78,10 +80,12 @@ The following field is added to the v6 transaction format [#zip-0230-transaction | 8 | ``fee`` | ``uint64`` | The fee to be paid by this transaction, in zatoshis. | +-------+---------+------------+------------------------------------------------------+ -Consensus Rules ---------------- +Note: If both this ZIP and ZIP 233 are selected for inclusion in the same +Network Upgrade, then the ambiguity in ordering of the fields added by these +ZIPs would need to be resolved. -The following changes are to be made to the Zcash Protocol Specification [#protocol]_. +Changes to the Zcash Protocol Specification +------------------------------------------- In § 3.4 ‘Transactions and Treestates’ [#protocol-transactions]_ (last modified by ZIP 236 [#zip-0236]_), add the following consensus rule and note: @@ -97,27 +101,21 @@ In § 7.1 ‘Transaction Encoding and Consensus’ [#protocol-txnconsensus]_, ad [NU7 onward] ``fee`` MUST be in the range :math:`\{ 0 .. \mathsf{MAX\_MONEY} \}`. -Signature Hash --------------- -The transaction signature hashing algorithm defined in ZIP 244 is to be modified -for v6 transactions as follows: +Modifications relative to ZIP 244 [#zip-0244]_ +---------------------------------------------- -Section T.1: `header_digest` [#zip-0244-header-digest]_ is specified in -`draft-txv6-sighash` [#draft-txv6-sighash]_ to read: +Relative to the sighash algorithm defined in ZIP 244, the sighash algorithm +that applies to v6 transactions differs by appending the ``fee`` field to +the Common Transaction Fields that are the input to the digest in +T.1: header_digest [#zip-0244-header-digest]_:: + + T.1f: fee (8-byte little-endian fee amount) + +Note: If both this ZIP and ZIP 233 are selected for inclusion in the same +Network Upgrade, then the ambiguity in ordering of the fields added by these +ZIPs would need to be resolved. - 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: fee (8-byte little-endian fee value) - - The personalization field of this hash is set to:: - - "ZTxIdHeadersHash" Applicability ------------- @@ -129,7 +127,7 @@ Deployment ========== This ZIP is proposed to be deployed with the next transaction version change, -which is assumed to be v6. +which is assumed to be v6. [#zip-0230]_ Reference implementation @@ -148,7 +146,9 @@ References .. [#protocol-txnconsensus] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1.2: Transaction Consensus Rules `_ .. [#bitcointalk-fee-error] `Bitcoin Forum post by @Voiceeeeee, March 8, 2017. "PLEASE HELP.. I sent a transaction with a 2.5 BTC transaction fee" `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ -.. [#zip-0230-transaction-format] `ZIP 230: Version 6 Transaction Format `_ +.. [#zip-0230] `ZIP 230: Version 6 Transaction Format `_ +.. [#zip-0230-transaction-format] `ZIP 230: Version 6 Transaction Format. Specification: Transaction Format `_ .. [#zip-0236] `ZIP 236: Blocks should balance exactly `_ +.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#zip-0244-header-digest] `ZIP 244: Transaction Identifier Non-Malleability. Section T.1: Header Digest `_ .. [#draft-txv6-sighash] `ZIP draft: Version 6 Transaction Signature Validation `_ diff --git a/zips/zip-2003.rst b/zips/zip-2003.rst index f5a3a404c..9101ea32b 100644 --- a/zips/zip-2003.rst +++ b/zips/zip-2003.rst @@ -13,17 +13,17 @@ Terminology =========== -The key word "MUST" in this document is to be interpreted as described in BCP 14 [#BCP14]_ -when, and only when, it appears in all capitals. +The key word "MUST" in this document is to be interpreted as described in BCP 14 +[#BCP14]_ 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. [#zip-0200]_ -The terms "Testnet" and "Mainnet" are to be interpreted as described in section -3.12 of the Zcash Protocol Specification. [#protocol-networks]_ +The character § is used when referring to sections of the Zcash Protocol +Specification. [#protocol]_ -The character § is used when referring to sections of the Zcash Protocol Specification -[#protocol]_. +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [#protocol-networks]_ Abstract @@ -103,10 +103,9 @@ Interaction with the proposed Network Sustainability Mechanism -------------------------------------------------------------- For clarity, the Sprout chain value pool balance as of activation of this ZIP -remains issued. If the Network Sustainability Mechanism ZIPs that affect -issuance ([#draft-zip-0233]_ and [#draft-zip-0234]_) are activated, then the -Sprout chain value pool balance is, therefore, not considered part of the -“Money Reserve” as a consequence of activating this ZIP. +remains issued. If the Network Sustainability Mechanism ZIPs that affect issuance +([#zip-0233]_ and [#zip-0234]_) are also activated, then this ZIP would not cause +the Sprout chain value pool to be considered part of the “Money Reserve”. Deployment @@ -141,6 +140,6 @@ References .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances `_ .. [#zip-0225] `ZIP 225: Version 5 Transaction Format `_ -.. [#draft-zip-0233] `Draft ZIP 233: Network Sustainability Mechanism: Burning `_ -.. [#draft-zip-0234] `Draft ZIP 234: Network Sustainability Mechanism: Issuance Smoothing `_ +.. [#zip-0233] `ZIP 233: Network Sustainability Mechanism: Burning `_ +.. [#zip-0234] `ZIP 234: Network Sustainability Mechanism: Issuance Smoothing `_ .. [#cultivating-sapling] `Cultivating Sapling: Faster zk-SNARKs. Sean Bowe, September 13, 2017. `_ diff --git a/zips/zip-2004.rst b/zips/zip-2004.rst index 08286b589..2d974cf7b 100644 --- a/zips/zip-2004.rst +++ b/zips/zip-2004.rst @@ -20,11 +20,11 @@ The key word "MUST" in this document is to be interpreted as described in BCP 14 The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [#zip-0200]_ -The terms "Testnet" and "Mainnet" are to be interpreted as described in section -3.12 of the Zcash Protocol Specification. [#protocol-networks]_ +The character § is used when referring to sections of the Zcash Protocol +Specification. [#protocol]_ -The character § is used when referring to sections of the Zcash Protocol Specification -[#protocol]_. +The terms "Mainnet" and "Testnet" are to be interpreted as described in +§ 3.12 ‘Mainnet and Testnet’. [#protocol-networks]_ Abstract @@ -77,23 +77,23 @@ independent of note encryption. Specification ============= -Changes to the protocol specification -------------------------------------- +Changes to the Zcash Protocol Specification +------------------------------------------- In § 5.4.3 'Symmetric Encryption', rename :math:`Sym` to :math:`NoteSym` and add the following text: Let :math:`\mathsf{NullSym.}\mathbf{K} := \mathbb{B}^{[256]}`, - :math:`\mathsf{NullSym.}\mathbf{P} := \mathbb{B^Y}^{\mathbb{N}}`, and - :math:`\mathsf{NullSym.}\mathbf{C} := \mathbb{B^Y}^{\mathbb{N}}`. + :math:`\mathsf{NullSym.}\mathbf{P} := \mathbb{B^Y}^{\mathbb{N}}`, and + :math:`\mathsf{NullSym.}\mathbf{C} := \mathbb{B^Y}^{\mathbb{N}}\!`. - Let :math:`\mathsf{NullSym.Encrypt_K}(\mathsf{P}) := \mathsf{P} || [0x00]^{16}`. + Let :math:`\mathsf{NullSym.Encrypt_K}(\mathsf{P}) := \mathsf{P} \,||\, [0x00]^{16}\!`. Define :math:`\mathsf{NullSym.Decrypt_K}(\mathsf{C})` as follows: - * If the last 16 bytes of :math:`\mathsf{C}` are not :math:`[0x00]^{16}`, - return :math:`\bot`. Otherwise discard those 16 bytes and return the - remaining prefix of :math:`\mathsf{C}`. + * If the last 16 bytes of :math:`\mathsf{C}` are not :math:`[0x00]^{16}\!`, + return :math:`\bot\!`. Otherwise discard those 16 bytes and return the + remaining prefix of :math:`\mathsf{C}\!`. Note: These definitions intentionally ignore the key; :math:`\mathsf{NullSym}` is not a secure authenticated encryption scheme. It MUST be used only for @@ -110,11 +110,11 @@ to let :math:`\mathsf{NoteSym}` and :math:`\mathsf{NullSym}` be as instantiated in § 5.4.3 'Symmetric Encryption'. - [Pre-NU7] let :math:`\mathsf{Sym}` be :math:`\mathsf{NoteSym}`. + [Pre-NU7] let :math:`\mathsf{Sym}` be :math:`\mathsf{NoteSym}\!`. [NU7 onward] if the note to be decrypted is in an output of a version 6 or later coinbase transaction, let :math:`\mathsf{Sym}` be - :math:`\mathsf{NullSym}`, otherwise let it be :math:`\mathsf{NoteSym}`. + :math:`\mathsf{NullSym}\!`, otherwise let it be :math:`\mathsf{NoteSym}\!`. These changes apply identically to Mainnet and Testnet. @@ -125,7 +125,7 @@ Deployment ========== This ZIP is proposed to be deployed with the next transaction version change, -which is assumed to be v6. +which is assumed to be v6. [#zip-0230]_ Reference implementation @@ -150,3 +150,4 @@ References .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0212] `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext `_ .. [#zip-0213] `ZIP 213: Shielded Coinbase `_ +.. [#zip-0230] `ZIP 230: Version 6 Transaction Format `_