From ed3af0a2f57fabe1523f87a76f8c6d233c1d1a58 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Wed, 3 Jul 2024 20:13:32 +0000 Subject: [PATCH] Render manually, while the CI-based rendering is broken --- README.rst | 15 ++ draft-nuttycom-lockbox-streams.html | 114 +++++++++++++ index.html | 8 +- zip-0216.html | 4 +- zip-guide-markdown.html | 241 +++++++--------------------- 5 files changed, 194 insertions(+), 188 deletions(-) create mode 100644 draft-nuttycom-lockbox-streams.html diff --git a/README.rst b/README.rst index 5fc4ea56..11c2f9ec 100644 --- a/README.rst +++ b/README.rst @@ -149,3 +149,18 @@ Index of ZIPs guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft + +Drafts without assigned ZIP numbers +----------------------------------- + +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. + +.. raw:: html + + + + +
Title
Lockbox for Decentralized Grants Allocation
diff --git a/draft-nuttycom-lockbox-streams.html b/draft-nuttycom-lockbox-streams.html new file mode 100644 index 00000000..78e8210b --- /dev/null +++ b/draft-nuttycom-lockbox-streams.html @@ -0,0 +1,114 @@ + + + + Draft nuttycom-lockbox-streams: Lockbox for Decentralized Grants Allocation + + + + +
+ 
ZIP: Unassigned
+Title: Lockbox for Decentralized Grants Allocation
+Owners: Kris Nuttycombe <kris@nutty.land>
+Original-Authors: Skylar Saveland <skylar@free2z.com>
+Credits: Daira-Emma Hopwood <daira-emma@electriccoin.co>
+         Jack Grigg <jack@electriccoin.co>
+Status: Draft
+Category: Consensus
+Created: 2024-07-02
+License: MIT
+Pull-Request: <https://github.com/zcash/zips/pull/>
+

Terminology

+

The key words "MUST", "REQUIRED", "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.

+
+

Abstract

+

This ZIP specifies a change to the Zcash consensus protocol to define a pool of issued Zcash value to be used to fund future development efforts within the Zcash ecosystem.

+

This ZIP builds upon the funding stream mechanism defined in ZIP 207 3. It defines a new "DEFERRED_POOL" funding stream type such that portions of the block reward sent to a stream of this type are deposited directly into the deferred funding pool instead of being sent to a recipient address. Other ways of adding to the pool, such as allowing for direct deposits or fee value currently allocated to miners may be defined in the future.

+
+

Motivation

+

In accordance with ZIP 1014, 2 the Zcash block reward is allocated with 80% going to miners, and the remaining 20% distributed among the Major Grants Fund (8%), Electric Coin Company (ECC) (7%), and the Zcash Foundation (ZF) (5%). This funding structure supports various essential activities such as protocol development, security, marketing, and legal expenses. However, this model will expire in November 2024, leading to the entire block reward being allocated to miners if no changes are made.

+

Several draft ZIPs under consideration for replacing the existing direct allocation of block rewards suggest that part of the block reward be directed to a reserve, the distribution of which is to be determined via a future ZIP. This ZIP is intended to provide a common mechanism that can be used to implement these various proposals.

+
+

Requirements

+

The Zcash protocol will maintain a new Deferred chain pool value balance + \(\mathsf{PoolValue}_{Deferred}\) + for the deferred funding pool, in much the same fashion as it maintains chain pool value balances for the transparent, Sprout, Sapling, and Orchard pools.

+

The funding stream mechanism defined in ZIP 207 3 is modified such that a funding stream may deposit funds into the deferred pool.

+
+

Specification

+

Deferred Development Fund Chain Value Pool Balance

+

Full node implementations MUST track an additional + \(\mathsf{PoolValue}_{Deferred}\) + chain value pool balance, in addition to the Sprout, Sapling, and Orchard chain value pool balances. This balance is set to zero prior to the activation of Network Upgrade 6.

+

ZIP 207 3 is modified as follows:

+

In the section Funding streams 4, instead of:

+
+

Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.

+
+

it will be modified to read:

+
+

Each funding stream has an associated sequence of recipients, each of which MUST be either a transparent P2SH address, a Sapling address, or the identifier DEFERRED_POOL.

+
+

In the section Consensus rules 5, the following will be added:

+
+

The "prescribed way" to pay to the DEFERRED_POOL is to add + \(\mathsf{FundingStream[FUND].Value}(\mathsf{height})\) + to + \(\mathsf{PoolValue}_{Deferred}\) + .

