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..fc984c96 --- /dev/null +++ b/zip-0000.rst @@ -0,0 +1,579 @@ +:: + + ZIP: 0 + Title: ZIP Process + Owners: 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 +======== + +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 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 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, +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 `__. + + +ZIP Workflow +============ + +The ZIP process begins with a new idea for Zcash. Each potential ZIP +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 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 +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 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 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 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 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 (Owners MUST NOT self-assign ZIP numbers). + +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. + +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 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 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 +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 Owner may update the draft as necessary in the git +repository. Updates to drafts should also be submitted by the Owner +as pull requests. + + +Transferring ZIP Ownership +-------------------------- + +It occasionally becomes necessary to transfer ownership of ZIPs to a new +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 +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 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 :). + + +ZIP Editors +----------- + +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 +Electric Coin 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 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 Owner 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. + +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 [#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 Owner of the document are inimical + to the Zcash Code of Conduct [#conduct]_ (except in the case of an update + 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 +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 [#conduct]_ +and follow `the GNU Kind Communication +Guidelines `__ + + +ZIP format and structure +======================== + +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. + +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 `the ZIP licensing requirements <#zip-licensing>`__. + +* Terminology -- Definitions of technical or non-obvious terms used + in the document. + +* 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. + +* 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. + +* 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 -- 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. + +ZIP header preamble +------------------- + +Each ZIP must begin with an RFC 822-style header preamble. The following +header fields are REQUIRED:: + +  ZIP: +  Title: +  Owners: +  Status: +  Category: + Created: +  License: + +The following additional header fields are OPTIONAL:: + +  Discussions-To: +  Network Upgrade: + Obsoleted by: + Updated by: + Obsoletes: + Updates: + +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 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 Owner, or on the +Zcash email mailing lists. + +The Category header specifies the type of ZIP: Consensus, Standards Track, +Informational, or Process. + +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, for any ZIP +that requires more than one file, all of the files SHOULD be in a +subdirectory named zip-XXXX. + + +ZIP types +========= + +There are several kinds of ZIP: + +* A Consensus ZIP describes a change that affects the consensus protocol + followed by all Zcash implementations. + +* 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. + +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. + +* 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 + 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, 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 + 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 + 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. + +* 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 +------------- + +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 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 +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 Owner provides an associated reference +implementation, typically in the period after the network upgrade's +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 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. + +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 +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 +============= + +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. + +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. 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. + +Statements of code licenses in ZIPs are only advisory; anyone intending +to use the code should look for license statements in the code itself. + +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. + + +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. + +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. +* 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 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. + + +See Also +======== + +* `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 `_ +