From 14da9191fbe81781f74335b1460eb82817cf285f Mon Sep 17 00:00:00 2001 From: Josh Cincinnati Date: Sat, 16 Feb 2019 01:32:09 -0500 Subject: [PATCH 01/10] Add ZIP 0 draft. Author: Daira Hopwood Author: Josh Cincinnati --- README.md | 2 +- zip-0000.rst | 582 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 583 insertions(+), 1 deletion(-) create mode 100644 zip-0000.rst diff --git a/README.md b/README.md index 01ac8fcc..730e5d3c 100644 --- a/README.md +++ b/README.md @@ -10,5 +10,5 @@ Participation in the Zcash project is subject to a License ------- -The contents of this repository are released under the terms of the MIT license. +Unless otherwise stated in this repository's individual files, the contents of this repository are released under the terms of the MIT license. See [COPYING](COPYING) for more information or see http://opensource.org/licenses/MIT. diff --git a/zip-0000.rst b/zip-0000.rst new file mode 100644 index 00000000..803e3471 --- /dev/null +++ b/zip-0000.rst @@ -0,0 +1,582 @@ +:: + + ZIP: ?? + Title: ZIP Process + Champions: Daira Hopwood, Josh Cincinnati + Status: Draft + Type: Process + Created: 2019-02-16 + License: BSD-2-Clause + +Abstract +======== + +A Zcash Improvement Proposal (ZIP) is a design document providing +information to the Zcash community, or describing a new feature for +Zcash or its processes or environment. The ZIP should provide a concise +technical specification of the feature and a rationale for the feature. + +We intend ZIPs to be the primary mechanisms for proposing new features, +for collecting community input on an issue, and for documenting the +design decisions that have gone into Zcash. The author(s) of the ZIP +(known as Champions in this document) are responsible for building +consensus within the community and documenting dissenting opinions. + +Because the ZIPs are maintained as text files in a versioned repository, +their revision history is the historical record of the feature proposal. + +This document is based on the work done by Luke Dashjr with `BIP +2 `__ and Daira Hopwood with `Draft ZIP +0 `__. + +Copyright +========= + +This ZIP is dual-licensed under the Open Publication License and BSD +2-clause license. + +ZIP Workflow +============ + +The ZIP process begins with a new idea for Zcash. Each potential ZIP +must have a Champion -- someone who writes the ZIP using the style and +format described below, shepherds the discussions in the appropriate +forums, and attempts to build community consensus around the idea. The +ZIP Champion (a.k.a. author) should first attempt to ascertain whether +the idea is ZIP-able. Small enhancements or patches to a particular +piece of software often don't require standardisation between multiple +projects; these don't need a ZIP and should be injected into the +relevant project-specific development workflow with a patch submission +to the applicable issue tracker. Additionally, many ideas have been +brought forward for changing Zcash that have been rejected for various +reasons. The first step should be to search past discussions to see if +an idea has been considered before, and if so, what issues arose in its +progression. After investigating past work, the best way to proceed is +by posting about the new idea to the `Zcash Ecosystem Development +list `__. + +Vetting an idea publicly before going as far as writing a ZIP is meant +to save both the potential Champion and the wider community time. Asking +the Zcash community first if an idea is original helps prevent too much +time being spent on something that is guaranteed to be rejected based on +prior discussions (searching the internet does not always do the trick). +It also helps to make sure the idea is applicable to the entire +community and not just the Champion. Just because an idea sounds good to +the Champion does not mean it will work for most people in most areas +where Zcash is used. + +Once the Champion has asked the Zcash community as to whether an idea +has any chance of acceptance, a draft ZIP should be presented to the +`Zcash Ecosystem Development +list `__. +This gives the Champion a chance to flesh out the draft ZIP to make it +properly formatted, of high quality, and to address additional concerns +about the proposal. Following a discussion, the proposal should be +submitted to the `ZIPs git repository `__ +as a pull request. This draft must be written in ZIP style as described +below, and named with an alias such as +“zip-zatoshizakamoto-42millionzec” until the editor(s) have assigned it +a ZIP number (Champions MUST NOT self-assign ZIP numbers). + +ZIP Champions are responsible for collecting community feedback on both +the initial idea and the ZIP before submitting it for review. However, +wherever possible, long open-ended discussions on public mailing lists +should be avoided. + +It is highly recommended that a single ZIP contain a single key proposal +or new idea. The more focused the ZIP, the more successful it tends to +be. If in doubt, split your ZIP into several well-focused ones. + +When the ZIP draft is complete, the ZIP Editor(s) will assign the ZIP a +number, label it as Standards Track, Informational, or Process, and +merge the pull request to the ZIPs git repository. The ZIP Editor(s) +will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include +duplication of effort, disregard for formatting rules, being too +unfocused or too broad, being technically unsound, not providing proper +motivation or not in keeping with the Zcash philosophy. For a ZIP to be +accepted it must meet certain minimum criteria. It must be a clear and +complete description of the proposed enhancement. The enhancement must +represent a net improvement. The proposed implementation, if applicable, +must be solid and must not complicate the protocol unduly. + +The ZIP Champion may update the draft as necessary in the git +repository. Updates to drafts should also be submitted by the Champion +as pull requests. + +Transferring ZIP Ownership +-------------------------- + +It occasionally becomes necessary to transfer ownership of ZIPs to a new +Champion. In general, we'd like to retain the original Champion as a +co-Champion of the transferred ZIP, but that's really up to the original +Champion. A good reason to transfer ownership is because the original +Champion no longer has the time or interest in updating it or following +through with the ZIP process, or has fallen off the face of the 'net +(i.e. is unreachable or not responding to email). A bad reason to +transfer ownership is because you don't agree with the direction of the +ZIP. We try to build consensus around a ZIP, but if that's not possible, +you can always submit a competing ZIP. + +If you are interested in assuming ownership of a ZIP, send a message +asking to take over, addressed to both the original Champion and the ZIP +Editor(s). If the original Champion doesn't respond to email in a timely +manner, the ZIP Editor(s) will make a unilateral decision (it's not like +such decisions can't be reversed :). + +ZIP Editors +----------- + +The current ZIP Editors are Daira Hopwood, representing the Zcash +Company, and Josh Cincinnati, representing the Zcash Foundation. Both +can be reached at zips@z.cash . The current design of the ZIP Process +dictates that there are always at least two ZIP Editors: one from the +Zcash Company and one from the Zcash Foundation. Additional Editors may +be selected by consensus among the current Editors. + +ZIP Editor Responsibilities & Workflow +-------------------------------------- + +The ZIP Editors subscribe to the Zcash Ecosystem Development list. + +For each new ZIP that comes in an Editor confirms the following: + +- Read the ZIP to check if it is ready: sound and complete. The ideas + must make technical sense, even if they don't seem likely to be + accepted. +- The title should accurately describe the content. +- The ZIP draft must have been sent to the Zcash Ecosystem Development + mailing list for discussion. +- Motivation and backward compatibility (when applicable) must be + addressed. +- Licensing terms must be acceptable for ZIPs. + +If the ZIP isn't ready, the editor will send it back to the Champion for +revision, with specific instructions. + +Once the ZIP is ready for the repository it should be submitted as a +“pull request” to the `ZIPs git +repository `__ where it may get further +feedback. + +The ZIP Editors will: + +- Assign a ZIP number in the pull request. +- Merge the pull request when it is ready. +- List the ZIP in `README.mediawiki `__ + +The ZIP editors monitor ZIP changes and update ZIP headers as +appropriate. + +The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP +for any of the following reasons: + +| ``* it violates the `Zcash Code of Conduct`_;`` +| ``* it appears too unfocused or broad;`` +| ``* it duplicates effort in other ZIPs without sufficient technical justification`` +| ``  (however, alternative proposals to address similar or overlapping problems`` +| ``  are not excluded for this reason);`` +| ``* it has manifest security flaws (including being unrealistically dependent`` +| ``  on user vigilance to avoid security weaknesses);`` +| ``* it disregards compatibility with the existing Zcash blockchain or ecosystem;`` +| ``* it is manifestly unimplementable;`` +| ``* it includes buggy code, pseudocode, or algorithms;`` +| ``* it manifestly violates common expectations of a significant portion of the`` +| ``  Zcash community;`` +| ``* it updates a Draft ZIP to Released when there is significant community`` +| ``  opposition to its content (however, Draft ZIPs explicitly may describe`` +| ``  proposals to which there is, or could be expected, significant community`` +| ``  opposition);`` +| ``* in the case of a Released ZIP, the update makes a substantive change to`` +| ``  which there is significant community opposition;`` +| ``* it is dependent on a patent that could potentially be an obstacle to`` +| ``  adoption of the ZIP;`` +| ``* it includes commercial advertising;`` +| ``* it disregards formatting rules;`` +| ``* it makes non-editorial edits to previous entries in a ZIP's Change history;`` +| ``* an update to an existing ZIP extends or changes its scope to an extent`` +| ``  that would be better handled as a separate ZIP;`` +| ``* a new ZIP has been proposed for a category that does not reflect its content,`` +| ``  or an update would change a ZIP to an inappropriate category;`` +| ``* it updates a Released ZIP to Draft when the specification is already`` +| ``  implemented and has been in common use;`` +| ``* it violates any specific "MUST" or "MUST NOT" rule in this document; +| ``* the expressed political views of a Champion of the document are inimical`` +| ``  to the `Zcash Code of Conduct `__ +| ``  (except in the case of an update removing that Champion);`` +| ``* it is not authorized by the stated ZIP Champions;`` +| ``* it removes an Champion without their consent (unless the reason for removal`` +| ``  is directly related to a breach of the Code of Conduct by that Champion);`` +| ``* it is spam.`` + +The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal +or update that does not violate any of these criteria. If they refuse a +proposal or update, they MUST give an explanation of which of the +criteria were violated, with the exception that spam may be deleted +without an explanation. + +Note that it is not the primary responsibility of the ZIP Editors to +review proposals for security, correctness, or implementability. + +Please send all ZIP-related communications either by email to +, or by opening an issue on the `ZIPs issue +tracker `__. All communications +should abide by the `Zcash Code of +Conduct `__ +and follow `the GNU Kind Communication +Guidelines `__ + +ZIP format and structure +======================== + +Specification +------------- + +ZIPs should be written in mediawiki format. + +Each ZIP should have the following parts: + +- Preamble -- Headers containing metadata about the ZIP (`see + below <#ZIP_header_preamble>`__). + +- Abstract -- A short (~200 word) description of the technical issue + being addressed. + +- Copyright -- The ZIP must be explicitly licensed under acceptable + copyright terms (`see below <#ZIP_licensing>`__). + +- Specification -- The technical specification should describe the + syntax and semantics of any new feature. The specification should be + detailed enough to allow competing, interoperable implementations for + any of the current Zcash platforms. + +- Motivation -- The motivation is critical for ZIPs that want to change + the Zcash protocol. It should clearly explain why the existing + protocol is inadequate to address the problem that the ZIP solves. + +- Rationale -- The rationale fleshes out the specification by + describing what motivated the design and why particular design + decisions were made. It should describe alternate designs that were + considered and related work. The rationale should provide evidence of + consensus within the community and discuss important objections or + concerns raised during discussion. + +- Reference implementation -- The reference implementation must be + completed before any ZIP is given status “Implemented”, but it + generally need not be completed before the ZIP is accepted into + Proposed. + +ZIP header preamble +~~~~~~~~~~~~~~~~~~~ + +Each ZIP must begin with an RFC 822 style header preamble. The headers +must appear in the following order. Headers marked with “\*” are +optional and are described below. All other headers are required. + +| `` ZIP: ``\ +| `` Title: ``\ +| `` Champions: ``\ +| `` Discussions-To: ``\ +| `` Status: ``\ +| `` Type: ``\ +| `` Network Upgrade: ``\ +| `` Created: ``\ +| `` License: ``\ +| `` License-Code: ``\ +| `` Discussion-URL: ``\ +| `` Obsoleted by: ``\ +| `` Updated by: ``\ +| `` Obsoletes: ``\ +| `` Updates: ``\ + +The Champions header lists the names and email addresses of all the +champions/owners of the ZIP. The format of the Champions header value +must be + +`` Random J. User `` + +If there are multiple champions, each should be on a separate line +following RFC 2822 continuation line conventions. + +While a ZIP is in private discussions (usually during the initial Draft +phase), a Discussions-To header will indicate the mailing list or URL +where the ZIP is being discussed. No Discussions-To header is necessary +if the ZIP is being discussed privately with the Champion, or on the +Zcash email mailing lists. + +The Type header specifies the type of ZIP: Standards Track, +Informational, or Process. + +The Created header records the date that the ZIP was assigned a number, +while Discussion-URL is used to record when new versions of the ZIP are +posted to zcash mailing lists. Dates should be in yyyy-mm-dd format, +e.g. 2001-08-14. + +Auxiliary Files +~~~~~~~~~~~~~~~ + +ZIPs may include auxiliary files such as diagrams. Auxiliary files +should be included in a subdirectory for that ZIP; that is, any ZIP that +requires more than one file should be in a subdirectory named zip-XXXX. + +ZIP types +========= + +There are several kinds of ZIP: + +- A Standards Track ZIP describes any change that affects most or all + Zcash implementations, such as a change to the network protocol, a + change in block or transaction validity rules, or any change or + addition that affects the interoperability of applications using + Zcash. Standards Track ZIPs consist of two parts, a design document + and a reference implementation -- but they need only include a design + document for the initial Draft. + +- An Informational ZIP describes a Zcash design issue, or provides + general guidelines or information to the Zcash community, but does + not propose a new feature. Informational ZIPs do not necessarily + represent a Zcash community consensus or recommendation, so users and + implementers are free to ignore Informational ZIPs or follow their + advice. + +- A Process ZIP describes a process surrounding Zcash, or proposes a + change to (or an event in) a process. Process ZIPs are like Standards + Track ZIPs but apply to areas other than the Zcash protocol itself. + They may propose an implementation, but not to Zcash's codebase; they + often require community consensus; unlike Informational ZIPs, they + are more than recommendations, and users are typically not free to + ignore them. Examples include procedures, guidelines, changes to the + decision-making process, and changes to the tools or environment used + in Zcash development. + +New categories may be added by consensus among the ZIP Editors. + +ZIP Status Field +================ + +- Draft: All initial ZIP submissions have this status. + +- Withdrawn: If the Champion decides to remove the ZIP from + consideration by the community, they may set the status to Withdrawn. + +- Active: Typically only used for Process/Informational ZIPs, achieved + once rough consensus is reached in PR/mailing list from Draft Process + ZIP. + +- Proposed: Typically the stage after Draft, added to a ZIP after + consideration and feedback from the community. The ZIP Editor(s) must + validate this change before it is approved. + +- Rejected: The status when progress hasn’t been made on the ZIP in one + year. Can revert back to Draft/Proposed if the Champion resumes work + or resolves issues preventing consensus. + +- Final: When a Standards, Consensus, or P2P Network ZIP is both + implemented and activated on the Zcash network. + +- Obsolete: The status when a ZIP is no longer relevant (typically when + superseded by another ZIP). + +More details on the status workflow in the section below. + +Specification +------------- + +Champions of a ZIP may decide on their own to change the status between +Draft or Withdrawn. + +A ZIP may only change status from Draft (or Rejected) to Proposed, when +the Champion deems it is complete and there is rough consensus on the +mailing list, validated by both the Zcash Company and Zcash Foundation +Editor(s). One Editor will not suffice -- there needs to consensus among +the Editors. If it's a Standards Track ZIP, upon changing status to +Proposed the Editor(s) will add the optional \*Network Upgrade\* to the +header, indicating the intent for the ZIP to be implemented in the +specified network upgrade. (All \*Network Upgrade\* schedules will be +distributed via the Zcash Ecosystem Developer list by the Editor(s).) + +A Standards Track ZIP may only change status from Proposed to +Implemented once the Champion provides an associated reference +implementation, typically in the period after the \*Network Upgrade\*'s +specification freeze but before the implementation audit. If they miss +this deadline, the Editor(s) or Champion(s) may choose to either update +the intended \*Network Upgrade Version\* at their discretion. + +ZIPs should be changed from Draft or Proposed status, to Rejected +status, upon request by any person, if they have not made progress in +one year. Such a ZIP may be changed to Draft status if the Champion +provides revisions that meaningfully address public criticism of the +proposal, or to Proposed status if it meets the criteria required as +described in the previous paragraph. + +A Standards, Consensus, or P2P Network ZIP becomes Final when its +associated Network Upgrade is activated on Zcash's mainnet. + +A Process or Informational ZIP may change status from Draft to Active +when it achieves rough consensus on the mailing list. Such a proposal is +said to have rough consensus if it has been open to discussion on the +development mailing list for at least one month, and no person maintains +any unaddressed substantiated objections to it. Addressed or obstructive +objections may be ignored/overruled by general agreement that they have +been sufficiently addressed, but clear reasoning must be given in such +circumstances. + +When an Active or Final ZIP is no longer relevant, its status may be +changed to Obsolete. This change must also be objectively verifiable +and/or discussed. Final ZIPs may be updated; the specification is still +in force but modified by another specified ZIP or ZIPs (check the +optional Updated-by header). + +ZIP Comments +============ + +Comments from the community on the ZIP should occur on the Zcash +Ecosystem Developer list and the comment fields of the pull requests in +any open ZIPs. Editors will use these sources to judge rough consensus. + +ZIP licensing +============= + +Specification +------------- + +New ZIPs may be accepted with the following licenses. Each new ZIP must +identify at least one acceptable license in its preamble. The License +header in the preamble must be placed after the Created header. Each +license must be referenced by their respective abbreviation given below. + +For example, a preamble might include the following License header: + +| ``   License: BSD-2-Clause`` +| ``   GNU-All-Permissive`` + +In this case, the ZIP text is fully licensed under both the OSI-approved +BSD 2-clause license as well as the GNU All-Permissive License, and +anyone may modify and redistribute the text provided they comply with +the terms of \*either\* license. In other words, the license list is an +“OR choice”, not an “AND also” requirement. + +It is also possible to license source code differently from the ZIP +text. A optional License-Code header is placed after the License header. +Again, each license must be referenced by their respective abbreviation +given below. + +For example, a preamble specifying the optional License-Code header +might look like: + +| ``   License: BSD-2-Clause`` +| ``   GNU-All-Permissive`` +| ``   License-Code: GPL-2.0+`` + +In this case, the code in the ZIP is not available under the BSD or +All-Permissive licenses, but only under the terms of the GNU General +Public License (GPL), version 2 or newer. If the code were to be +available under \*only\* version 2 exactly, the “+” symbol should be +removed from the license abbreviation. For a later version (eg, GPL +3.0), you would increase the version number (and retain or remove the +“+” depending on intent). + +| ``   License-Code: GPL-2.0   # This refers to GPL v2.0 *only*, no later license versions are acceptable.`` +| ``   License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.`` +| ``   License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.`` +| ``   License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.`` + +In the event that the licensing for the text or code is too complicated +to express with a simple list of alternatives, the list should instead +be replaced with the single term “Complex”. In all cases, details of the +licensing terms must be provided in the Copyright section of the ZIP. + +ZIPs are not required to be \*exclusively\* licensed under approved +terms, and may also be licensed under unacceptable licenses \*in +addition to\* at least one acceptable license. In this case, only the +acceptable license(s) should be listed in the License and License-Code +headers. + +Recommended licenses +~~~~~~~~~~~~~~~~~~~~ + +- MIT: `Expat/MIT/X11 license `__ +- BSD-2-Clause: `OSI-approved BSD 2-clause + license `__ +- BSD-3-Clause: `OSI-approved BSD 3-clause + license `__ +- CC0-1.0: `Creative Commons CC0 1.0 + Universal `__ +- GNU-All-Permissive: `GNU All-Permissive + License `__ +- Apache-2.0: `Apache License, version + 2.0 `__ + +In addition, it is recommended that literal code included in the ZIP be +dual-licensed under the same license terms as the project it modifies. +For example, literal code intended for zcashd would ideally be +dual-licensed under the MIT license terms as well as one of the above +with the rest of the ZIP text. + +Not recommended, but acceptable licenses +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- BSL-1.0: `Boost Software License, version + 1.0 `__ +- CC-BY-4.0: `Creative Commons Attribution 4.0 + International `__ +- CC-BY-SA-4.0: `Creative Commons Attribution-ShareAlike 4.0 + International `__ +- AGPL-3.0+: `GNU Affero General Public License (AGPL), version 3 or + newer `__ +- FDL-1.3: `GNU Free Documentation License, version + 1.3 `__ +- GPL-2.0+: `GNU General Public License (GPL), version 2 or + newer `__ +- LGPL-2.1+: `GNU Lesser General Public License (LGPL), version 2.1 or + newer `__ + +Not acceptable licenses +~~~~~~~~~~~~~~~~~~~~~~~ + +All licenses not explicitly included in the above lists are not +acceptable terms for a Zcash Improvement Proposal unless a later ZIP +extends this one to add them. However, ZIPs predating the acceptance of +this ZIP were allowed under other terms, and should use these +abbreviation when no other license is granted: + +- OPL: `Open Publication License, version + 1.0 `__ +- PD: Released into the public domain + +Rationale +--------- + +Bitcoin's BIP 1 allowed the Open Publication License or releasing into +the public domain; was this insufficient? + +- The OPL is generally regarded as obsolete, and not a license suitable + for new publications. +- Many are unfamiliar with the OPL terms, and may just prefer to use + the public domain rather than license under uncertain terms. +- The OPL license terms allowed for the author to prevent publication + and derived works, which was widely considered inappropriate. +- Public domain is not universally recognised as a legitimate action, + thus it is inadvisable. + +Why are there software licenses included? + +- Some ZIPs, especially consensus layer, may include literal code in + the ZIP itself which may not be available under the exact license + terms of the ZIP. +- Despite this, not all software licenses would be acceptable for + content included in ZIPs. + +Why is Public Domain no longer acceptable for new ZIPs? + +- In some jurisdictions, public domain is not recognised as a + legitimate legal action, leaving the ZIP simply copyrighted with no + redistribution or modification allowed at all. + +See Also +======== + +- `The GNU Kind Communication + Guidelines `__ +- `RFC 7282: On Consensus and Humming in the + IETF `__ +- `Zcash Network Upgrade Pipeline `__ From 04f4c32dda2471af1ddb91f2cb915e0225d3dbc3 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 24 Feb 2019 05:25:56 +0000 Subject: [PATCH 02/10] Mostly trivial wording changes and cosmetics; some simplifications. Remove OPL licensing; BSD 2-clause is sufficient. Signed-off-by: Daira Hopwood --- zip-0000.rst | 563 +++++++++++++++++++++++++-------------------------- 1 file changed, 275 insertions(+), 288 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index 803e3471..7488cbd6 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -1,12 +1,25 @@ :: - ZIP: ?? - Title: ZIP Process - Champions: Daira Hopwood, Josh Cincinnati - Status: Draft - Type: Process - Created: 2019-02-16 - License: BSD-2-Clause + ZIP: 0 + Title: ZIP Process + Champions: Daira Hopwood + Josh Cincinnati + Status: Draft + Type: Process + Created: 2019-02-16 + License: BSD-2-Clause + + +Terminology +=========== + +The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", +"OPTIONAL", and "REQUIRED" in this document are to be interpreted as +described in RFC 2119. [#RFC2119]_ + +The term "network upgrade" in this document is to be interpreted as +described in ZIP 200. [#zip-0200]_ + Abstract ======== @@ -16,7 +29,7 @@ information to the Zcash community, or describing a new feature for Zcash or its processes or environment. The ZIP should provide a concise technical specification of the feature and a rationale for the feature. -We intend ZIPs to be the primary mechanisms for proposing new features, +We intend ZIPs to be the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Zcash. The author(s) of the ZIP (known as Champions in this document) are responsible for building @@ -25,15 +38,10 @@ consensus within the community and documenting dissenting opinions. Because the ZIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. -This document is based on the work done by Luke Dashjr with `BIP -2 `__ and Daira Hopwood with `Draft ZIP -0 `__. +This document is based on the work done by Luke Dashjr with +`BIP 2 `__ and Daira Hopwood with +`Draft ZIP 0 `__. -Copyright -========= - -This ZIP is dual-licensed under the Open Publication License and BSD -2-clause license. ZIP Workflow ============ @@ -67,16 +75,16 @@ where Zcash is used. Once the Champion has asked the Zcash community as to whether an idea has any chance of acceptance, a draft ZIP should be presented to the -`Zcash Ecosystem Development -list `__. +`Zcash Ecosystem Development list +`__. This gives the Champion a chance to flesh out the draft ZIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the `ZIPs git repository `__ as a pull request. This draft must be written in ZIP style as described below, and named with an alias such as -“zip-zatoshizakamoto-42millionzec” until the editor(s) have assigned it -a ZIP number (Champions MUST NOT self-assign ZIP numbers). +``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned +it a ZIP number (Champions MUST NOT self-assign ZIP numbers). ZIP Champions are responsible for collecting community feedback on both the initial idea and the ZIP before submitting it for review. However, @@ -87,9 +95,9 @@ It is highly recommended that a single ZIP contain a single key proposal or new idea. The more focused the ZIP, the more successful it tends to be. If in doubt, split your ZIP into several well-focused ones. -When the ZIP draft is complete, the ZIP Editor(s) will assign the ZIP a +When the ZIP draft is complete, the ZIP Editors will assign the ZIP a number, label it as Standards Track, Informational, or Process, and -merge the pull request to the ZIPs git repository. The ZIP Editor(s) +merge the pull request to the ZIPs git repository. The ZIP Editors will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper @@ -103,6 +111,7 @@ The ZIP Champion may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the Champion as pull requests. + Transferring ZIP Ownership -------------------------- @@ -119,10 +128,11 @@ you can always submit a competing ZIP. If you are interested in assuming ownership of a ZIP, send a message asking to take over, addressed to both the original Champion and the ZIP -Editor(s). If the original Champion doesn't respond to email in a timely -manner, the ZIP Editor(s) will make a unilateral decision (it's not like +Editors. If the original Champion doesn't respond to email in a timely +manner, the ZIP Editors will make a unilateral decision (it's not like such decisions can't be reversed :). + ZIP Editors ----------- @@ -133,6 +143,7 @@ dictates that there are always at least two ZIP Editors: one from the Zcash Company and one from the Zcash Foundation. Additional Editors may be selected by consensus among the current Editors. + ZIP Editor Responsibilities & Workflow -------------------------------------- @@ -140,29 +151,28 @@ The ZIP Editors subscribe to the Zcash Ecosystem Development list. For each new ZIP that comes in an Editor confirms the following: -- Read the ZIP to check if it is ready: sound and complete. The ideas - must make technical sense, even if they don't seem likely to be - accepted. -- The title should accurately describe the content. -- The ZIP draft must have been sent to the Zcash Ecosystem Development - mailing list for discussion. -- Motivation and backward compatibility (when applicable) must be - addressed. -- Licensing terms must be acceptable for ZIPs. +* Read the ZIP to check if it is ready: sound and complete. The ideas + must make technical sense, even if they don't seem likely to be + accepted. +* The title should accurately describe the content. +* The ZIP draft must have been sent to the Zcash Ecosystem Development + mailing list or another suitable forum for discussion. +* Motivation and backward compatibility (when applicable) must be + addressed. +* The licensing terms are acceptable for ZIPs. If the ZIP isn't ready, the editor will send it back to the Champion for revision, with specific instructions. Once the ZIP is ready for the repository it should be submitted as a -“pull request” to the `ZIPs git -repository `__ where it may get further -feedback. +"pull request" to the `ZIPs git repository `__ +where it may get further feedback. The ZIP Editors will: -- Assign a ZIP number in the pull request. -- Merge the pull request when it is ready. -- List the ZIP in `README.mediawiki `__ +* Assign a ZIP number in the pull request. +* Merge the pull request when it is ready. +* List the ZIP in `README.rst `__ The ZIP editors monitor ZIP changes and update ZIP headers as appropriate. @@ -170,43 +180,42 @@ appropriate. The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons: -| ``* it violates the `Zcash Code of Conduct`_;`` -| ``* it appears too unfocused or broad;`` -| ``* it duplicates effort in other ZIPs without sufficient technical justification`` -| ``  (however, alternative proposals to address similar or overlapping problems`` -| ``  are not excluded for this reason);`` -| ``* it has manifest security flaws (including being unrealistically dependent`` -| ``  on user vigilance to avoid security weaknesses);`` -| ``* it disregards compatibility with the existing Zcash blockchain or ecosystem;`` -| ``* it is manifestly unimplementable;`` -| ``* it includes buggy code, pseudocode, or algorithms;`` -| ``* it manifestly violates common expectations of a significant portion of the`` -| ``  Zcash community;`` -| ``* it updates a Draft ZIP to Released when there is significant community`` -| ``  opposition to its content (however, Draft ZIPs explicitly may describe`` -| ``  proposals to which there is, or could be expected, significant community`` -| ``  opposition);`` -| ``* in the case of a Released ZIP, the update makes a substantive change to`` -| ``  which there is significant community opposition;`` -| ``* it is dependent on a patent that could potentially be an obstacle to`` -| ``  adoption of the ZIP;`` -| ``* it includes commercial advertising;`` -| ``* it disregards formatting rules;`` -| ``* it makes non-editorial edits to previous entries in a ZIP's Change history;`` -| ``* an update to an existing ZIP extends or changes its scope to an extent`` -| ``  that would be better handled as a separate ZIP;`` -| ``* a new ZIP has been proposed for a category that does not reflect its content,`` -| ``  or an update would change a ZIP to an inappropriate category;`` -| ``* it updates a Released ZIP to Draft when the specification is already`` -| ``  implemented and has been in common use;`` -| ``* it violates any specific "MUST" or "MUST NOT" rule in this document; -| ``* the expressed political views of a Champion of the document are inimical`` -| ``  to the `Zcash Code of Conduct `__ -| ``  (except in the case of an update removing that Champion);`` -| ``* it is not authorized by the stated ZIP Champions;`` -| ``* it removes an Champion without their consent (unless the reason for removal`` -| ``  is directly related to a breach of the Code of Conduct by that Champion);`` -| ``* it is spam.`` +* it violates the Zcash Code of Conduct [#conduct]_ ; +* it appears too unfocused or broad; +* it duplicates effort in other ZIPs without sufficient technical justification + (however, alternative proposals to address similar or overlapping problems + are not excluded for this reason); +* it has manifest security flaws (including being unrealistically dependent + on user vigilance to avoid security weaknesses); +* it disregards compatibility with the existing Zcash blockchain or ecosystem; +* it is manifestly unimplementable; +* it includes buggy code, pseudocode, or algorithms; +* it manifestly violates common expectations of a significant portion of the + Zcash community; +* it updates a Draft ZIP to Released when there is significant community + opposition to its content (however, Draft ZIPs explicitly may describe + proposals to which there is, or could be expected, significant community + opposition); +* in the case of a Released ZIP, the update makes a substantive change to + which there is significant community opposition; +* it is dependent on a patent that could potentially be an obstacle to + adoption of the ZIP; +* it includes commercial advertising or spam; +* it disregards formatting rules; +* it makes non-editorial edits to previous entries in a ZIP's Change history; +* an update to an existing ZIP extends or changes its scope to an extent + that would be better handled as a separate ZIP; +* a new ZIP has been proposed for a category that does not reflect its content, + or an update would change a ZIP to an inappropriate category; +* it updates a Released ZIP to Draft when the specification is already + implemented and has been in common use; +* it violates any specific "MUST" or "MUST NOT" rule in this document; +* the expressed political views of a Champion of the document are inimical + to the Zcash Code of Conduct [#conduct]_ (except in the case of an update + removing that Champion); +* it is not authorized by the stated ZIP Champions; +* it removes an Champion without their consent (unless the reason for removal + is directly related to a breach of the Code of Conduct by that Champion). The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update that does not violate any of these criteria. If they refuse a @@ -220,82 +229,82 @@ review proposals for security, correctness, or implementability. Please send all ZIP-related communications either by email to , or by opening an issue on the `ZIPs issue tracker `__. All communications -should abide by the `Zcash Code of -Conduct `__ +should abide by the Zcash Code of Conduct [#conduct]_ and follow `the GNU Kind Communication Guidelines `__ + ZIP format and structure ======================== -Specification -------------- +ZIPs SHOULD be written either in reStructuredText [#rst]_ or LaTeX [#latex]_. +In the latter case, a `Makefile` MUST be provided to build (at least) a +PDF version of the document. -ZIPs should be written in mediawiki format. +Each ZIP SHOULD have the following parts: -Each ZIP should have the following parts: +* Preamble -- Headers containing metadata about the ZIP (`see + below <#ZIP_header_preamble>`__). + The License field of the preamble indicates the licensing terms, + which MUST be acceptable according to <#ZIP_licensing>`__. -- Preamble -- Headers containing metadata about the ZIP (`see - below <#ZIP_header_preamble>`__). +* Terminology -- Definitions of technical or non-obvious terms used + in the document. -- Abstract -- A short (~200 word) description of the technical issue - being addressed. +* Abstract -- A short (~200 word) description of the technical issue + being addressed. -- Copyright -- The ZIP must be explicitly licensed under acceptable - copyright terms (`see below <#ZIP_licensing>`__). +* Specification -- The technical specification should describe the + interface and semantics of any new feature. The specification should be + detailed enough to allow competing, interoperable implementations for + any of the current Zcash platforms. -- Specification -- The technical specification should describe the - syntax and semantics of any new feature. The specification should be - detailed enough to allow competing, interoperable implementations for - any of the current Zcash platforms. +* Motivation -- The motivation is critical for ZIPs that want to change + the Zcash protocol. It should clearly explain why the existing + protocol is inadequate to address the problem that the ZIP solves. -- Motivation -- The motivation is critical for ZIPs that want to change - the Zcash protocol. It should clearly explain why the existing - protocol is inadequate to address the problem that the ZIP solves. +* Rationale -- The rationale fleshes out the specification by + describing what motivated the design and why particular design + decisions were made. It should describe alternate designs that were + considered and related work. The rationale should provide evidence of + consensus within the community and discuss important objections or + concerns raised during discussion. -- Rationale -- The rationale fleshes out the specification by - describing what motivated the design and why particular design - decisions were made. It should describe alternate designs that were - considered and related work. The rationale should provide evidence of - consensus within the community and discuss important objections or - concerns raised during discussion. - -- Reference implementation -- The reference implementation must be - completed before any ZIP is given status “Implemented”, but it - generally need not be completed before the ZIP is accepted into - Proposed. +* Reference implementation -- The reference implementation must be + completed before any ZIP is given status “Implemented”, but it + generally need not be completed before the ZIP is accepted into + Proposed. ZIP header preamble -~~~~~~~~~~~~~~~~~~~ +------------------- -Each ZIP must begin with an RFC 822 style header preamble. The headers -must appear in the following order. Headers marked with “\*” are -optional and are described below. All other headers are required. +Each ZIP must begin with an RFC 822-style header preamble. The following +header fields are REQUIRED:: -| `` ZIP: ``\ -| `` Title: ``\ -| `` Champions: ``\ -| `` Discussions-To: ``\ -| `` Status: ``\ -| `` Type: ``\ -| `` Network Upgrade: ``\ -| `` Created: ``\ -| `` License: ``\ -| `` License-Code: ``\ -| `` Discussion-URL: ``\ -| `` Obsoleted by: ``\ -| `` Updated by: ``\ -| `` Obsoletes: ``\ -| `` Updates: ``\ +  ZIP: +  Title: +  Champions: +  Status: +  Category: + Created: +  License: + +The following additional header fields are OPTIONAL:: + +  Discussions-To: +  Network Upgrade: + Obsoleted by: + Updated by: + Obsoletes: + Updates: The Champions header lists the names and email addresses of all the champions/owners of the ZIP. The format of the Champions header value -must be +SHOULD be:: -`` Random J. User `` + Random J. User  -If there are multiple champions, each should be on a separate line -following RFC 2822 continuation line conventions. +If there are multiple champions, each should be on a separate line. While a ZIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL @@ -303,78 +312,81 @@ where the ZIP is being discussed. No Discussions-To header is necessary if the ZIP is being discussed privately with the Champion, or on the Zcash email mailing lists. -The Type header specifies the type of ZIP: Standards Track, +The Category header specifies the type of ZIP: Consensus, Standards Track, Informational, or Process. -The Created header records the date that the ZIP was assigned a number, -while Discussion-URL is used to record when new versions of the ZIP are -posted to zcash mailing lists. Dates should be in yyyy-mm-dd format, -e.g. 2001-08-14. +The Created header records the date that the ZIP was submitted. +Dates should be in yyyy-mm-dd format, e.g. 2001-08-14. Auxiliary Files -~~~~~~~~~~~~~~~ +--------------- ZIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that ZIP; that is, any ZIP that requires more than one file should be in a subdirectory named zip-XXXX. + ZIP types ========= There are several kinds of ZIP: -- A Standards Track ZIP describes any change that affects most or all - Zcash implementations, such as a change to the network protocol, a - change in block or transaction validity rules, or any change or - addition that affects the interoperability of applications using - Zcash. Standards Track ZIPs consist of two parts, a design document - and a reference implementation -- but they need only include a design - document for the initial Draft. +* A Consensus ZIP describes a change that affects the consensus protocol + followed by all Zcash implementations. -- An Informational ZIP describes a Zcash design issue, or provides - general guidelines or information to the Zcash community, but does - not propose a new feature. Informational ZIPs do not necessarily - represent a Zcash community consensus or recommendation, so users and - implementers are free to ignore Informational ZIPs or follow their - advice. +* A Standards Track ZIP describes any non-consensus change that affects + most or all Zcash implementations, such as a change to the network + protocol, or any change or addition that affects the interoperability + of applications using Zcash. -- A Process ZIP describes a process surrounding Zcash, or proposes a - change to (or an event in) a process. Process ZIPs are like Standards - Track ZIPs but apply to areas other than the Zcash protocol itself. - They may propose an implementation, but not to Zcash's codebase; they - often require community consensus; unlike Informational ZIPs, they - are more than recommendations, and users are typically not free to - ignore them. Examples include procedures, guidelines, changes to the - decision-making process, and changes to the tools or environment used - in Zcash development. +Consensus and Standards Track ZIPs consist of two parts, a design document +and a reference implementation. + +* An Informational ZIP describes Zcash design issues, or general + guidelines or information for the Zcash community, that do not fall + into either of the above categories. Informational ZIPs do not + necessarily represent a Zcash community consensus or recommendation, + so users and implementers are free to ignore Informational ZIPs or + follow their advice. + +* A Process ZIP describes a process surrounding Zcash, or proposes a + change to (or an event in) a process. Process ZIPs are like Standards + Track ZIPs but apply to areas other than the Zcash protocol itself. + They may propose an implementation, but not to Zcash's codebase; they + often require community consensus; unlike Informational ZIPs, they + are more than recommendations, and users are typically not free to + ignore them. Examples include procedures, guidelines, changes to the + decision-making process, and changes to the tools or environment used + in Zcash development. New categories may be added by consensus among the ZIP Editors. + ZIP Status Field ================ -- Draft: All initial ZIP submissions have this status. +* Draft: All initial ZIP submissions have this status. -- Withdrawn: If the Champion decides to remove the ZIP from - consideration by the community, they may set the status to Withdrawn. +* Withdrawn: If the Champion decides to remove the ZIP from + consideration by the community, they may set the status to Withdrawn. -- Active: Typically only used for Process/Informational ZIPs, achieved - once rough consensus is reached in PR/mailing list from Draft Process - ZIP. +* Active: Typically only used for Process/Informational ZIPs, achieved + once rough consensus is reached in PR/mailing list from Draft Process + ZIP. -- Proposed: Typically the stage after Draft, added to a ZIP after - consideration and feedback from the community. The ZIP Editor(s) must - validate this change before it is approved. +* Proposed: Typically the stage after Draft, added to a ZIP after + consideration and feedback from the community. The ZIP Editors must + validate this change before it is approved. -- Rejected: The status when progress hasn’t been made on the ZIP in one - year. Can revert back to Draft/Proposed if the Champion resumes work - or resolves issues preventing consensus. +* Rejected: The status when progress hasn't been made on the ZIP in one + year. Can revert back to Draft/Proposed if the Champion resumes work + or resolves issues preventing consensus. -- Final: When a Standards, Consensus, or P2P Network ZIP is both - implemented and activated on the Zcash network. +* Final: When a Consensus or Standards Track ZIP is both implemented + and activated on the Zcash network. -- Obsolete: The status when a ZIP is no longer relevant (typically when - superseded by another ZIP). +* Obsolete: The status when a ZIP is no longer relevant (typically when + superseded by another ZIP). More details on the status workflow in the section below. @@ -387,19 +399,20 @@ Draft or Withdrawn. A ZIP may only change status from Draft (or Rejected) to Proposed, when the Champion deems it is complete and there is rough consensus on the mailing list, validated by both the Zcash Company and Zcash Foundation -Editor(s). One Editor will not suffice -- there needs to consensus among -the Editors. If it's a Standards Track ZIP, upon changing status to -Proposed the Editor(s) will add the optional \*Network Upgrade\* to the -header, indicating the intent for the ZIP to be implemented in the -specified network upgrade. (All \*Network Upgrade\* schedules will be -distributed via the Zcash Ecosystem Developer list by the Editor(s).) +Editors. One Editor will not suffice -- there needs to be consensus +among the Editors. If it's a Standards Track ZIP, upon changing status to +Proposed the Editors will add the optional ``Network Upgrade`` header +to the preamble, indicating the intent for the ZIP to be implemented in +the specified network upgrade. (All \*Network Upgrade\* schedules will be +distributed via the Zcash Ecosystem Developer list by the Editors.) A Standards Track ZIP may only change status from Proposed to Implemented once the Champion provides an associated reference -implementation, typically in the period after the \*Network Upgrade\*'s -specification freeze but before the implementation audit. If they miss -this deadline, the Editor(s) or Champion(s) may choose to either update -the intended \*Network Upgrade Version\* at their discretion. +implementation, typically in the period after the network upgrade's +specification freeze but before the implementation audit. If the Champion +misses this deadline, the Editors or Champion(s) may choose to update +the ``Network Upgrade`` header to target another upgrade, at their +discretion. ZIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in @@ -408,8 +421,8 @@ provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. -A Standards, Consensus, or P2P Network ZIP becomes Final when its -associated Network Upgrade is activated on Zcash's mainnet. +A Consensus or Standards Track ZIP becomes Final when its associated +network upgrade or other protocol change is activated on Zcash's mainnet. A Process or Informational ZIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is @@ -426,6 +439,7 @@ and/or discussed. Final ZIPs may be updated; the specification is still in force but modified by another specified ZIP or ZIPs (check the optional Updated-by header). + ZIP Comments ============ @@ -433,115 +447,83 @@ Comments from the community on the ZIP should occur on the Zcash Ecosystem Developer list and the comment fields of the pull requests in any open ZIPs. Editors will use these sources to judge rough consensus. + ZIP licensing ============= -Specification -------------- +New ZIPs may be accepted with the following licenses. Each new ZIP MUST +identify at least one acceptable license in its preamble. Each license +MUST be referenced by their respective abbreviation given below. -New ZIPs may be accepted with the following licenses. Each new ZIP must -identify at least one acceptable license in its preamble. The License -header in the preamble must be placed after the Created header. Each -license must be referenced by their respective abbreviation given below. +For example, a preamble might include the following License header:: -For example, a preamble might include the following License header: - -| ``   License: BSD-2-Clause`` -| ``   GNU-All-Permissive`` + License: BSD-2-Clause +    GNU-All-Permissive In this case, the ZIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with -the terms of \*either\* license. In other words, the license list is an -“OR choice”, not an “AND also” requirement. +the terms of *either* license. In other words, the license list is an +"OR choice", not an "AND also" requirement. It is also possible to license source code differently from the ZIP -text. A optional License-Code header is placed after the License header. -Again, each license must be referenced by their respective abbreviation -given below. +text. This case SHOULD be indicated in the Reference Implementation +section of the ZIP. Again, each license MUST be referenced by its +respective abbreviation given below. -For example, a preamble specifying the optional License-Code header -might look like: +Statements of code licenses in ZIPs are only advisory; anyone intending +to use the code should look for license statements in the code itself. -| ``   License: BSD-2-Clause`` -| ``   GNU-All-Permissive`` -| ``   License-Code: GPL-2.0+`` +ZIPs are not required to be *exclusively* licensed under approved +terms, and MAY also be licensed under unacceptable licenses +*in addition to* at least one acceptable license. In this case, only the +acceptable license(s) should be listed in the License header. -In this case, the code in the ZIP is not available under the BSD or -All-Permissive licenses, but only under the terms of the GNU General -Public License (GPL), version 2 or newer. If the code were to be -available under \*only\* version 2 exactly, the “+” symbol should be -removed from the license abbreviation. For a later version (eg, GPL -3.0), you would increase the version number (and retain or remove the -“+” depending on intent). - -| ``   License-Code: GPL-2.0   # This refers to GPL v2.0 *only*, no later license versions are acceptable.`` -| ``   License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.`` -| ``   License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.`` -| ``   License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.`` - -In the event that the licensing for the text or code is too complicated -to express with a simple list of alternatives, the list should instead -be replaced with the single term “Complex”. In all cases, details of the -licensing terms must be provided in the Copyright section of the ZIP. - -ZIPs are not required to be \*exclusively\* licensed under approved -terms, and may also be licensed under unacceptable licenses \*in -addition to\* at least one acceptable license. In this case, only the -acceptable license(s) should be listed in the License and License-Code -headers. Recommended licenses -~~~~~~~~~~~~~~~~~~~~ +-------------------- -- MIT: `Expat/MIT/X11 license `__ -- BSD-2-Clause: `OSI-approved BSD 2-clause - license `__ -- BSD-3-Clause: `OSI-approved BSD 3-clause - license `__ -- CC0-1.0: `Creative Commons CC0 1.0 - Universal `__ -- GNU-All-Permissive: `GNU All-Permissive - License `__ -- Apache-2.0: `Apache License, version - 2.0 `__ +* MIT: `Expat/MIT/X11 license `__ +* BSD-2-Clause: `OSI-approved BSD 2-clause + license `__ +* BSD-3-Clause: `OSI-approved BSD 3-clause + license `__ +* CC0-1.0: `Creative Commons CC0 1.0 + Universal `__ +* GNU-All-Permissive: `GNU All-Permissive + License `__ +* Apache-2.0: `Apache License, version + 2.0 `__ -In addition, it is recommended that literal code included in the ZIP be +In addition, it is RECOMMENDED that literal code included in the ZIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for zcashd would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ZIP text. Not recommended, but acceptable licenses -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +---------------------------------------- -- BSL-1.0: `Boost Software License, version - 1.0 `__ -- CC-BY-4.0: `Creative Commons Attribution 4.0 - International `__ -- CC-BY-SA-4.0: `Creative Commons Attribution-ShareAlike 4.0 - International `__ -- AGPL-3.0+: `GNU Affero General Public License (AGPL), version 3 or - newer `__ -- FDL-1.3: `GNU Free Documentation License, version - 1.3 `__ -- GPL-2.0+: `GNU General Public License (GPL), version 2 or - newer `__ -- LGPL-2.1+: `GNU Lesser General Public License (LGPL), version 2.1 or - newer `__ +* BSL-1.0: `Boost Software License, version + 1.0 `__ +* CC-BY-4.0: `Creative Commons Attribution 4.0 + International `__ +* CC-BY-SA-4.0: `Creative Commons Attribution-ShareAlike 4.0 + International `__ +* AGPL-3.0+: `GNU Affero General Public License (AGPL), version 3 or + newer `__ +* FDL-1.3: `GNU Free Documentation License, version + 1.3 `__ +* GPL-2.0+: `GNU General Public License (GPL), version 2 or + newer `__ +* LGPL-2.1+: `GNU Lesser General Public License (LGPL), version 2.1 or + newer `__ Not acceptable licenses -~~~~~~~~~~~~~~~~~~~~~~~ +----------------------- All licenses not explicitly included in the above lists are not -acceptable terms for a Zcash Improvement Proposal unless a later ZIP -extends this one to add them. However, ZIPs predating the acceptance of -this ZIP were allowed under other terms, and should use these -abbreviation when no other license is granted: - -- OPL: `Open Publication License, version - 1.0 `__ -- PD: Released into the public domain +acceptable terms for a Zcash Improvement Proposal. Rationale --------- @@ -549,34 +531,39 @@ Rationale Bitcoin's BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient? -- The OPL is generally regarded as obsolete, and not a license suitable - for new publications. -- Many are unfamiliar with the OPL terms, and may just prefer to use - the public domain rather than license under uncertain terms. -- The OPL license terms allowed for the author to prevent publication - and derived works, which was widely considered inappropriate. -- Public domain is not universally recognised as a legitimate action, - thus it is inadvisable. +* The OPL is generally regarded as obsolete, and not a license suitable + for new publications. +* The OPL license terms allowed for the author to prevent publication + and derived works, which was widely considered inappropriate. +* In some jurisdictions, releasing a work to the public domain is not + recognised as a legitimate legal action, leaving the ZIP simply + copyrighted with no redistribution or modification allowed at all. Why are there software licenses included? -- Some ZIPs, especially consensus layer, may include literal code in - the ZIP itself which may not be available under the exact license - terms of the ZIP. -- Despite this, not all software licenses would be acceptable for - content included in ZIPs. +* Some ZIPs, especially in the Consensus category, may include literal + code in the ZIP itself which may not be available under the exact + license terms of the ZIP. +* Despite this, not all software licenses would be acceptable for + content included in ZIPs. -Why is Public Domain no longer acceptable for new ZIPs? - -- In some jurisdictions, public domain is not recognised as a - legitimate legal action, leaving the ZIP simply copyrighted with no - redistribution or modification allowed at all. See Also ======== -- `The GNU Kind Communication - Guidelines `__ -- `RFC 7282: On Consensus and Humming in the - IETF `__ -- `Zcash Network Upgrade Pipeline `__ +* `The GNU Kind Communication + Guidelines `__ +* `RFC 7282: On Consensus and Humming in the + IETF `__ +* `Zcash Network Upgrade Pipeline `__ + + +References +========== + +.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ +.. [#conduct] `Zcash Code of Conduct `_ +.. [#rst] `reStructuredText documentation `_ +.. [#latex] `LaTeX -- a document preparation system `_ + From 998047b3501ddd19d6c31d96692c5c508ae321da Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 02:29:12 +0000 Subject: [PATCH 03/10] adds security and privacy considerations section Co-authored-by: Josh Cincinnati --- zip-0000.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/zip-0000.rst b/zip-0000.rst index 7488cbd6..354826d6 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -270,6 +270,12 @@ Each ZIP SHOULD have the following parts: consensus within the community and discuss important objections or concerns raised during discussion. +* Security and privacy considerations -- If applicable, security + and privacy considerations should be explicitly described, particularly + if the ZIP makes explicit trade-offs or assumptions. For guidance on + this section consider `RFC 3552 `__. + as a starting point. + * Reference implementation -- The reference implementation must be completed before any ZIP is given status “Implemented”, but it generally need not be completed before the ZIP is accepted into From 331e487a2b6e5110fbd10f61ff940bfdef90e882 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 02:34:22 +0000 Subject: [PATCH 04/10] adds implementation description Co-authored-by: Josh Cincinnati --- zip-0000.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/zip-0000.rst b/zip-0000.rst index 354826d6..380c4996 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -388,6 +388,9 @@ ZIP Status Field year. Can revert back to Draft/Proposed if the Champion resumes work or resolves issues preventing consensus. +* Implemented: When a Consensus or Standards Track ZIP has a working + reference implementation but before activation on the Zcash network. + * Final: When a Consensus or Standards Track ZIP is both implemented and activated on the Zcash network. From 7c9bbc7a36760a085f3c60ee7dca27271f69d7cc Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 02:41:33 +0000 Subject: [PATCH 05/10] Zcash Company -> Electric Coin Company. Co-authored-by: str4d Co-authored-by: Josh Cincinnati --- zip-0000.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index 380c4996..8e81e48e 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -136,11 +136,11 @@ such decisions can't be reversed :). ZIP Editors ----------- -The current ZIP Editors are Daira Hopwood, representing the Zcash +The current ZIP Editors are Daira Hopwood, representing the Electric Coin Company, and Josh Cincinnati, representing the Zcash Foundation. Both can be reached at zips@z.cash . The current design of the ZIP Process dictates that there are always at least two ZIP Editors: one from the -Zcash Company and one from the Zcash Foundation. Additional Editors may +Electric Coin Company and one from the Zcash Foundation. Additional Editors may be selected by consensus among the current Editors. @@ -407,7 +407,7 @@ Draft or Withdrawn. A ZIP may only change status from Draft (or Rejected) to Proposed, when the Champion deems it is complete and there is rough consensus on the -mailing list, validated by both the Zcash Company and Zcash Foundation +mailing list, validated by both the Electric Coin Company and Zcash Foundation Editors. One Editor will not suffice -- there needs to be consensus among the Editors. If it's a Standards Track ZIP, upon changing status to Proposed the Editors will add the optional ``Network Upgrade`` header From ee74933826bf6a43960a985e4575b52ce185e2e3 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 02:43:48 +0000 Subject: [PATCH 06/10] Fix references. Co-authored-by: str4d Co-authored-by: Josh Cincinnati --- zip-0000.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index 8e81e48e..36f03a2d 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -244,9 +244,9 @@ PDF version of the document. Each ZIP SHOULD have the following parts: * Preamble -- Headers containing metadata about the ZIP (`see - below <#ZIP_header_preamble>`__). + below <#zip-header-preamble>`__). The License field of the preamble indicates the licensing terms, - which MUST be acceptable according to <#ZIP_licensing>`__. + which MUST be acceptable according to `the ZIP licensing requirements <#zip-licensing>`__. * Terminology -- Definitions of technical or non-obvious terms used in the document. From 0105afc51f63efdd049e6d4f204b024afc05a39c Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 02:49:37 +0000 Subject: [PATCH 07/10] Minor updates. Co-authored-by: str4d Co-authored-by: Josh Cincinnati --- zip-0000.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index 36f03a2d..cac7dc3b 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -276,7 +276,9 @@ Each ZIP SHOULD have the following parts: this section consider `RFC 3552 `__. as a starting point. -* Reference implementation -- The reference implementation must be +* Reference implementation -- Literal code implementing the ZIP's + specification, and/or a link to the reference implementation of + the ZIP's specification. The reference implementation must be completed before any ZIP is given status “Implemented”, but it generally need not be completed before the ZIP is accepted into Proposed. @@ -345,7 +347,7 @@ There are several kinds of ZIP: protocol, or any change or addition that affects the interoperability of applications using Zcash. -Consensus and Standards Track ZIPs consist of two parts, a design document +Consensus and Standards Track ZIPs consist of two parts: a design document and a reference implementation. * An Informational ZIP describes Zcash design issues, or general @@ -381,7 +383,7 @@ ZIP Status Field ZIP. * Proposed: Typically the stage after Draft, added to a ZIP after - consideration and feedback from the community. The ZIP Editors must + consideration, feedback, and rough consensus from the community. The ZIP Editors must validate this change before it is approved. * Rejected: The status when progress hasn't been made on the ZIP in one @@ -412,7 +414,7 @@ Editors. One Editor will not suffice -- there needs to be consensus among the Editors. If it's a Standards Track ZIP, upon changing status to Proposed the Editors will add the optional ``Network Upgrade`` header to the preamble, indicating the intent for the ZIP to be implemented in -the specified network upgrade. (All \*Network Upgrade\* schedules will be +the specified network upgrade. (All ``Network Upgrade`` schedules will be distributed via the Zcash Ecosystem Developer list by the Editors.) A Standards Track ZIP may only change status from Proposed to From d22670e43a97f851ec103c223af151926f35de7e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 02:55:15 +0000 Subject: [PATCH 08/10] moves motivation section and adds auxilary file clarity Co-authored-by: Josh Cincinnati --- zip-0000.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index cac7dc3b..96f948ec 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -254,15 +254,15 @@ Each ZIP SHOULD have the following parts: * Abstract -- A short (~200 word) description of the technical issue being addressed. +* Motivation -- The motivation is critical for ZIPs that want to change + the Zcash protocol. It should clearly explain why the existing + protocol is inadequate to address the problem that the ZIP solves. + * Specification -- The technical specification should describe the interface and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Zcash platforms. -* Motivation -- The motivation is critical for ZIPs that want to change - the Zcash protocol. It should clearly explain why the existing - protocol is inadequate to address the problem that the ZIP solves. - * Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were @@ -330,8 +330,9 @@ Auxiliary Files --------------- ZIPs may include auxiliary files such as diagrams. Auxiliary files -should be included in a subdirectory for that ZIP; that is, any ZIP that -requires more than one file should be in a subdirectory named zip-XXXX. +should be included in a subdirectory for that ZIP; that is, for any ZIP +that requires more than one file, all of the files SHOULD be in a +subdirectory named zip-XXXX. ZIP types From f61e720c02ccfe8a79a38fc8406b765a39c5fb3f Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 20 Mar 2019 03:02:47 +0000 Subject: [PATCH 09/10] s/Champion/Owner/g Co-authored-by: Josh Cincinnati --- zip-0000.rst | 79 ++++++++++++++++++++++++++-------------------------- 1 file changed, 39 insertions(+), 40 deletions(-) diff --git a/zip-0000.rst b/zip-0000.rst index 96f948ec..37e61b0e 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -2,8 +2,8 @@ ZIP: 0 Title: ZIP Process - Champions: Daira Hopwood - Josh Cincinnati + Owners: Daira Hopwood + Josh Cincinnati Status: Draft Type: Process Created: 2019-02-16 @@ -32,7 +32,7 @@ technical specification of the feature and a rationale for the feature. We intend ZIPs to be the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Zcash. The author(s) of the ZIP -(known as Champions in this document) are responsible for building +(known as Owners in this document) are responsible for building consensus within the community and documenting dissenting opinions. Because the ZIPs are maintained as text files in a versioned repository, @@ -47,10 +47,10 @@ ZIP Workflow ============ The ZIP process begins with a new idea for Zcash. Each potential ZIP -must have a Champion -- someone who writes the ZIP using the style and +must have a Owner -- someone who writes the ZIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The -ZIP Champion (a.k.a. author) should first attempt to ascertain whether +ZIP Owner (a.k.a. author) should first attempt to ascertain whether the idea is ZIP-able. Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a ZIP and should be injected into the @@ -64,29 +64,29 @@ by posting about the new idea to the `Zcash Ecosystem Development list `__. Vetting an idea publicly before going as far as writing a ZIP is meant -to save both the potential Champion and the wider community time. Asking +to save both the potential Owner and the wider community time. Asking the Zcash community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire -community and not just the Champion. Just because an idea sounds good to -the Champion does not mean it will work for most people in most areas +community and not just the Owner. Just because an idea sounds good to +the Owner does not mean it will work for most people in most areas where Zcash is used. -Once the Champion has asked the Zcash community as to whether an idea +Once the Owner has asked the Zcash community as to whether an idea has any chance of acceptance, a draft ZIP should be presented to the `Zcash Ecosystem Development list `__. -This gives the Champion a chance to flesh out the draft ZIP to make it +This gives the Owner a chance to flesh out the draft ZIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the `ZIPs git repository `__ as a pull request. This draft must be written in ZIP style as described below, and named with an alias such as ``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned -it a ZIP number (Champions MUST NOT self-assign ZIP numbers). +it a ZIP number (Owners MUST NOT self-assign ZIP numbers). -ZIP Champions are responsible for collecting community feedback on both +ZIP Owners are responsible for collecting community feedback on both the initial idea and the ZIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. @@ -107,8 +107,8 @@ complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. -The ZIP Champion may update the draft as necessary in the git -repository. Updates to drafts should also be submitted by the Champion +The ZIP Owner may update the draft as necessary in the git +repository. Updates to drafts should also be submitted by the Owner as pull requests. @@ -116,10 +116,10 @@ Transferring ZIP Ownership -------------------------- It occasionally becomes necessary to transfer ownership of ZIPs to a new -Champion. In general, we'd like to retain the original Champion as a -co-Champion of the transferred ZIP, but that's really up to the original -Champion. A good reason to transfer ownership is because the original -Champion no longer has the time or interest in updating it or following +Owner. In general, we'd like to retain the original Owner as a +co-Owner of the transferred ZIP, but that's really up to the original +Owner. A good reason to transfer ownership is because the original +Owner no longer has the time or interest in updating it or following through with the ZIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the @@ -127,8 +127,8 @@ ZIP. We try to build consensus around a ZIP, but if that's not possible, you can always submit a competing ZIP. If you are interested in assuming ownership of a ZIP, send a message -asking to take over, addressed to both the original Champion and the ZIP -Editors. If the original Champion doesn't respond to email in a timely +asking to take over, addressed to both the original Owner and the ZIP +Editors. If the original Owner doesn't respond to email in a timely manner, the ZIP Editors will make a unilateral decision (it's not like such decisions can't be reversed :). @@ -161,7 +161,7 @@ For each new ZIP that comes in an Editor confirms the following: addressed. * The licensing terms are acceptable for ZIPs. -If the ZIP isn't ready, the editor will send it back to the Champion for +If the ZIP isn't ready, the editor will send it back to the Owner for revision, with specific instructions. Once the ZIP is ready for the repository it should be submitted as a @@ -210,12 +210,12 @@ for any of the following reasons: * it updates a Released ZIP to Draft when the specification is already implemented and has been in common use; * it violates any specific "MUST" or "MUST NOT" rule in this document; -* the expressed political views of a Champion of the document are inimical +* the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct [#conduct]_ (except in the case of an update - removing that Champion); -* it is not authorized by the stated ZIP Champions; -* it removes an Champion without their consent (unless the reason for removal - is directly related to a breach of the Code of Conduct by that Champion). + removing that Owner); +* it is not authorized by the stated ZIP Owners; +* it removes an Owner without their consent (unless the reason for removal + is directly related to a breach of the Code of Conduct by that Owner). The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update that does not violate any of these criteria. If they refuse a @@ -291,7 +291,7 @@ header fields are REQUIRED::  ZIP:  Title: -  Champions: +  Owners:  Status:  Category: Created: @@ -306,18 +306,17 @@ The following additional header fields are OPTIONAL:: Obsoletes: Updates: -The Champions header lists the names and email addresses of all the -champions/owners of the ZIP. The format of the Champions header value -SHOULD be:: +The Owners header lists the names and email addresses of all the +Owners of the ZIP. The format of the Owners header value SHOULD be:: Random J. User  -If there are multiple champions, each should be on a separate line. +If there are multiple Owners, each should be on a separate line. While a ZIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the ZIP is being discussed. No Discussions-To header is necessary -if the ZIP is being discussed privately with the Champion, or on the +if the ZIP is being discussed privately with the Owner, or on the Zcash email mailing lists. The Category header specifies the type of ZIP: Consensus, Standards Track, @@ -376,7 +375,7 @@ ZIP Status Field * Draft: All initial ZIP submissions have this status. -* Withdrawn: If the Champion decides to remove the ZIP from +* Withdrawn: If the Owner decides to remove the ZIP from consideration by the community, they may set the status to Withdrawn. * Active: Typically only used for Process/Informational ZIPs, achieved @@ -388,7 +387,7 @@ ZIP Status Field validate this change before it is approved. * Rejected: The status when progress hasn't been made on the ZIP in one - year. Can revert back to Draft/Proposed if the Champion resumes work + year. Can revert back to Draft/Proposed if the Owner resumes work or resolves issues preventing consensus. * Implemented: When a Consensus or Standards Track ZIP has a working @@ -405,11 +404,11 @@ More details on the status workflow in the section below. Specification ------------- -Champions of a ZIP may decide on their own to change the status between +Owners of a ZIP may decide on their own to change the status between Draft or Withdrawn. A ZIP may only change status from Draft (or Rejected) to Proposed, when -the Champion deems it is complete and there is rough consensus on the +the Owner deems it is complete and there is rough consensus on the mailing list, validated by both the Electric Coin Company and Zcash Foundation Editors. One Editor will not suffice -- there needs to be consensus among the Editors. If it's a Standards Track ZIP, upon changing status to @@ -419,16 +418,16 @@ the specified network upgrade. (All ``Network Upgrade`` schedules will be distributed via the Zcash Ecosystem Developer list by the Editors.) A Standards Track ZIP may only change status from Proposed to -Implemented once the Champion provides an associated reference +Implemented once the Owner provides an associated reference implementation, typically in the period after the network upgrade's -specification freeze but before the implementation audit. If the Champion -misses this deadline, the Editors or Champion(s) may choose to update +specification freeze but before the implementation audit. If the Owner +misses this deadline, the Editors or Owner(s) may choose to update the ``Network Upgrade`` header to target another upgrade, at their discretion. ZIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in -one year. Such a ZIP may be changed to Draft status if the Champion +one year. Such a ZIP may be changed to Draft status if the Owner provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. From f4ffdb3c60bd09393eb261b7a8a2e07dbfa5cb3b Mon Sep 17 00:00:00 2001 From: Josh Cincinnati Date: Mon, 25 Mar 2019 13:31:34 -0400 Subject: [PATCH 10/10] removes readme step for editors --- zip-0000.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/zip-0000.rst b/zip-0000.rst index 37e61b0e..fc984c96 100644 --- a/zip-0000.rst +++ b/zip-0000.rst @@ -172,7 +172,6 @@ The ZIP Editors will: * Assign a ZIP number in the pull request. * Merge the pull request when it is ready. -* List the ZIP in `README.rst `__ The ZIP editors monitor ZIP changes and update ZIP headers as appropriate.