+
+

The protocol specification is modified to define the "total issued supply" such that the total issued supply as of a given height is given by the function:

+
\(\begin{array}{ll} +\mathsf{IssuedSupply}(\mathsf{height}) := &\!\!\!\!\mathsf{PoolValue}_{Transparent}(\mathsf{height}) \\ +&+\;\; \mathsf{PoolValue}_{Sprout}(\mathsf{height}) \\ +&+\,\; \mathsf{PoolValue}_{Sapling}(\mathsf{height}) \\ +&+\,\; \mathsf{PoolValue}_{Orchard}(\mathsf{height}) \\ +&+\,\; \mathsf{PoolValue}_{Deferred}(\mathsf{height}) +\end{array}\)
+
+
+

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"
+ + + + + + + +
2ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants
+ + + + + + + +
3ZIP 207: Funding Streams
+ + + + + + + +
4ZIP 207: Funding Streams. Section: Funding streams
+ + + + + + + +
5ZIP 207: Funding Streams. Section: Consensus rules
+
+
+ + \ No newline at end of file diff --git a/index.html b/index.html index 0e93d84b..de0e8776 100644 --- a/index.html +++ b/index.html @@ -121,8 +121,14 @@ 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 - guide-markdown {Something Short and To the Point} Draft + guide-markdown {Something Short and To the Point} Draft guide {Something Short and To the Point} Draft + +

Drafts without assigned ZIP numbers

+

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.

+ + +
Title
Lockbox for Decentralized Grants Allocation
diff --git a/zip-0216.html b/zip-0216.html index e32adc95..52bc7ada 100644 --- a/zip-0216.html +++ b/zip-0216.html @@ -29,9 +29,9 @@ Discussions-To: <https://g \(u\!\) -coordinate is zero, there are two encodings that will be accepted:

// Fix the sign of `u` if necessary
-let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1);
+let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1);
 let u_negated = -u;
-let final_u = Fq::conditional_select(&u, &u_negated, flip_sign);
+let final_u = Fq::conditional_select(&u, &u_negated, flip_sign);

This code accepts either sign bit, because u_negated == u.

There are two points on the Jubjub curve with \(u\!\) diff --git a/zip-guide-markdown.html b/zip-guide-markdown.html index e1b2b280..b9121a6d 100644 --- a/zip-guide-markdown.html +++ b/zip-guide-markdown.html @@ -19,236 +19,107 @@ Created: yyyy-mm-dd License: {usually MIT} Pull-Request: <https://github.com/zcash/zips/pull/???>

Don’t Panic

-

If this is your first time writing a ZIP, the structure and format -may look intimidating. But really, it’s just meant to reflect -common-sense practice and some technical conventions. Feel free to start -with a simple initial draft that gets ideas across, even if it doesn’t -quite follow this format. The community and ZIP editors will help you -figure things out and get it into shape later.

+

If this is your first time writing a ZIP, the structure and format may look intimidating. But really, it’s just meant to reflect common-sense practice and some technical conventions. Feel free to start with a simple initial draft that gets ideas across, even if it doesn’t quite follow this format. The community and ZIP editors will help you figure things out and get it into shape later.

{Delete this section.}

Terminology

-

{Edit this to reflect the key words that are actually used.} The key -words “MUST”, “REQUIRED”, “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.

-

{Avoid duplicating definitions from other ZIPs. Instead use wording -like this:}

-

The terms “Mainnet” and “Testnet” in this document are to be -interpreted as defined in the Zcash protocol specification 2.

-

The term “full validator” in this document is to be interpreted as -defined in the Zcash protocol specification 3.

+

{Edit this to reflect the key words that are actually used.} The key words “MUST”, “REQUIRED”, “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.

+

{Avoid duplicating definitions from other ZIPs. Instead use wording like this:}

+

The terms “Mainnet” and “Testnet” in this document are to be interpreted as defined in the Zcash protocol specification 2.

+

The term “full validator” in this document is to be interpreted as defined in the Zcash protocol specification 3.

The terms below are to be interpreted as follows:

{Term to be defined}
-
-

{Definition.}

+

{Definition.}

{Another term}
-
-

{Definition.}

+

{Definition.}

Abstract

{Describe what this proposal does, typically in a few paragraphs.

-

The Abstract should only provide a summary of the ZIP; the ZIP should -remain complete without the Abstract.

-

Use links where applicable, e.g. 4 5.}

+

The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.

+

Use links where applicable, e.g. 4 5.}

Motivation

{Why is this proposal needed?

-

This is one of the most important sections of the ZIP, and should be -detailed and comprehensive. It shouldn’t include any of the actual -specification – don’t put conformance requirements in this section.

-

Explain the status quo, why the status quo is in need of improvement, -and if applicable, the history of how this area has changed. Then -describe at a high level why this proposed solution addresses -the perceived issues. It is ok if this is somewhat redundant with the -abstract, but here you can go into a lot more detail.}

+

This is one of the most important sections of the ZIP, and should be detailed and comprehensive. It shouldn’t include any of the actual specification – don’t put conformance requirements in this section.

+

Explain the status quo, why the status quo is in need of improvement, and if applicable, the history of how this area has changed. Then describe at a high level why this proposed solution addresses the perceived issues. It is ok if this is somewhat redundant with the abstract, but here you can go into a lot more detail.}

Requirements

-

{Describe design constraints on, or goals for the solution – -typically one paragraph for each constraint or goal. Again, don’t -actually specify anything here; this section is primarily for use as a -consistency check that what is specified meets the requirements.}

+

{Describe design constraints on, or goals for the solution – typically one paragraph for each constraint or goal. Again, don’t actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements.}

Non-requirements

-

{This section is entirely optional. If it is present, it describes -issues that the proposal is not attempting to address, that -someone might otherwise think it does or should.}

+

{This section is entirely optional. If it is present, it describes issues that the proposal is not attempting to address, that someone might otherwise think it does or should.}

Specification

{Replace this entire section.}

-

The Specification section describes what should change, using precise -language and conformance key words. Anything that is required in -order to implement the ZIP (or follow its process, in the case of a -Process ZIP) should be in this section.

-

Avoid overspecification! Also avoid underspecification. Specification -is hard. Don’t be afraid to ask for help.

-

Feel free to copy from other ZIPs doing similar things, e.g. defining -RPC calls, consensus rules, etc.

-

ZIPs MUST take into account differences between the Zcash Mainnet and -Testnet 6 where applicable. A consensus ZIP -MUST be able to be deployed on both Mainnet and Testnet.

-

Unless the specification is particularly simple, you will need to -organise it under subheadings.

+

The Specification section describes what should change, using precise language and conformance key words. Anything that is required in order to implement the ZIP (or follow its process, in the case of a Process ZIP) should be in this section.

+

Avoid overspecification! Also avoid underspecification. Specification is hard. Don’t be afraid to ask for help.

+

Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls, consensus rules, etc.

+

ZIPs MUST take into account differences between the Zcash Mainnet and Testnet 6 where applicable. A consensus ZIP MUST be able to be deployed on both Mainnet and Testnet.

+

Unless the specification is particularly simple, you will need to organise it under subheadings.

Example subheading

-

At least while the ZIP is in Draft, we encourage writing open -questions and TODOs.

+

At least while the ZIP is in Draft, we encourage writing open questions and TODOs.

Open questions

TODO: define byte encoding for the Jabberwock.

Comparison of ZIPs to RFCs

-

Like RFCs, ZIPs are precise technical documents that SHOULD give -enough implementation information to implement part of a Zcash-related -protocol or follow a Zcash-related process 7.

+

Like RFCs, ZIPs are precise technical documents that SHOULD give enough implementation information to implement part of a Zcash-related protocol or follow a Zcash-related process 7.

ZIPs are different from RFCs in the following ways:

Using mathematical notation

-

Embedded LaTeX x + y is allowed and -encouraged in ZIPs. The syntax for inline math is -“:math:latex -code`" in reStructuredText or "latexcode`” -in Markdown. The rendered HTML will use KaTeX 8, -which only supports a subset of LaTeX, so you will need to double-check -that the rendering is as intended.

-

In general the conventions in the Zcash protocol specification SHOULD -be followed. If you find this difficult, don’t worry too much about it -in initial drafts; the ZIP editors will catch any inconsistencies in -review.

+

Embedded LaTeX x + y is allowed and encouraged in ZIPs. The syntax for inline math is “:math:latex code`" in reStructuredText or "latexcode`” in Markdown. The rendered HTML will use KaTeX 8, which only supports a subset of LaTeX, so you will need to double-check that the rendering is as intended.

+

In general the conventions in the Zcash protocol specification SHOULD be followed. If you find this difficult, don’t worry too much about it in initial drafts; the ZIP editors will catch any inconsistencies in review.

Notes and warnings

-

“.. note::” in reStructuredText, or -“:::info” (terminated by “:::”) in Markdown, -can be used for an aside from the main text.

-

The rendering of notes is colourful and may be distracting, so they -should only be used for important points.

+

“.. note::” in reStructuredText, or “:::info” (terminated by “:::”) in Markdown, can be used for an aside from the main text.

+

The rendering of notes is colourful and may be distracting, so they should only be used for important points.

-

“.. warning::” in reStructuredText, or -“:::warning” (terminated by “:::”) in -Markdown, can be used for warnings.

-

Warnings should be used very sparingly — for example to signal that a -entire specification, or part of it, may be inapplicable or could cause -significant interoperability or security problems. In most cases, a -“MUST” or “SHOULD” conformance requirement is more appropriate.

+

“.. warning::” in reStructuredText, or “:::warning” (terminated by “:::”) in Markdown, can be used for warnings.

+

Warnings should be used very sparingly — for example to signal that a entire specification, or part of it, may be inapplicable or could cause significant interoperability or security problems. In most cases, a “MUST” or “SHOULD” conformance requirement is more appropriate.

Valid markup

-

This is optional before publishing a PR, but to check whether a -document is valid reStructuredText or Markdown, first install -rst2html5 and pandoc. E.g. on Debian-based -distros::

+

This is optional before publishing a PR, but to check whether a document is valid reStructuredText or Markdown, first install rst2html5 and pandoc. E.g. on Debian-based distros::

sudo apt install python3-pip pandoc perl sed
 pip3 install docutils==0.19 rst2html5
-

Then, with draft-myzip.rst or -draft-myzip.md in the root directory of a clone of this -repo, run::

+

Then, with draft-myzip.rst or draft-myzip.md in the root directory of a clone of this repo, run::

make draft-myzip.html
-

(or just “make”) and view draft-myzip.html -in a web browser.

+

(or just “make”) and view draft-myzip.html in a web browser.

Citations and references

-

Each reference should be given a short name, e.g. “snark” 9. The syntax to cite that reference -is “[#snark]_” in reStructuredText, or -“[^snark]” in Markdown.

-

The corresponding entry in the References -section should look like this in reStructuredText:

-
.. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+

Each reference should be given a short name, e.g. “snark” 9. The syntax to cite that reference is “[#snark]_” in reStructuredText, or “[^snark]” in Markdown.

+

The corresponding entry in the References section should look like this in reStructuredText:

+
.. [#snark] `The Hunting of the Snark <https://www.gutenberg.org/files/29888/29888-h/29888-h.htm>_. Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.

or like this in Markdown::

-
[^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
-

Note that each entry must be on a single line regardless of how long -that makes the line. In Markdown there must be a blank line between -entries.

-

The current rendering of a Markdown ZIP reorders the references -according to their first use; the rendering of a reStructuredText ZIP -keeps them in the same order as in the References section.

+
[^snark] [The Hunting of the Snark](https://www.gutenberg.org/files/29888/29888-h/29888-h.htm). Lewis Carroll, with illustrations by Henry Holiday. MacMillan and Co. London. March 29, 1876.
+

Note that each entry must be on a single line regardless of how long that makes the line. In Markdown there must be a blank line between entries.

+

The current rendering of a Markdown ZIP reorders the references according to their first use; the rendering of a reStructuredText ZIP keeps them in the same order as in the References section.

To link to another section of the same ZIP, use

-
`Section title`_
+
`Section title`_

in reStructuredText, or

-
[Section title]
+
[Section title]

in Markdown.

-

Citing the Zcash -protocol specification

-

For references to the Zcash protocol specification, prefer to link to -a section anchor, and name the reference as -[^protocol-<anchor>]. This makes it more likely that -the link will remain valid if sections are renumbered or if content is -moved. The anchors in the protocol specification can be displayed by -clicking on a section heading in most PDF viewers. References to -particular sections should be versioned, even though the link will point -to the most recent stable version.

-

Do not include the “https://zips.z.cash/” part of URLs -to ZIPs or the protocol spec.

+

Citing the Zcash protocol specification

+

For references to the Zcash protocol specification, prefer to link to a section anchor, and name the reference as [^protocol-<anchor>]. This makes it more likely that the link will remain valid if sections are renumbered or if content is moved. The anchors in the protocol specification can be displayed by clicking on a section heading in most PDF viewers. References to particular sections should be versioned, even though the link will point to the most recent stable version.

+

Do not include the “https://zips.z.cash/” part of URLs to ZIPs or the protocol spec.

Reference implementation

-

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

+

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

References

- +