mirror of https://github.com/zcash/zips.git
Regenerate all HTML using Docutils 0.19.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
954467c15d
commit
25610fc5c7
|
|
@ -19,8 +19,8 @@ Category: Process
|
|||
Created: 2019-02-16
|
||||
License: BSD-2-Clause</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>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.</p>
|
||||
|
|
@ -75,7 +75,7 @@ License: BSD-2-Clause</pre>
|
|||
<p>The ZIP editors monitor ZIP changes and update ZIP headers as appropriate.</p>
|
||||
<p>The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons:</p>
|
||||
<ul>
|
||||
<li>it violates the Zcash Code of Conduct <a id="id3" class="footnote_reference" href="#conduct">4</a> ;</li>
|
||||
<li>it violates the Zcash Code of Conduct <a id="footnote-reference-3" class="footnote_reference" href="#conduct">4</a> ;</li>
|
||||
<li>it appears too unfocused or broad;</li>
|
||||
<li>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);</li>
|
||||
<li>it has manifest security flaws (including being unrealistically dependent on user vigilance to avoid security weaknesses);</li>
|
||||
|
|
@ -93,17 +93,17 @@ License: BSD-2-Clause</pre>
|
|||
<li>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;</li>
|
||||
<li>it updates a Released ZIP to Draft when the specification is already implemented and has been in common use;</li>
|
||||
<li>it violates any specific "MUST" or "MUST NOT" rule in this document;</li>
|
||||
<li>the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct <a id="id4" class="footnote_reference" href="#conduct">4</a> (except in the case of an update removing that Owner);</li>
|
||||
<li>the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct <a id="footnote-reference-4" class="footnote_reference" href="#conduct">4</a> (except in the case of an update removing that Owner);</li>
|
||||
<li>it is not authorized by the stated ZIP Owners;</li>
|
||||
<li>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).</li>
|
||||
</ul>
|
||||
<p>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.</p>
|
||||
<p>Note that it is not the primary responsibility of the ZIP Editors to review proposals for security, correctness, or implementability.</p>
|
||||
<p>Please send all ZIP-related communications either by email to <<a href="mailto:zips@z.cash">zips@z.cash</a>>, or by opening an issue on the <a href="https://github.com/zcash/zips/issues">ZIPs issue tracker</a>. All communications should abide by the Zcash Code of Conduct <a id="id5" class="footnote_reference" href="#conduct">4</a> and follow <a href="https://www.gnu.org/philosophy/kind-communication.en.html">the GNU Kind Communication Guidelines</a></p>
|
||||
<p>Please send all ZIP-related communications either by email to <<a href="mailto:zips@z.cash">zips@z.cash</a>>, or by opening an issue on the <a href="https://github.com/zcash/zips/issues">ZIPs issue tracker</a>. All communications should abide by the Zcash Code of Conduct <a id="footnote-reference-5" class="footnote_reference" href="#conduct">4</a> and follow <a href="https://www.gnu.org/philosophy/kind-communication.en.html">the GNU Kind Communication Guidelines</a></p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="zip-format-and-structure"><h2><span class="section-heading">ZIP format and structure</span><span class="section-anchor"> <a rel="bookmark" href="#zip-format-and-structure"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>ZIPs SHOULD be written in reStructuredText <a id="id6" class="footnote_reference" href="#rst">5</a>, Markdown <a id="id7" class="footnote_reference" href="#markdown">6</a>, or LaTeX <a id="id8" class="footnote_reference" href="#latex">7</a>. For ZIPs written in LaTeX, a <code>Makefile</code> MUST be provided to build (at least) a PDF version of the document.</p>
|
||||
<p>ZIPs SHOULD be written in reStructuredText <a id="footnote-reference-6" class="footnote_reference" href="#rst">5</a>, Markdown <a id="footnote-reference-7" class="footnote_reference" href="#markdown">6</a>, or LaTeX <a id="footnote-reference-8" class="footnote_reference" href="#latex">7</a>. For ZIPs written in LaTeX, a <code>Makefile</code> MUST be provided to build (at least) a PDF version of the document.</p>
|
||||
<p>Each ZIP SHOULD have the following parts:</p>
|
||||
<ul>
|
||||
<li>Preamble — Headers containing metadata about the ZIP (<a href="#zip-header-preamble">see below</a>). The License field of the preamble indicates the licensing terms, which MUST be acceptable according to <a href="#zip-licensing">the ZIP licensing requirements</a>.</li>
|
||||
|
|
@ -112,7 +112,7 @@ License: BSD-2-Clause</pre>
|
|||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>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 <a id="id9" class="footnote_reference" href="#rfc3552">2</a> as a starting point.</li>
|
||||
<li>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 <a id="footnote-reference-9" class="footnote_reference" href="#rfc3552">2</a> as a starting point.</li>
|
||||
<li>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” or “Final”, but it generally need not be completed before the ZIP is accepted into “Proposed”.</li>
|
||||
</ul>
|
||||
<section id="zip-header-preamble"><h3><span class="section-heading">ZIP header preamble</span><span class="section-anchor"> <a rel="bookmark" href="#zip-header-preamble"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
|
|||
|
|
@ -25,34 +25,34 @@ License: MIT</pre>
|
|||
<span class="math">\(% This ZIP makes heavy use of mathematical markup. If you can see this, you may want to instead view the rendered version at https://zips.z.cash/zip-0032 .\)</span>
|
||||
</p>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#protocol-jubjub">15</a>.</p>
|
||||
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>"Jubjub" refers to the elliptic curve defined in <a id="footnote-reference-2" class="footnote_reference" href="#protocol-jubjub">15</a>.</p>
|
||||
<p>A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">10</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">10</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id4" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
|
||||
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="footnote-reference-4" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
|
||||
<p>The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed, for the following shielded pools (which have different internal key structures):</p>
|
||||
<ul>
|
||||
<li>Sapling</li>
|
||||
<li>Orchard</li>
|
||||
</ul>
|
||||
<p>Previous versions of this document also defined a similar derivation system for the Sprout shielded pool. This has been removed since it was never used, and is unlikely to be used given that <cite>zcashd</cite> no longer generates Sprout addresses (and neither <cite>Zebra</cite> nor the mobile SDKs have ever done so).</p>
|
||||
<p>The last part shows how to use these trees in the context of existing BIP 44 <a id="id5" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
|
||||
<p>The last part shows how to use these trees in the context of existing BIP 44 <a id="footnote-reference-5" class="footnote_reference" href="#bip-0044">5</a> wallets.</p>
|
||||
<p>This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses notwithstanding).</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>BIP 32 <a id="id6" class="footnote_reference" href="#bip-0032">2</a> is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses <a id="id7" class="footnote_reference" href="#slip-0044">6</a>) generate keys and addresses deterministically. This has several advantages over random generation:</p>
|
||||
<p>BIP 32 <a id="footnote-reference-6" class="footnote_reference" href="#bip-0032">2</a> is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses <a id="footnote-reference-7" class="footnote_reference" href="#slip-0044">6</a>) generate keys and addresses deterministically. This has several advantages over random generation:</p>
|
||||
<ul>
|
||||
<li>Wallets only need to store a single seed (particularly useful for hardware wallets).</li>
|
||||
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
|
||||
<li>A one-time backup of the seed (usually stored as a word phrase <a id="footnote-reference-8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
|
||||
<li>Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.</li>
|
||||
<li>Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.</li>
|
||||
</ul>
|
||||
<p>At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.</p>
|
||||
</section>
|
||||
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification <a id="id9" class="footnote_reference" href="#protocol">9</a>. They are reproduced here for convenience:</p>
|
||||
<p>Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification <a id="footnote-reference-9" class="footnote_reference" href="#protocol">9</a>. They are reproduced here for convenience:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{truncate}_k(S)\)</span>
|
||||
|
|
@ -104,7 +104,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
|
||||
is the representation of the Jubjub elliptic curve point
|
||||
<span class="math">\(P\)</span>
|
||||
as a bit sequence, defined in <a id="id10" class="footnote_reference" href="#protocol-jubjub">15</a>.</li>
|
||||
as a bit sequence, defined in <a id="footnote-reference-10" class="footnote_reference" href="#protocol-jubjub">15</a>.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span>
|
||||
refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
|
||||
|
|
@ -144,9 +144,9 @@ License: MIT</pre>
|
|||
<span class="math">\(d\)</span>
|
||||
to a base point on the Jubjub elliptic curve, or to
|
||||
<span class="math">\(\bot\)</span>
|
||||
if the diversifier is invalid. It is instantiated in <a id="id11" class="footnote_reference" href="#protocol-concretediversifyhash">13</a>.</li>
|
||||
if the diversifier is invalid. It is instantiated in <a id="footnote-reference-11" class="footnote_reference" href="#protocol-concretediversifyhash">13</a>.</li>
|
||||
</ul>
|
||||
<p>The following algorithm standardized in <a id="id12" class="footnote_reference" href="#nist-sp-800-38g">22</a> is used:</p>
|
||||
<p>The following algorithm standardized in <a id="footnote-reference-12" class="footnote_reference" href="#nist-sp-800-38g">22</a> is used:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\)</span>
|
||||
|
|
@ -181,11 +181,11 @@ License: MIT</pre>
|
|||
.</li>
|
||||
</ul>
|
||||
<p>Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.</p>
|
||||
<p>We adapt the path notation of BIP 32 <a id="id13" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
|
||||
<p>We adapt the path notation of BIP 32 <a id="footnote-reference-13" class="footnote_reference" href="#bip-0032">2</a> to describe shielded HD paths, using prime marks (
|
||||
<span class="math">\('\)</span>
|
||||
) to indicate hardened derivation (
|
||||
<span class="math">\(i' = i + 2^{31}\)</span>
|
||||
) as in BIP 44 <a id="id14" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
) as in BIP 44 <a id="footnote-reference-14" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)\)</span>
|
||||
|
|
@ -269,7 +269,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{nsk}_m\)</span>
|
||||
, and
|
||||
<span class="math">\(\mathsf{ovk}_m\)</span>
|
||||
via the standard Sapling derivation <a id="id15" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>:
|
||||
via the standard Sapling derivation <a id="footnote-reference-15" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>:
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{ask}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)</span>
|
||||
|
|
@ -303,7 +303,7 @@ License: MIT</pre>
|
|||
<span class="math">\(0\)</span>
|
||||
, or if the corresponding
|
||||
<span class="math">\(\mathsf{ivk}\)</span>
|
||||
derived as specified in <a id="id16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
derived as specified in <a id="footnote-reference-16" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
|
|
@ -334,7 +334,7 @@ License: MIT</pre>
|
|||
<span class="math">\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)</span>
|
||||
is the full viewing key derived from
|
||||
<span class="math">\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)</span>
|
||||
as described in <a id="id17" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
|
||||
as described in <a id="footnote-reference-17" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Split
|
||||
|
|
@ -378,16 +378,16 @@ License: MIT</pre>
|
|||
<span class="math">\(0\)</span>
|
||||
, or if the corresponding
|
||||
<span class="math">\(\mathsf{ivk}\)</span>
|
||||
derived as specified in <a id="id18" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
derived as specified in <a id="footnote-reference-18" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="deriving-a-child-extended-full-viewing-key"><h4><span class="section-heading">Deriving a child extended full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-child-extended-full-viewing-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Let
|
||||
<span class="math">\(\mathcal{G}^\mathsf{Sapling}\)</span>
|
||||
be as defined in <a id="id19" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
|
||||
be as defined in <a id="footnote-reference-19" class="footnote_reference" href="#protocol-concretespendauthsig">14</a> and let
|
||||
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
|
||||
be as defined in <a id="id20" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
|
||||
be as defined in <a id="footnote-reference-20" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
|
||||
<p>
|
||||
<span class="math">\(\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\)</span>
|
||||
<span class="math">\(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\)</span>
|
||||
|
|
@ -444,13 +444,13 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{ak}_i\)</span>
|
||||
is the zero point of Jubjub, or if the corresponding
|
||||
<span class="math">\(\mathsf{ivk}\)</span>
|
||||
derived as specified in <a id="id21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
derived as specified in <a id="footnote-reference-21" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="sapling-internal-key-derivation"><h3><span class="section-heading">Sapling internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="id22" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
|
||||
<p>The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree <a id="footnote-reference-22" class="footnote_reference" href="#bip-0044">5</a>, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
|
||||
<section id="deriving-a-sapling-internal-spending-key"><h4><span class="section-heading">Deriving a Sapling internal spending key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-spending-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Let
|
||||
<span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})\)</span>
|
||||
|
|
@ -460,7 +460,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{ak}\)</span>
|
||||
and
|
||||
<span class="math">\(\mathsf{nk}\)</span>
|
||||
as specified in <a id="id23" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
|
||||
as specified in <a id="footnote-reference-23" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</li>
|
||||
<li>Let
|
||||
<span class="math">\(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\)</span>
|
||||
.</li>
|
||||
|
|
@ -488,14 +488,14 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{ak}\)</span>
|
||||
is the zero point of Jubjub, or if the corresponding
|
||||
<span class="math">\(\mathsf{ivk}\)</span>
|
||||
derived as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
derived as specified in <a id="footnote-reference-24" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="deriving-a-sapling-internal-full-viewing-key"><h4><span class="section-heading">Deriving a Sapling internal full viewing key</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-sapling-internal-full-viewing-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Let
|
||||
<span class="math">\(\mathcal{H}^\mathsf{Sapling}\)</span>
|
||||
be as defined in <a id="id25" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
|
||||
be as defined in <a id="footnote-reference-25" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a>.</p>
|
||||
<p>Let
|
||||
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
|
||||
be the external full viewing key.</p>
|
||||
|
|
@ -534,16 +534,16 @@ License: MIT</pre>
|
|||
<span class="math">\(R\)</span>
|
||||
are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:</p>
|
||||
<figure class="align-center" align="center">
|
||||
<img width="900px" src="zip-0032-sapling-internal-key-derivation.png" />
|
||||
<img width="900" src="zip-0032-sapling-internal-key-derivation.png" alt="" />
|
||||
<figcaption>Diagram of Sapling internal key derivation</figcaption>
|
||||
</figure>
|
||||
<p>(For simplicity, the proof authorizing key is not shown.)</p>
|
||||
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id26" class="footnote_reference" href="#zip-0316">8</a>.</p>
|
||||
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="footnote-reference-26" class="footnote_reference" href="#zip-0316">8</a>.</p>
|
||||
<p>Note that the internal extended key is invalid if
|
||||
<span class="math">\(\mathsf{ak}\)</span>
|
||||
is the zero point of Jubjub, or if the corresponding
|
||||
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
|
||||
derived from the internal full viewing key as specified in <a id="id27" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
derived from the internal full viewing key as specified in <a id="footnote-reference-27" class="footnote_reference" href="#protocol-saplingkeycomponents">11</a> is
|
||||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
|
|
@ -655,7 +655,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{c}_i\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Note that the resulting child spending key may produce an invalid external FVK, as specified in <a id="id28" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.</p>
|
||||
<p>Note that the resulting child spending key may produce an invalid external FVK, as specified in <a id="footnote-reference-28" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.</p>
|
||||
</section>
|
||||
<section id="orchard-internal-key-derivation"><h3><span class="section-heading">Orchard internal key derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-internal-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As in the case of Sapling, for a given external address, we want to produce another address for use by wallets for internal operations such as change and auto-shielding. That is, for any external full viewing key we need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.</p>
|
||||
|
|
@ -663,7 +663,7 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{ask}\)</span>
|
||||
be the spend authorizing key if available, and let
|
||||
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
|
||||
be the corresponding external full viewing key, obtained as specified in <a id="id29" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
|
||||
be the corresponding external full viewing key, obtained as specified in <a id="footnote-reference-29" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
|
||||
<p>Define
|
||||
<span class="math">\(\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
|
||||
as follows:</p>
|
||||
|
|
@ -691,13 +691,13 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{ivk_{internal}}\)</span>
|
||||
and
|
||||
<span class="math">\(\mathsf{ovk_{internal}}\)</span>
|
||||
fields being derived, as specified in <a id="id30" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
|
||||
fields being derived, as specified in <a id="footnote-reference-30" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a> and shown in the following diagram:</p>
|
||||
<figure class="align-center" align="center">
|
||||
<img width="720px" src="zip-0032-orchard-internal-key-derivation.png" />
|
||||
<img width="720" src="zip-0032-orchard-internal-key-derivation.png" alt="" />
|
||||
<figcaption>Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key</figcaption>
|
||||
</figure>
|
||||
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="id31" class="footnote_reference" href="#zip-0316">8</a>.</p>
|
||||
<p>Note that the resulting FVK may be invalid, as specified in <a id="id32" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
|
||||
<p>This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in <cite>zcashd</cite> as part of support for ZIP 316 <a id="footnote-reference-31" class="footnote_reference" href="#zip-0316">8</a>.</p>
|
||||
<p>Note that the resulting FVK may be invalid, as specified in <a id="footnote-reference-32" class="footnote_reference" href="#protocol-orchardkeycomponents">12</a>.</p>
|
||||
</section>
|
||||
<section id="orchard-diversifier-derivation"><h3><span class="section-heading">Orchard diversifier derivation</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-diversifier-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.</p>
|
||||
|
|
@ -738,7 +738,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id33" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="footnote-reference-33" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
|
||||
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
|
||||
<ul>
|
||||
|
|
@ -751,7 +751,7 @@ License: MIT</pre>
|
|||
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
|
||||
<li>
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id34" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
|
||||
: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="footnote-reference-34" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
index
|
||||
<span class="math">\(1\)</span>
|
||||
|
|
@ -760,7 +760,7 @@ License: MIT</pre>
|
|||
<span class="math">\(account\)</span>
|
||||
: numbered from index
|
||||
<span class="math">\(0\)</span>
|
||||
in sequentially increasing manner. Defined as in BIP 44 <a id="id35" class="footnote_reference" href="#bip-0044">5</a>.</li>
|
||||
in sequentially increasing manner. Defined as in BIP 44 <a id="footnote-reference-35" class="footnote_reference" href="#bip-0044">5</a>.</li>
|
||||
</ul>
|
||||
<p>Unlike BIP 44, none of the shielded key paths have a
|
||||
<span class="math">\(change\)</span>
|
||||
|
|
@ -782,7 +782,7 @@ License: MIT</pre>
|
|||
payment addresses, because each diversifier has around a 50% chance of being invalid.</p>
|
||||
<p>If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened
|
||||
<span class="math">\(address\_index\)</span>
|
||||
path level as in <a id="id36" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
path level as in <a id="footnote-reference-36" class="footnote_reference" href="#bip-0044">5</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
|
||||
|
|
@ -814,7 +814,7 @@ License: MIT</pre>
|
|||
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(\mathit{FVK}\)</span>
|
||||
(as specified in <a id="id37" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
|
||||
(as specified in <a id="footnote-reference-37" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">18</a>) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)</span>
|
||||
|
|
@ -826,7 +826,7 @@ License: MIT</pre>
|
|||
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
|
||||
<span class="math">\(\mathit{FVK}\)</span>
|
||||
(as specified in <a id="id38" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
|
||||
(as specified in <a id="footnote-reference-38" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a>) is given by:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\)</span>
|
||||
|
|
@ -851,7 +851,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a rel="bookmark" href="#specification-key-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id39" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
|
||||
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="footnote-reference-39" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
|
||||
<section id="sapling-extended-spending-keys"><h3><span class="section-heading">Sapling extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-spending-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Sapling extended spending key
|
||||
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
|
||||
|
|
@ -943,7 +943,7 @@ License: MIT</pre>
|
|||
<span class="math">\(0\)</span>
|
||||
.</p>
|
||||
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-orchard-extsk-main</code> for Mainnet, or <code>secret-orchard-extsk-test</code> for Testnet.</p>
|
||||
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id40" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
|
||||
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="footnote-reference-40" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="values-reserved-due-to-previous-specification-for-sprout"><h2><span class="section-heading">Values reserved due to previous specification for Sprout</span><span class="section-anchor"> <a rel="bookmark" href="#values-reserved-due-to-previous-specification-for-sprout"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
174
zip-0143.html
174
zip-0143.html
|
|
@ -18,19 +18,19 @@ Category: Consensus
|
|||
Created: 2017-12-27
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">10</a></p>
|
||||
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="id3" class="footnote_reference" href="#zip-0201">11</a></p>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">10</a></p>
|
||||
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="footnote-reference-3" class="footnote_reference" href="#zip-0201">11</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a new transaction digest algorithm for signature validation from the Overwinter network upgrade, in order to minimize redundant data hashing in validation, and to cover the input value by the signature.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>There are 4 ECDSA signature validation operations in the original Zcash script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> ("sigops"). According to the sighash type (<code>ALL</code>, <code>NONE</code>, or <code>SINGLE</code>, possibly modified by <code>ANYONECANPAY</code>), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <a id="id4" class="footnote_reference" href="#wiki-checksig">3</a> The transaction digest is additionally used for the JoinSplit signature (solely with sighash type <code>ALL</code>). <a id="id5" class="footnote_reference" href="#protocol-sproutsend">2</a></p>
|
||||
<p>There are 4 ECDSA signature validation operations in the original Zcash script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> ("sigops"). According to the sighash type (<code>ALL</code>, <code>NONE</code>, or <code>SINGLE</code>, possibly modified by <code>ANYONECANPAY</code>), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <a id="footnote-reference-4" class="footnote_reference" href="#wiki-checksig">3</a> The transaction digest is additionally used for the JoinSplit signature (solely with sighash type <code>ALL</code>). <a id="footnote-reference-5" class="footnote_reference" href="#protocol-sproutsend">2</a></p>
|
||||
<p>Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:</p>
|
||||
<ul>
|
||||
<li>For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). <a id="id6" class="footnote_reference" href="#quadratic">4</a></li>
|
||||
<li>The algorithm does not involve the value being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the lack of knowledge of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of a lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funds would be lost. <a id="id7" class="footnote_reference" href="#offline-wallets">5</a></li>
|
||||
<li>For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). <a id="footnote-reference-6" class="footnote_reference" href="#quadratic">4</a></li>
|
||||
<li>The algorithm does not involve the value being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the lack of knowledge of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of a lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funds would be lost. <a id="footnote-reference-7" class="footnote_reference" href="#offline-wallets">5</a></li>
|
||||
</ul>
|
||||
<p>Deploying the aforementioned fixes in the original script system is not a simple task.</p>
|
||||
</section>
|
||||
|
|
@ -52,11 +52,11 @@ License: MIT</pre>
|
|||
b. scriptCode of the input (serialized as scripts inside CTxOuts)
|
||||
c. value of the output spent by this input (8-byte little endian)
|
||||
d. nSequence of the input (4-byte little endian)</pre>
|
||||
<p>The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, <a id="id8" class="footnote_reference" href="#bip-0143">6</a> with replay protection inspired by BUIP-HF v1.2. <a id="id9" class="footnote_reference" href="#buip-hf">7</a></p>
|
||||
<p>The new algorithm MUST be used for signatures created over the Overwinter transaction format. <a id="id10" class="footnote_reference" href="#zip-0202">12</a> Combined with the new consensus rule that v1 and v2 transaction formats will be invalid from the Overwinter upgrade, <a id="id11" class="footnote_reference" href="#zip-0202">12</a> this effectively means that all transaction signatures from the Overwinter activation height will use the new algorithm. <a id="id12" class="footnote_reference" href="#zip-0201">11</a></p>
|
||||
<p>The BLAKE2b-256 personalization field <a id="id13" class="footnote_reference" href="#blake2-personalization">8</a> is set to:</p>
|
||||
<p>The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, <a id="footnote-reference-8" class="footnote_reference" href="#bip-0143">6</a> with replay protection inspired by BUIP-HF v1.2. <a id="footnote-reference-9" class="footnote_reference" href="#buip-hf">7</a></p>
|
||||
<p>The new algorithm MUST be used for signatures created over the Overwinter transaction format. <a id="footnote-reference-10" class="footnote_reference" href="#zip-0202">12</a> Combined with the new consensus rule that v1 and v2 transaction formats will be invalid from the Overwinter upgrade, <a id="footnote-reference-11" class="footnote_reference" href="#zip-0202">12</a> this effectively means that all transaction signatures from the Overwinter activation height will use the new algorithm. <a id="footnote-reference-12" class="footnote_reference" href="#zip-0201">11</a></p>
|
||||
<p>The BLAKE2b-256 personalization field <a id="footnote-reference-13" class="footnote_reference" href="#blake2-personalization">8</a> is set to:</p>
|
||||
<pre>"ZcashSigHash" || CONSENSUS_BRANCH_ID</pre>
|
||||
<p><code>CONSENSUS_BRANCH_ID</code> is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. <a id="id14" class="footnote_reference" href="#zip-0200">10</a> Domain separation of the signature hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will have invalid signatures on other consensus branches.</p>
|
||||
<p><code>CONSENSUS_BRANCH_ID</code> is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. <a id="footnote-reference-14" class="footnote_reference" href="#zip-0200">10</a> Domain separation of the signature hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will have invalid signatures on other consensus branches.</p>
|
||||
<p>Transaction creators MUST specify the epoch they want their transaction to be mined in. Across a network upgrade, this means that if a transaction is not mined before the activation height, it will never be mined.</p>
|
||||
<p>Semantics of the original sighash types remain unchanged, except the following:</p>
|
||||
<ol type="1">
|
||||
|
|
@ -65,12 +65,12 @@ License: MIT</pre>
|
|||
<li><code>SINGLE</code> does not commit to the input index. When <code>ANYONECANPAY</code> is not set, the semantics are unchanged since <code>hashPrevouts</code> and <code>outpoint</code> together implictly commit to the input index. When <code>SINGLE</code> is used with <code>ANYONECANPAY</code>, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.</li>
|
||||
</ol>
|
||||
<section id="field-definitions"><h3><span class="section-heading">Field definitions</span><span class="section-anchor"> <a rel="bookmark" href="#field-definitions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The items 7, 9, 10a, 10d have the same meaning as the original algorithm from Bitcoin. <a id="id15" class="footnote_reference" href="#wiki-checksig">3</a></p>
|
||||
<p>The items 7, 9, 10a, 10d have the same meaning as the original algorithm from Bitcoin. <a id="footnote-reference-15" class="footnote_reference" href="#wiki-checksig">3</a></p>
|
||||
<section id="header"><h4><span class="section-heading">1: <code>header</code></span><span class="section-anchor"> <a rel="bookmark" href="#header"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Deserialized into two transaction properties: <code>fOverwintered</code> and <code>nVersion</code>. For transactions that use this transaction digest algorithm, <code>fOverwintered</code> is always set. <a id="id16" class="footnote_reference" href="#zip-0202">12</a></p>
|
||||
<p>Deserialized into two transaction properties: <code>fOverwintered</code> and <code>nVersion</code>. For transactions that use this transaction digest algorithm, <code>fOverwintered</code> is always set. <a id="footnote-reference-16" class="footnote_reference" href="#zip-0202">12</a></p>
|
||||
</section>
|
||||
<section id="nversiongroupid"><h4><span class="section-heading">2: <code>nVersionGroupId</code></span><span class="section-anchor"> <a rel="bookmark" href="#nversiongroupid"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Provides domain separation of <code>nVersion</code>. It is only defined if <code>fOverwintered</code> is set, which means that it is always defined for transactions that use this algorithm. <a id="id17" class="footnote_reference" href="#zip-0202">12</a></p>
|
||||
<p>Provides domain separation of <code>nVersion</code>. It is only defined if <code>fOverwintered</code> is set, which means that it is always defined for transactions that use this algorithm. <a id="footnote-reference-17" class="footnote_reference" href="#zip-0202">12</a></p>
|
||||
</section>
|
||||
<section id="hashprevouts"><h4><span class="section-heading">3: <code>hashPrevouts</code></span><span class="section-anchor"> <a rel="bookmark" href="#hashprevouts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<ul>
|
||||
|
|
@ -101,7 +101,7 @@ License: MIT</pre>
|
|||
<li>The BLAKE2b-256 personalization field is set to <code>ZcashOutputsHash</code> in both cases above.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>. <a id="id18" class="footnote_reference" href="#change">9</a></li>
|
||||
<li>Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>. <a id="footnote-reference-18" class="footnote_reference" href="#change">9</a></li>
|
||||
</ul>
|
||||
<p>Note: the encoding of the sighash type is masked with <code>0x1F</code> when checking whether or not the <code>SINGLE</code> and <code>NONE</code> flags are set.</p>
|
||||
</section>
|
||||
|
|
@ -117,7 +117,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
<section id="nexpiryheight"><h4><span class="section-heading">8: <code>nExpiryHeight</code></span><span class="section-anchor"> <a rel="bookmark" href="#nexpiryheight"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The block height after which the transaction becomes unilaterally invalid, and can never be mined. <a id="id19" class="footnote_reference" href="#zip-0203">13</a></p>
|
||||
<p>The block height after which the transaction becomes unilaterally invalid, and can never be mined. <a id="footnote-reference-19" class="footnote_reference" href="#zip-0203">13</a></p>
|
||||
</section>
|
||||
<section id="b-scriptcode"><h4><span class="section-heading">10b: <code>scriptCode</code></span><span class="section-anchor"> <a rel="bookmark" href="#b-scriptcode"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The script being currently executed: <code>redeemScript</code> for P2SH, or <code>scriptPubKey</code> in the general case. This is the same script as serialized in the Sprout transaction digest algorithm.</p>
|
||||
|
|
@ -129,98 +129,98 @@ License: MIT</pre>
|
|||
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a rel="bookmark" href="#notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The <code>hashPrevouts</code>, <code>hashSequence</code>, <code>hashOutputs</code>, and <code>hashJoinSplits</code> calculated in an earlier validation can be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n).</p>
|
||||
<p>Refer to the reference implementation, reproduced below, for the precise algorithm:</p>
|
||||
<pre data-language="cpp"><span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
|
||||
<span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'P'</span><span class="p">,</span><span class="sc">'r'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'v'</span><span class="p">,</span><span class="sc">'o'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span>
|
||||
<span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
|
||||
<span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'S'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'q'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'n'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span>
|
||||
<span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
|
||||
<span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'O'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'p'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span>
|
||||
<span class="k">const</span> <span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span>
|
||||
<span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'J'</span><span class="p">,</span><span class="sc">'S'</span><span class="p">,</span><span class="sc">'p'</span><span class="p">,</span><span class="sc">'l'</span><span class="p">,</span><span class="sc">'i'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span>
|
||||
<pre data-language="cpp"><span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'P'</span><span class="p">,</span><span class="sc">'r'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'v'</span><span class="p">,</span><span class="sc">'o'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span><span class="w"></span>
|
||||
<span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'S'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'q'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'e'</span><span class="p">,</span><span class="sc">'n'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span><span class="w"></span>
|
||||
<span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'O'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'p'</span><span class="p">,</span><span class="sc">'u'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span><span class="w"></span>
|
||||
<span class="k">const</span><span class="w"> </span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">{</span><span class="sc">'Z'</span><span class="p">,</span><span class="sc">'c'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">,</span><span class="sc">'J'</span><span class="p">,</span><span class="sc">'S'</span><span class="p">,</span><span class="sc">'p'</span><span class="p">,</span><span class="sc">'l'</span><span class="p">,</span><span class="sc">'i'</span><span class="p">,</span><span class="sc">'t'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'H'</span><span class="p">,</span><span class="sc">'a'</span><span class="p">,</span><span class="sc">'s'</span><span class="p">,</span><span class="sc">'h'</span><span class="p">};</span><span class="w"></span>
|
||||
|
||||
<span class="c1">// The default values are zeroes</span>
|
||||
<span class="n">uint256</span> <span class="n">hashPrevouts</span><span class="p">;</span>
|
||||
<span class="n">uint256</span> <span class="n">hashSequence</span><span class="p">;</span>
|
||||
<span class="n">uint256</span> <span class="n">hashOutputs</span><span class="p">;</span>
|
||||
<span class="n">uint256</span> <span class="n">hashJoinSplits</span><span class="p">;</span>
|
||||
<span class="n">uint256</span><span class="w"> </span><span class="n">hashPrevouts</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="n">uint256</span><span class="w"> </span><span class="n">hashSequence</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="n">uint256</span><span class="w"> </span><span class="n">hashOutputs</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="n">uint256</span><span class="w"> </span><span class="n">hashJoinSplits</span><span class="p">;</span><span class="w"></span>
|
||||
|
||||
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span> <span class="o">&</span> <span class="n">SIGHASH_ANYONECANPAY</span><span class="p">))</span> <span class="p">{</span>
|
||||
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
|
||||
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o"><</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
<span class="n">hashPrevouts</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
|
||||
<span class="p">}</span>
|
||||
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&</span><span class="w"> </span><span class="n">SIGHASH_ANYONECANPAY</span><span class="p">))</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_PREVOUTS_HASH_PERSONALIZATION</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o"><</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">}</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">hashPrevouts</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span><span class="w"></span>
|
||||
<span class="p">}</span><span class="w"></span>
|
||||
|
||||
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span> <span class="o">&</span> <span class="n">SIGHASH_ANYONECANPAY</span><span class="p">)</span> <span class="o">&&</span> <span class="p">(</span><span class="n">nHashType</span> <span class="o">&</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_SINGLE</span> <span class="o">&&</span> <span class="p">(</span><span class="n">nHashType</span> <span class="o">&</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_NONE</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">);</span>
|
||||
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o"><</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
<span class="n">hashSequence</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
|
||||
<span class="p">}</span>
|
||||
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="o">!</span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&</span><span class="w"> </span><span class="n">SIGHASH_ANYONECANPAY</span><span class="p">)</span><span class="w"> </span><span class="o">&&</span><span class="w"> </span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_SINGLE</span><span class="w"> </span><span class="o">&&</span><span class="w"> </span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_NONE</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_SEQUENCE_HASH_PERSONALIZATION</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o"><</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">n</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">}</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">hashSequence</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span><span class="w"></span>
|
||||
<span class="p">}</span><span class="w"></span>
|
||||
|
||||
<span class="k">if</span> <span class="p">((</span><span class="n">nHashType</span> <span class="o">&</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_SINGLE</span> <span class="o">&&</span> <span class="p">(</span><span class="n">nHashType</span> <span class="o">&</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">!=</span> <span class="n">SIGHASH_NONE</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
|
||||
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o"><</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">n</span><span class="p">];</span>
|
||||
<span class="p">}</span>
|
||||
<span class="n">hashOutputs</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
|
||||
<span class="p">}</span> <span class="k">else</span> <span class="k">if</span> <span class="p">((</span><span class="n">nHashType</span> <span class="o">&</span> <span class="mh">0x1f</span><span class="p">)</span> <span class="o">==</span> <span class="n">SIGHASH_SINGLE</span> <span class="o">&&</span> <span class="n">nIn</span> <span class="o"><</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">())</span> <span class="p">{</span>
|
||||
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">nIn</span><span class="p">];</span>
|
||||
<span class="n">hashOutputs</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
|
||||
<span class="p">}</span>
|
||||
<span class="k">if</span><span class="w"> </span><span class="p">((</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_SINGLE</span><span class="w"> </span><span class="o">&&</span><span class="w"> </span><span class="p">(</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">SIGHASH_NONE</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o"><</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">n</span><span class="p">];</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">}</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">hashOutputs</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span><span class="w"></span>
|
||||
<span class="p">}</span><span class="w"> </span><span class="k">else</span><span class="w"> </span><span class="k">if</span><span class="w"> </span><span class="p">((</span><span class="n">nHashType</span><span class="w"> </span><span class="o">&</span><span class="w"> </span><span class="mh">0x1f</span><span class="p">)</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="n">SIGHASH_SINGLE</span><span class="w"> </span><span class="o">&&</span><span class="w"> </span><span class="n">nIn</span><span class="w"> </span><span class="o"><</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">.</span><span class="n">size</span><span class="p">())</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_OUTPUTS_HASH_PERSONALIZATION</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vout</span><span class="p">[</span><span class="n">nIn</span><span class="p">];</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">hashOutputs</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span><span class="w"></span>
|
||||
<span class="p">}</span><span class="w"></span>
|
||||
|
||||
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">empty</span><span class="p">())</span> <span class="p">{</span>
|
||||
<span class="n">CBLAKE2bWriter</span> <span class="n">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">);</span>
|
||||
<span class="k">for</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">n</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">n</span> <span class="o"><</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">size</span><span class="p">();</span> <span class="n">n</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">[</span><span class="n">n</span><span class="p">];</span>
|
||||
<span class="p">}</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">joinSplitPubKey</span><span class="p">;</span>
|
||||
<span class="n">hashJoinSplits</span> <span class="o">=</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span>
|
||||
<span class="p">}</span>
|
||||
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="o">!</span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">empty</span><span class="p">())</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">ZCASH_JOINSPLITS_HASH_PERSONALIZATION</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="p">(</span><span class="kt">unsigned</span><span class="w"> </span><span class="kt">int</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span><span class="w"> </span><span class="n">n</span><span class="w"> </span><span class="o"><</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">.</span><span class="n">size</span><span class="p">();</span><span class="w"> </span><span class="n">n</span><span class="o">++</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vjoinsplit</span><span class="p">[</span><span class="n">n</span><span class="p">];</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="p">}</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">joinSplitPubKey</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">hashJoinSplits</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span><span class="w"></span>
|
||||
<span class="p">}</span><span class="w"></span>
|
||||
|
||||
<span class="kt">uint32_t</span> <span class="n">leConsensusBranchId</span> <span class="o">=</span> <span class="n">htole32</span><span class="p">(</span><span class="n">consensusBranchId</span><span class="p">);</span>
|
||||
<span class="kt">unsigned</span> <span class="kt">char</span> <span class="n">personalization</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span> <span class="o">=</span> <span class="p">{};</span>
|
||||
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="p">,</span> <span class="s">"ZcashSigHash"</span><span class="p">,</span> <span class="mi">12</span><span class="p">);</span>
|
||||
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="o">+</span><span class="mi">12</span><span class="p">,</span> <span class="o">&</span><span class="n">leConsensusBranchId</span><span class="p">,</span> <span class="mi">4</span><span class="p">);</span>
|
||||
<span class="kt">uint32_t</span><span class="w"> </span><span class="n">leConsensusBranchId</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">htole32</span><span class="p">(</span><span class="n">consensusBranchId</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="kt">unsigned</span><span class="w"> </span><span class="kt">char</span><span class="w"> </span><span class="n">personalization</span><span class="p">[</span><span class="mi">16</span><span class="p">]</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{};</span><span class="w"></span>
|
||||
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="p">,</span><span class="w"> </span><span class="s">"ZcashSigHash"</span><span class="p">,</span><span class="w"> </span><span class="mi">12</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="n">memcpy</span><span class="p">(</span><span class="n">personalization</span><span class="o">+</span><span class="mi">12</span><span class="p">,</span><span class="w"> </span><span class="o">&</span><span class="n">leConsensusBranchId</span><span class="p">,</span><span class="w"> </span><span class="mi">4</span><span class="p">);</span><span class="w"></span>
|
||||
|
||||
<span class="n">CBLAKE2bWriter</span> <span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">personalization</span><span class="p">);</span>
|
||||
<span class="n">CBLAKE2bWriter</span><span class="w"> </span><span class="nf">ss</span><span class="p">(</span><span class="n">SER_GETHASH</span><span class="p">,</span><span class="w"> </span><span class="mi">0</span><span class="p">,</span><span class="w"> </span><span class="n">personalization</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="c1">// fOverwintered and nVersion</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">GetHeader</span><span class="p">();</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">GetHeader</span><span class="p">();</span><span class="w"></span>
|
||||
<span class="c1">// Version group ID</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">nVersionGroupId</span><span class="p">;</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">nVersionGroupId</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="c1">// Input prevouts/nSequence (none/all, depending on flags)</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">hashPrevouts</span><span class="p">;</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">hashSequence</span><span class="p">;</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">hashPrevouts</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">hashSequence</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="c1">// Outputs (none/one/all, depending on flags)</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">hashOutputs</span><span class="p">;</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">hashOutputs</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="c1">// JoinSplits</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">hashJoinSplits</span><span class="p">;</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">hashJoinSplits</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="c1">// Locktime</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">nLockTime</span><span class="p">;</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">nLockTime</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="c1">// Expiry height</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">nExpiryHeight</span><span class="p">;</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">nExpiryHeight</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="c1">// Sighash type</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">nHashType</span><span class="p">;</span>
|
||||
<span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">nHashType</span><span class="p">;</span><span class="w"></span>
|
||||
|
||||
<span class="k">if</span> <span class="p">(</span><span class="n">nIn</span> <span class="o">!=</span> <span class="n">NOT_AN_INPUT</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="c1">// The input being signed (replacing the scriptSig with scriptCode + amount)</span>
|
||||
<span class="c1">// The prevout may already be contained in hashPrevout, and the nSequence</span>
|
||||
<span class="c1">// may already be contained in hashSequence.</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="k">static_cast</span><span class="o"><</span><span class="k">const</span> <span class="n">CScriptBase</span><span class="o">&></span><span class="p">(</span><span class="n">scriptCode</span><span class="p">);</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">amount</span><span class="p">;</span>
|
||||
<span class="n">ss</span> <span class="o"><<</span> <span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="n">nIn</span><span class="w"> </span><span class="o">!=</span><span class="w"> </span><span class="n">NOT_AN_INPUT</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="c1">// The input being signed (replacing the scriptSig with scriptCode + amount)</span>
|
||||
<span class="w"> </span><span class="c1">// The prevout may already be contained in hashPrevout, and the nSequence</span>
|
||||
<span class="w"> </span><span class="c1">// may already be contained in hashSequence.</span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">prevout</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="k">static_cast</span><span class="o"><</span><span class="k">const</span><span class="w"> </span><span class="n">CScriptBase</span><span class="o">&></span><span class="p">(</span><span class="n">scriptCode</span><span class="p">);</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">amount</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="n">ss</span><span class="w"> </span><span class="o"><<</span><span class="w"> </span><span class="n">txTo</span><span class="p">.</span><span class="n">vin</span><span class="p">[</span><span class="n">nIn</span><span class="p">].</span><span class="n">nSequence</span><span class="p">;</span><span class="w"></span>
|
||||
<span class="p">}</span><span class="w"></span>
|
||||
|
||||
<span class="k">return</span> <span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span></pre>
|
||||
<span class="k">return</span><span class="w"> </span><span class="n">ss</span><span class="p">.</span><span class="n">GetHash</span><span class="p">();</span><span class="w"></span></pre>
|
||||
</section>
|
||||
</section>
|
||||
<section id="example"><h2><span class="section-heading">Example</span><span class="section-anchor"> <a rel="bookmark" href="#example"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>To ensure consistency in consensus-critical behaviour, developers should test their implementations against the ZIP 143 test vectors <a id="id20" class="footnote_reference" href="#test-vectors">14</a>. The first two test vectors are broken out below for clarity. Note that 32-byte values below are exactly as the hash function returns, and are not reversed. Further examples can be found in the SignatureHash test data <a id="id21" class="footnote_reference" href="#sighash-tests">15</a>.</p>
|
||||
<p>The test vectors below should be verified with the Overwinter consensus branch ID (0x5ba81b19) <a id="id22" class="footnote_reference" href="#zip-0201">11</a>.</p>
|
||||
<p>To ensure consistency in consensus-critical behaviour, developers should test their implementations against the ZIP 143 test vectors <a id="footnote-reference-20" class="footnote_reference" href="#test-vectors">14</a>. The first two test vectors are broken out below for clarity. Note that 32-byte values below are exactly as the hash function returns, and are not reversed. Further examples can be found in the SignatureHash test data <a id="footnote-reference-21" class="footnote_reference" href="#sighash-tests">15</a>.</p>
|
||||
<p>The test vectors below should be verified with the Overwinter consensus branch ID (0x5ba81b19) <a id="footnote-reference-22" class="footnote_reference" href="#zip-0201">11</a>.</p>
|
||||
<section id="test-vector-1"><h3><span class="section-heading">Test vector 1</span><span class="section-anchor"> <a rel="bookmark" href="#test-vector-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Raw transaction:</p>
|
||||
<pre>030000807082c4030002e7719811893e0000095200ac6551ac636565b2835a0805750200025151481cdd86b3cc431800
|
||||
|
|
@ -339,7 +339,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is deployed with the Overwinter network upgrade. <a id="id23" class="footnote_reference" href="#zip-0201">11</a></p>
|
||||
<p>This proposal is deployed with the Overwinter network upgrade. <a id="footnote-reference-23" class="footnote_reference" href="#zip-0201">11</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is backwards-compatible with old UTXOs. It is <strong>not</strong> backwards-compatible with older software. All transactions will be required to use this transaction digest algorithm for signatures, and so transactions created by older software will be rejected by the network.</p>
|
||||
|
|
|
|||
|
|
@ -18,9 +18,9 @@ License: BSD-2-Clause
|
|||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/542">https://github.com/zcash/zips/issues/542</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/543">https://github.com/zcash/zips/pull/543</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
<p>"P2P network" means the Zcash peer-to-peer network.</p>
|
||||
<p><code>uint8</code>, <code>uint16</code>, and <code>uint32</code> denote unsigned integer data types of the corresponding length (8, 16, or 32 bits respectively).</p>
|
||||
</section>
|
||||
|
|
@ -28,11 +28,11 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/543">https://githu
|
|||
<p>This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current <code>addr</code> message.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy <a id="id4" class="footnote_reference" href="#tor-rendezvous-v3">9</a>. These services have 256-bit addresses and thus do not fit in the existing <code>addr</code> message (unchanged from Bitcoin <a id="id5" class="footnote_reference" href="#bitcoin-addr-message">7</a>), which encapsulates onion addresses in OnionCat IPv6 addresses.</p>
|
||||
<p>Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy <a id="footnote-reference-4" class="footnote_reference" href="#tor-rendezvous-v3">9</a>. These services have 256-bit addresses and thus do not fit in the existing <code>addr</code> message (unchanged from Bitcoin <a id="footnote-reference-5" class="footnote_reference" href="#bitcoin-addr-message">7</a>), which encapsulates onion addresses in OnionCat IPv6 addresses.</p>
|
||||
<p>Other transport-layer protocols such as I2P have always used longer addresses. This change would make it possible to gossip such addresses over the P2P network, so that other peers can connect to them.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The <code>addrv2</code> message is defined as a message where the <code>command</code> field is (NUL-padded) <code>"addrv2"</code>. It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format described in <a id="id6" class="footnote_reference" href="#bitcoin-addr-message">7</a>, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to <a id="id7" class="footnote_reference" href="#bitcoin-compactsize">8</a>.</p>
|
||||
<p>The <code>addrv2</code> message is defined as a message where the <code>command</code> field is (NUL-padded) <code>"addrv2"</code>. It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format described in <a id="footnote-reference-6" class="footnote_reference" href="#bitcoin-addr-message">7</a>, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to <a id="footnote-reference-7" class="footnote_reference" href="#bitcoin-compactsize">8</a>.</p>
|
||||
<p>This means that the message contains a serialized vector of the following structure:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
|
|
@ -127,14 +127,14 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/543">https://githu
|
|||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="id8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
|
||||
<p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="footnote-reference-8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
|
||||
<p>Clients SHOULD gossip valid, potentially routable addresses from all known networks, even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.</p>
|
||||
<p>Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.</p>
|
||||
<p>Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.</p>
|
||||
<section id="network-address-encodings"><h3><span class="section-heading">Network address encodings</span><span class="section-anchor"> <a rel="bookmark" href="#network-address-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The <code>IPV4</code> and <code>IPV6</code> network IDs use addresses encoded in the usual way for binary IPv4 and IPv6 addresses in network byte order (big endian).</p>
|
||||
<section id="tor-v3-address-encoding"><h4><span class="section-heading">Tor v3 address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#tor-v3-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>According to the spec <a id="id9" class="footnote_reference" href="#tor-rendezvous-v3">9</a>, version 3 <code>.onion</code> addresses are encoded as follows:</p>
|
||||
<p>According to the spec <a id="footnote-reference-9" class="footnote_reference" href="#tor-rendezvous-v3">9</a>, version 3 <code>.onion</code> addresses are encoded as follows:</p>
|
||||
<pre>onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion"
|
||||
CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
|
||||
<p>where:</p>
|
||||
|
|
@ -143,30 +143,30 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
|
|||
<li><code>VERSION</code> is a one-byte version field (default value <code>0x03</code>);</li>
|
||||
<li><code>".onion"</code> and <code>".onion checksum"</code> are constant strings;</li>
|
||||
<li><code>CHECKSUM</code> is truncated to two bytes before inserting it in <code>onion_address</code>;</li>
|
||||
<li><code>H()</code> is the SHA3-256 cryptographic hash function. <a id="id10" class="footnote_reference" href="#nist-sha3">10</a></li>
|
||||
<li><code>H()</code> is the SHA3-256 cryptographic hash function. <a id="footnote-reference-10" class="footnote_reference" href="#nist-sha3">10</a></li>
|
||||
</ul>
|
||||
<p>Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte <code>PUBKEY</code> part in the <code>addr</code> field. As <code>VERSION</code> will always be 0x03 in the case of v3 addresses, this is enough to reconstruct the onion address.</p>
|
||||
</section>
|
||||
<section id="i2p-address-encoding"><h4><span class="section-heading">I2P address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#i2p-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Like Tor, I2P naming uses a base32-encoded address format <a id="id11" class="footnote_reference" href="#i2p-naming">11</a>.</p>
|
||||
<p>Like Tor, I2P naming uses a base32-encoded address format <a id="footnote-reference-11" class="footnote_reference" href="#i2p-naming">11</a>.</p>
|
||||
<p>I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>. The base32 encoding does not include <code>"="</code> padding characters.</p>
|
||||
<p>I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field.</p>
|
||||
</section>
|
||||
<section id="cjdns-address-encoding"><h4><span class="section-heading">Cjdns address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#cjdns-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range <a id="id12" class="footnote_reference" href="#cjdns-whitepaper">12</a>. They MUST be sent with the <code>CJDNS</code> network ID. They are encoded in network byte order (big endian) as for the <code>IPV6</code> network ID.</p>
|
||||
<p>Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range <a id="footnote-reference-12" class="footnote_reference" href="#cjdns-whitepaper">12</a>. They MUST be sent with the <code>CJDNS</code> network ID. They are encoded in network byte order (big endian) as for the <code>IPV6</code> network ID.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>TODO: change ${PLACEHOLDER} to a specific peer protocol version.</p>
|
||||
<p>Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="id13" class="footnote_reference" href="#zip-0252">6</a>.</p>
|
||||
<p>Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="footnote-reference-13" class="footnote_reference" href="#zip-0252">6</a>.</p>
|
||||
<p>Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MUST NOT send <code>addrv2</code> messages on that connection.</p>
|
||||
<p>A node that has negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MAY still send <code>addr</code> messages on the connection, and MUST handle received <code>addr</code> messages as it would have done prior to this ZIP.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is closely based on BIP 155 <a id="id14" class="footnote_reference" href="#bip-0155">3</a>, with the following changes:</p>
|
||||
<p>This ZIP is closely based on BIP 155 <a id="footnote-reference-14" class="footnote_reference" href="#bip-0155">3</a>, with the following changes:</p>
|
||||
<ul>
|
||||
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of ${PLACEHOLDER} or higher, not by sending a <code>sendaddrv2</code> message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example the <code>MSG_WTX</code> inv type defined in ZIP 239 <a id="id15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
|
||||
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of ${PLACEHOLDER} or higher, not by sending a <code>sendaddrv2</code> message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example the <code>MSG_WTX</code> inv type defined in ZIP 239 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
|
||||
<li>No Network ID for Tor v2 onion addresses: the Tor network is expected to have removed support for these addresses in the timeframe for deployment of this ZIP.</li>
|
||||
<li>Clients MUST, rather than SHOULD, reject <code>addrv2</code> messages with more than 1,000 addresses. Making this a consistent requirement promotes interoperability.</li>
|
||||
<li>Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks.</li>
|
||||
|
|
@ -177,7 +177,7 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
|
|||
<p>TBD.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is closely based on BIP 155 <a id="id16" class="footnote_reference" href="#bip-0155">3</a>, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.</p>
|
||||
<p>This ZIP is closely based on BIP 155 <a id="footnote-reference-16" class="footnote_reference" href="#bip-0155">3</a>, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.</p>
|
||||
<p>Acknowledgements for BIP 155:</p>
|
||||
<ul>
|
||||
<li>Jonas Schnelli: change <code>services</code> field to <code>CompactSize</code>, to make the message more compact in the likely case instead of always using 8 bytes.</li>
|
||||
|
|
|
|||
|
|
@ -18,15 +18,15 @@ Category: Standards / Wallet
|
|||
Created: 2018-06-13
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205. <a id="id3" class="footnote_reference" href="#zip-0205">5</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205. <a id="footnote-reference-3" class="footnote_reference" href="#zip-0205">5</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This document proposes a checksummed base32 format, "Bech32", and a standard for Sapling addresses and keys using it.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256 checksum, inherited from Bitcoin. They were part of the original Bitcoin software and their scope was extended in BIP 13 <a id="id4" class="footnote_reference" href="#bip-0013">6</a> for P2SH (Pay-to-Script-Hash) addresses. However, both the character set and the checksum algorithm have limitations:</p>
|
||||
<p>Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256 checksum, inherited from Bitcoin. They were part of the original Bitcoin software and their scope was extended in BIP 13 <a id="footnote-reference-4" class="footnote_reference" href="#bip-0013">6</a> for P2SH (Pay-to-Script-Hash) addresses. However, both the character set and the checksum algorithm have limitations:</p>
|
||||
<ul>
|
||||
<li>Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''.</li>
|
||||
<li>The mixed case in Base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud.</li>
|
||||
|
|
@ -34,11 +34,11 @@ License: MIT</pre>
|
|||
<li>Most of the research on error-detecting codes only applies to character-set sizes that are a <a href="https://en.wikipedia.org/wiki/Prime_power">prime power</a>, which 58 is not.</li>
|
||||
<li>Base58 decoding is complicated and relatively slow.</li>
|
||||
</ul>
|
||||
<p>To address these issues, Bitcoin adopted a new encoding called Bech32 <a id="id5" class="footnote_reference" href="#bip-0173">7</a>, for use with address types added by its Segregated Witness proposal. Zcash does not implement Segregated Witness, but it reuses Bech32 with address and key types introduced by the Sapling network upgrade <a id="id6" class="footnote_reference" href="#zip-0205">5</a>.</p>
|
||||
<p>Since the description of Bech32 in <a id="id7" class="footnote_reference" href="#bip-0173">7</a> is partially entangled with Segregated Witness address formats, we have found it clearer to write this ZIP to specify Bech32 separately. This specification should be read in conjunction with section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol specification <a id="id8" class="footnote_reference" href="#protocol">2</a>, and with ZIP 32 which specifies additional key types for support of shielded hierarchical deterministic wallets <a id="id9" class="footnote_reference" href="#zip-0032">3</a>.</p>
|
||||
<p>To address these issues, Bitcoin adopted a new encoding called Bech32 <a id="footnote-reference-5" class="footnote_reference" href="#bip-0173">7</a>, for use with address types added by its Segregated Witness proposal. Zcash does not implement Segregated Witness, but it reuses Bech32 with address and key types introduced by the Sapling network upgrade <a id="footnote-reference-6" class="footnote_reference" href="#zip-0205">5</a>.</p>
|
||||
<p>Since the description of Bech32 in <a id="footnote-reference-7" class="footnote_reference" href="#bip-0173">7</a> is partially entangled with Segregated Witness address formats, we have found it clearer to write this ZIP to specify Bech32 separately. This specification should be read in conjunction with section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol specification <a id="footnote-reference-8" class="footnote_reference" href="#protocol">2</a>, and with ZIP 32 which specifies additional key types for support of shielded hierarchical deterministic wallets <a id="footnote-reference-9" class="footnote_reference" href="#zip-0032">3</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>We describe the general checksummed base32 format called ''Bech32''. Its use for Sapling payment addresses and keys is defined in the Sapling protocol specification <a id="id10" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>We describe the general checksummed base32 format called ''Bech32''. Its use for Sapling payment addresses and keys is defined in the Sapling protocol specification <a id="footnote-reference-10" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>A Bech32 string consists of:</p>
|
||||
<ul>
|
||||
<li>The <em>human-readable part</em>, which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications.</li>
|
||||
|
|
@ -158,7 +158,7 @@ def bech32_verify_checksum(hrp, data):
|
|||
<li>The resulting groups are interpreted as the raw encoding of the appropriate address or key type, with the most significant bit first in each byte.</li>
|
||||
</ul>
|
||||
<p>Decoders SHOULD enforce known-length restrictions on address and key types.</p>
|
||||
<p>For example, <a id="id11" class="footnote_reference" href="#protocol">2</a> specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.</p>
|
||||
<p>For example, <a id="footnote-reference-11" class="footnote_reference" href="#protocol">2</a> specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.</p>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -183,7 +183,7 @@ def bech32_verify_checksum(hrp, data):
|
|||
<p>Existing character sets for base-32 encodings include <a href="https://www.rfc-editor.org/rfc/rfc3548.html">RFC 3548</a> and <a href="https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt">z-base-32</a>. The set used for Bech32 was chosen to minimize ambiguity according to <a href="https://hissa.nist.gov/~black/GTLD/">this</a> visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.</p>
|
||||
</section>
|
||||
<section id="why-are-the-high-bits-of-the-human-readable-part-processed-first"><h3><span class="section-heading">Why are the high bits of the human-readable part processed first?</span><span class="section-anchor"> <a rel="bookmark" href="#why-are-the-high-bits-of-the-human-readable-part-processed-first"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This design choice had a rationale for Bitcoin Segregated Witness addresses (see <a id="id12" class="footnote_reference" href="#bip-0173">7</a>) that does not apply to Zcash Sapling addresses. It is retained for compatibility with Bech32 encoders/decoders written for Bitcoin.</p>
|
||||
<p>This design choice had a rationale for Bitcoin Segregated Witness addresses (see <a id="footnote-reference-12" class="footnote_reference" href="#bip-0173">7</a>) that does not apply to Zcash Sapling addresses. It is retained for compatibility with Bech32 encoders/decoders written for Bitcoin.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementations"><h2><span class="section-heading">Reference implementations</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Consensus
|
|||
Created: 2018-01-08
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Block chain</dt>
|
||||
|
|
@ -33,8 +33,8 @@ License: MIT</pre>
|
|||
<p>This proposal defines a mechanism for coordinating upgrades of the Zcash network, in order to remove ambiguity about when network upgrades will activate, provide defined periods in which users should upgrade their local software, and minimize the risks to both the upgrading network and any users opting out of the changes.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash is a <em>consensual currency</em>: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. <a id="id2" class="footnote_reference" href="#consensual-currency">2</a> As such, different sub-communities will always have the freedom to choose different variants or branches which offer different design trade-offs.</p>
|
||||
<p>The current Zcash software includes an <em>End-of-Service halt</em> feature, causing nodes running a particular version to automatically shut down approximately 16 weeks after that version was released (specifically, at the block height <code>DEPRECATION_HEIGHT</code> defined in the source code for that version). This was implemented for several reasons: <a id="id3" class="footnote_reference" href="#release-lifecycle">3</a></p>
|
||||
<p>Zcash is a <em>consensual currency</em>: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. <a id="footnote-reference-2" class="footnote_reference" href="#consensual-currency">2</a> As such, different sub-communities will always have the freedom to choose different variants or branches which offer different design trade-offs.</p>
|
||||
<p>The current Zcash software includes an <em>End-of-Service halt</em> feature, causing nodes running a particular version to automatically shut down approximately 16 weeks after that version was released (specifically, at the block height <code>DEPRECATION_HEIGHT</code> defined in the source code for that version). This was implemented for several reasons: <a id="footnote-reference-3" class="footnote_reference" href="#release-lifecycle">3</a></p>
|
||||
<ul>
|
||||
<li>It gives the same systemic advantage of removing old software as auto-upgrade behavior.</li>
|
||||
<li>It requires users to individually choose one of the following options:
|
||||
|
|
@ -70,19 +70,19 @@ License: MIT</pre>
|
|||
<section id="activation-mechanism"><h3><span class="section-heading">Activation mechanism</span><span class="section-anchor"> <a rel="bookmark" href="#activation-mechanism"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Zcash block chain is broken into "epochs" of block height intervals <code>[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})</code> (i.e. including <code>ACTIVATION_HEIGHT_N</code> and excluding <code>ACTIVATION_HEIGHT_{N+1}</code>), on which consensus rule sets are defined.</p>
|
||||
<p>When a consensus rule depends on activation of a particular upgrade, its implementation (and that of any network behavior or surrounding code that depends on it) MUST be gated by a block height check. For example:</p>
|
||||
<pre data-language="cpp"><span class="k">if</span> <span class="p">(</span><span class="n">CurrentEpoch</span><span class="p">(</span><span class="n">chainActive</span><span class="p">.</span><span class="n">Height</span><span class="p">(),</span> <span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">())</span> <span class="o">==</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">)</span> <span class="p">{</span>
|
||||
<span class="c1">// Overwinter-specific logic</span>
|
||||
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
|
||||
<span class="c1">// Non-Overwinter logic</span>
|
||||
<span class="p">}</span>
|
||||
<pre data-language="cpp"><span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="n">CurrentEpoch</span><span class="p">(</span><span class="n">chainActive</span><span class="p">.</span><span class="n">Height</span><span class="p">(),</span><span class="w"> </span><span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">())</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="c1">// Overwinter-specific logic</span>
|
||||
<span class="p">}</span><span class="w"> </span><span class="k">else</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="c1">// Non-Overwinter logic</span>
|
||||
<span class="p">}</span><span class="w"></span>
|
||||
|
||||
<span class="c1">// ...</span>
|
||||
|
||||
<span class="k">if</span> <span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">pindex</span><span class="o">-></span><span class="n">nHeight</span><span class="p">,</span> <span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">(),</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">))</span> <span class="p">{</span>
|
||||
<span class="c1">// Overwinter consensus rules applied to block</span>
|
||||
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
|
||||
<span class="c1">// Pre-Overwinter consensus rules applied to block</span>
|
||||
<span class="p">}</span></pre>
|
||||
<span class="k">if</span><span class="w"> </span><span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">pindex</span><span class="o">-></span><span class="n">nHeight</span><span class="p">,</span><span class="w"> </span><span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">(),</span><span class="w"> </span><span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">))</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="c1">// Overwinter consensus rules applied to block</span>
|
||||
<span class="p">}</span><span class="w"> </span><span class="k">else</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||
<span class="w"> </span><span class="c1">// Pre-Overwinter consensus rules applied to block</span>
|
||||
<span class="p">}</span><span class="w"></span></pre>
|
||||
<section id="block-validation"><h4><span class="section-heading">Block validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be validated under the consensus rules corresponding to the expected consensus branch ID for that height.</p>
|
||||
<p>Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown) MAY be cached, so that they can be reconsidered in the future after all their parents have been received.</p>
|
||||
|
|
@ -99,8 +99,8 @@ License: MIT</pre>
|
|||
<p>When the current chain tip height reaches <code>ACTIVATION_HEIGHT</code>, the node's local transaction memory pool SHOULD be cleared of transactions that will never be valid on the post-upgrade consensus branch.</p>
|
||||
</section>
|
||||
<section id="two-way-replay-protection"><h3><span class="section-heading">Two-way replay protection</span><span class="section-anchor"> <a rel="bookmark" href="#two-way-replay-protection"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the most significant bit of the transaction version is set to 1. <a id="id4" class="footnote_reference" href="#zip-0202">6</a> From the perspective of old nodes, the transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes old transactions invalid on the Overwinter consensus branch.</p>
|
||||
<p>After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific <code>CONSENSUS_BRANCH_ID</code>. <a id="id5" class="footnote_reference" href="#zip-0143">4</a></p>
|
||||
<p>Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the most significant bit of the transaction version is set to 1. <a id="footnote-reference-4" class="footnote_reference" href="#zip-0202">6</a> From the perspective of old nodes, the transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes old transactions invalid on the Overwinter consensus branch.</p>
|
||||
<p>After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific <code>CONSENSUS_BRANCH_ID</code>. <a id="footnote-reference-5" class="footnote_reference" href="#zip-0143">4</a></p>
|
||||
</section>
|
||||
<section id="wipe-out-protection"><h3><span class="section-heading">Wipe-out protection</span><span class="section-anchor"> <a rel="bookmark" href="#wipe-out-protection"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from <code>ACTIVATION_HEIGHT</code>. The chain from that height will not reorganize to a pre-upgrade consensus branch if any block in that consensus branch would violate the new consensus rules.</p>
|
||||
|
|
@ -108,7 +108,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. <a id="id6" class="footnote_reference" href="#zip-0201">5</a></p>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. <a id="footnote-reference-6" class="footnote_reference" href="#zip-0201">5</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
|
|
|
|||
|
|
@ -15,8 +15,8 @@ Category: Network
|
|||
Created: 2018-01-15
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Overwinter</dt>
|
||||
|
|
@ -24,12 +24,12 @@ License: MIT</pre>
|
|||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Mechanism <a id="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Mechanism <a id="footnote-reference-3" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>Related to:</p>
|
||||
<ul>
|
||||
<li>Transaction Signature Validation for Overwinter <a id="id4" class="footnote_reference" href="#zip-0143">2</a>.</li>
|
||||
<li>Version 3 Transaction Format for Overwinter <a id="id5" class="footnote_reference" href="#zip-0202">4</a>.</li>
|
||||
<li>Transaction Expiry <a id="id6" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
<li>Transaction Signature Validation for Overwinter <a id="footnote-reference-4" class="footnote_reference" href="#zip-0143">2</a>.</li>
|
||||
<li>Version 3 Transaction Format for Overwinter <a id="footnote-reference-5" class="footnote_reference" href="#zip-0202">4</a>.</li>
|
||||
<li>Transaction Expiry <a id="footnote-reference-6" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -37,7 +37,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>When a new inbound connection is received or an outbound connection created, a CNode object is instantiated with the version field set to INIT_PROTO_VERSION which has a value of 209. This value is not transmitted across the network, but for legacy reasons and technical debt beyond the scope of this ZIP, this value will not be changed.</p>
|
||||
<p>Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake <a id="id7" class="footnote_reference" href="#bitcoin-version-handshake">8</a> involves "version" and "verack" messages being exchanged.:</p>
|
||||
<p>Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake <a id="footnote-reference-7" class="footnote_reference" href="#bitcoin-version-handshake">8</a> involves "version" and "verack" messages being exchanged.:</p>
|
||||
<pre>L -> R: Send version message with the local peer's version
|
||||
R -> L: Send version message back
|
||||
R -> L: Send verack message
|
||||
|
|
@ -70,7 +70,7 @@ static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
|
|||
<p>To prepare for mainnet activation, Overwinter nodes will contain the following constants:</p>
|
||||
<pre>static const int PROTOCOL_VERSION = 170005;
|
||||
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
|
||||
<p>On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the <code>NODE_BLOOM</code> service bit defined in <a id="id8" class="footnote_reference" href="#bip-0111">6</a>.)</p>
|
||||
<p>On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the <code>NODE_BLOOM</code> service bit defined in <a id="footnote-reference-8" class="footnote_reference" href="#bip-0111">6</a>.)</p>
|
||||
<p>These constants allow pre-Overwinter nodes that support protocol versions 170002 to 170004 inclusive, and Overwinter nodes (which support protocol versions 170002 to 170005 inclusive before Overwinter activation) to remain connected until the activation.</p>
|
||||
<p>As these constants cannot be changed at run-time, once Overwinter activates on testnet or mainnet, Overwinter nodes should take steps to:</p>
|
||||
<ul>
|
||||
|
|
@ -80,7 +80,7 @@ static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
|
|||
</section>
|
||||
<section id="network-coalescence"><h3><span class="section-heading">Network Coalescence</span><span class="section-anchor"> <a rel="bookmark" href="#network-coalescence"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to the activation of Overwinter, nodes running a pre-Overwinter protocol version (e.g. 170002) and the Overwinter protocol version (170003 for testnet; 170005 for mainnet) remain connected with the same consensus rules, but it is desirable for nodes supporting Overwinter to connect preferentially to other nodes supporting Overwinter.</p>
|
||||
<p>This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. <a id="id9" class="footnote_reference" href="#eclipse-attack">9</a></p>
|
||||
<p>This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. <a id="footnote-reference-9" class="footnote_reference" href="#eclipse-attack">9</a></p>
|
||||
<p>To assist network coalescence before the activation height, we update the eviction process to place a higher priority on evicting Sprout nodes.</p>
|
||||
<p>Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers:</p>
|
||||
<pre>if (nInbound >= nMaxInbound)
|
||||
|
|
@ -158,7 +158,7 @@ if (nActivationHeight > 0 &&
|
|||
</section>
|
||||
</section>
|
||||
<section id="deployment-of-overwinter"><h2><span class="section-heading">Deployment of Overwinter</span><span class="section-anchor"> <a rel="bookmark" href="#deployment-of-overwinter"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Overwinter network upgrade defines the following network upgrade constants <a id="id10" class="footnote_reference" href="#zip-0200">3</a>:</p>
|
||||
<p>The Overwinter network upgrade defines the following network upgrade constants <a id="footnote-reference-10" class="footnote_reference" href="#zip-0200">3</a>:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0x5ba81b19</code></dd>
|
||||
|
|
@ -170,11 +170,11 @@ if (nActivationHeight > 0 &&
|
|||
</dl>
|
||||
<p>The following ZIPs are deployed by Overwinter:</p>
|
||||
<ul>
|
||||
<li>ZIP 200 <a id="id11" class="footnote_reference" href="#zip-0200">3</a></li>
|
||||
<li>ZIP 200 <a id="footnote-reference-11" class="footnote_reference" href="#zip-0200">3</a></li>
|
||||
<li>ZIP 201 (this ZIP)</li>
|
||||
<li>ZIP 202 <a id="id12" class="footnote_reference" href="#zip-0202">4</a></li>
|
||||
<li>ZIP 203 <a id="id13" class="footnote_reference" href="#zip-0203">5</a></li>
|
||||
<li>ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">2</a></li>
|
||||
<li>ZIP 202 <a id="footnote-reference-12" class="footnote_reference" href="#zip-0202">4</a></li>
|
||||
<li>ZIP 203 <a id="footnote-reference-13" class="footnote_reference" href="#zip-0203">5</a></li>
|
||||
<li>ZIP 143 <a id="footnote-reference-14" class="footnote_reference" href="#zip-0143">2</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -15,12 +15,12 @@ Category: Consensus
|
|||
Created: 2018-01-10
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="id3" class="footnote_reference" href="#zip-0201">4</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="footnote-reference-3" class="footnote_reference" href="#zip-0201">4</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a new transaction format required for Network Upgrade Mechanism <a id="id4" class="footnote_reference" href="#zip-0200">3</a> and Transaction Expiry <a id="id5" class="footnote_reference" href="#zip-0203">5</a>.</p>
|
||||
<p>This proposal defines a new transaction format required for Network Upgrade Mechanism <a id="footnote-reference-4" class="footnote_reference" href="#zip-0200">3</a> and Transaction Expiry <a id="footnote-reference-5" class="footnote_reference" href="#zip-0203">5</a>.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash launched with support for upstream Bitcoin version 1 transactions and defined a new version 2 transaction format which added fields required for shielded transactions.</p>
|
||||
|
|
@ -98,12 +98,12 @@ License: MIT</pre>
|
|||
</table>
|
||||
<p>A new transaction format is required to:</p>
|
||||
<ul>
|
||||
<li>support safe network upgrades as specified in Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a>;</li>
|
||||
<li>support safe network upgrades as specified in Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">3</a>;</li>
|
||||
<li>provide replay protection between pre-Overwinter and Overwinter consensus branches during upgrades;</li>
|
||||
<li>provide replay protection between different consensus branches post-Overwinter;</li>
|
||||
<li>enable a consensus branch to support multiple transaction version formats;</li>
|
||||
<li>ensure transaction formats are parsed uniquely across parallel consensus branches;</li>
|
||||
<li>support transaction expiry <a id="id7" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
<li>support transaction expiry <a id="footnote-reference-7" class="footnote_reference" href="#zip-0203">5</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -268,7 +268,7 @@ License: MIT</pre>
|
|||
<p>However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.</p>
|
||||
</section>
|
||||
<section id="expiry-height"><h3><span class="section-heading">Expiry Height</span><span class="section-anchor"> <a rel="bookmark" href="#expiry-height"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="id8" class="footnote_reference" href="#zip-0203">5</a>, stores the block height after which a transaction can no longer be mined.</p>
|
||||
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="footnote-reference-8" class="footnote_reference" href="#zip-0203">5</a>, stores the block height after which a transaction can no longer be mined.</p>
|
||||
</section>
|
||||
<section id="transaction-validation"><h3><span class="section-heading">Transaction Validation</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A valid Overwinter transaction intended for Zcash MUST have:</p>
|
||||
|
|
@ -283,7 +283,7 @@ License: MIT</pre>
|
|||
<li>the version group ID is unknown; or</li>
|
||||
<li>the version number is unknown.</li>
|
||||
</ul>
|
||||
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id9" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="footnote-reference-9" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -317,14 +317,14 @@ License: MIT</pre>
|
|||
}</pre>
|
||||
<p>It is expected that this test involving <code>nVersionGroupId</code> is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.</p>
|
||||
<p>However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.</p>
|
||||
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id10" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="footnote-reference-10" class="footnote_reference" href="#zip-0143">2</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="id11" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="footnote-reference-11" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
</section>
|
||||
<section id="backwards-compatibility"><h2><span class="section-heading">Backwards compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backwards-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change" <a id="id12" class="footnote_reference" href="#zip-0200">3</a> between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.</p>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change" <a id="footnote-reference-12" class="footnote_reference" href="#zip-0200">3</a> between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.</p>
|
||||
<p>Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group IDs.</p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -48,10 +48,10 @@ License: MIT</pre>
|
|||
<p>Coinbase: <code>nExpiryHeight</code> on coinbase transactions is ignored, and is set to 0 by convention.</p>
|
||||
<p>Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions.</p>
|
||||
<section id="changes-for-blossom"><h3><span class="section-heading">Changes for Blossom</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-blossom"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>On Blossom activation <a id="id1" class="footnote_reference" href="#zip-0206">2</a>, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.</p>
|
||||
<p>On Blossom activation <a id="footnote-reference-1" class="footnote_reference" href="#zip-0206">2</a>, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.</p>
|
||||
</section>
|
||||
<section id="changes-for-nu5"><h3><span class="section-heading">Changes for NU5</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-nu5"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="id2" class="footnote_reference" href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">4</a>.</p>
|
||||
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="footnote-reference-2" class="footnote_reference" href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-txnencoding">4</a>.</p>
|
||||
</section>
|
||||
<section id="wallet-behavior-and-ui"><h3><span class="section-heading">Wallet behavior and UI</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-behavior-and-ui"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.</p>
|
||||
|
|
@ -69,7 +69,7 @@ License: MIT</pre>
|
|||
<p><cite>--txexpirydelta=100</cite></p>
|
||||
</section>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This feature will be deployed with Overwinter. The activation blockheight proposal is in <a id="id4" class="footnote_reference" href="#zip-0201">1</a>.</p>
|
||||
<p>This feature will be deployed with Overwinter. The activation blockheight proposal is in <a id="footnote-reference-4" class="footnote_reference" href="#zip-0201">1</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -15,9 +15,9 @@ Category: Consensus / Network
|
|||
Created: 2018-10-08
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">7</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">7</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Sapling</dt>
|
||||
|
|
@ -31,12 +31,12 @@ License: MIT</pre>
|
|||
<section id="sapling-deployment"><h3><span class="section-heading">Sapling deployment</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Sapling consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a>.</li>
|
||||
<li>Transaction Signature Validation for Sapling <a id="id5" class="footnote_reference" href="#zip-0243">9</a>.</li>
|
||||
<li>Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">7</a>.</li>
|
||||
<li>The Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a>.</li>
|
||||
<li>Transaction Signature Validation for Sapling <a id="footnote-reference-5" class="footnote_reference" href="#zip-0243">9</a>.</li>
|
||||
<li>Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">7</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in <a id="id7" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id8" class="footnote_reference" href="#zip-0200">7</a> are defined for the Sapling upgrade:</p>
|
||||
<p>The network handshake and peer management mechanisms defined in <a id="footnote-reference-7" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="footnote-reference-8" class="footnote_reference" href="#zip-0200">7</a> are defined for the Sapling upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0x76b809bb</code></dd>
|
||||
|
|
@ -52,7 +52,7 @@ License: MIT</pre>
|
|||
<p>Approximately three days (defined in terms of block height) before the Sapling activation height, Sapling-compatible nodes will change the behaviour of their peer connection logic in order to prefer pre-Sapling peers for eviction from the set of peer connections.</p>
|
||||
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id9" class="footnote_reference" href="#zip-0201">8</a>.</p>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-9" class="footnote_reference" href="#zip-0201">8</a>.</p>
|
||||
<p>Once Sapling activates on Testnet or Mainnet, Sapling nodes SHOULD take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Sapling nodes;</li>
|
||||
|
|
@ -60,8 +60,8 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
|
|||
</ul>
|
||||
</section>
|
||||
<section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Section 7.6.3 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">5</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
|
||||
<p>This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id12" class="footnote_reference" href="#protocol-nbits">6</a>.</p>
|
||||
<p>Section 7.6.3 of the Zcash Protocol Specification <a id="footnote-reference-10" class="footnote_reference" href="#protocol-diffadjustment">5</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
|
||||
<p>This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="footnote-reference-11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="footnote-reference-12" class="footnote_reference" href="#protocol-nbits">6</a>.</p>
|
||||
<p>Note: a previous revision of this ZIP incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
|
||||
<p>This change does not affect Mainnet.</p>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -15,16 +15,16 @@ Category: Consensus / Network
|
|||
Created: 2019-07-29
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Blossom</dt>
|
||||
<dd>Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dd>The Zcash test network, as defined in <a id="footnote-reference-3" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dd>The Zcash production network, as defined in <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -34,12 +34,12 @@ License: MIT</pre>
|
|||
<section id="blossom-deployment"><h3><span class="section-heading">Blossom deployment</span><span class="section-anchor"> <a rel="bookmark" href="#blossom-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Blossom consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a>.</li>
|
||||
<li>Shorter Block Target Spacing <a id="id6" class="footnote_reference" href="#zip-0208">5</a>.</li>
|
||||
<li>Network Upgrade Mechanism <a id="id7" class="footnote_reference" href="#zip-0200">3</a>.</li>
|
||||
<li>The Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol">2</a>.</li>
|
||||
<li>Shorter Block Target Spacing <a id="footnote-reference-6" class="footnote_reference" href="#zip-0208">5</a>.</li>
|
||||
<li>Network Upgrade Mechanism <a id="footnote-reference-7" class="footnote_reference" href="#zip-0200">3</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in <a id="id8" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id9" class="footnote_reference" href="#zip-0200">3</a> are defined for the Blossom upgrade:</p>
|
||||
<p>The network handshake and peer management mechanisms defined in <a id="footnote-reference-8" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="footnote-reference-9" class="footnote_reference" href="#zip-0200">3</a> are defined for the Blossom upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0x2BB40E60</code></dd>
|
||||
|
|
@ -54,7 +54,7 @@ License: MIT</pre>
|
|||
<p>For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding Blossom activation height, nodes compatible with Blossom activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Blossom peers on that network for eviction from the set of peer connections:</p>
|
||||
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id10" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-10" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
<p>Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Blossom nodes on that network;</li>
|
||||
|
|
@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
|
|||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Blossom and pre-Blossom nodes are compatible and can connect to each other. However, Blossom nodes will have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Blossom nodes can still accept the numerically larger protocol version used by Blossom as being valid, Blossom nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="id11" class="footnote_reference" href="#protocol">2</a> section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.</p>
|
||||
<p>Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="footnote-reference-11" class="footnote_reference" href="#protocol">2</a> section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.</p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Blossom on testnet is implemented in <code>zcashd</code> version 2.0.7, which advertises protocol version 170008. Support for Blossom on mainnet is implemented in <code>zcashd</code> version 2.1.0, which advertises protocol version 170009.</p>
|
||||
|
|
|
|||
|
|
@ -16,34 +16,34 @@ Category: Consensus
|
|||
Created: 2019-01-04
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">7</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">10</a></p>
|
||||
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="footnote-reference-2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="footnote-reference-3" class="footnote_reference" href="#protocol-subsidies">7</a></p>
|
||||
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-4" class="footnote_reference" href="#zip-0200">10</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Canopy</dt>
|
||||
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol-networks">4</a></dd>
|
||||
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="footnote-reference-5" class="footnote_reference" href="#protocol-networks">4</a></dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-networks">4</a></dd>
|
||||
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="footnote-reference-6" class="footnote_reference" href="#protocol-networks">4</a></dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">14</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">16</a>, which describes the high-level requirements for that fund.</p>
|
||||
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="footnote-reference-7" class="footnote_reference" href="#zip-0214">14</a>. It should be read in conjunction with ZIP 1014 <a id="footnote-reference-8" class="footnote_reference" href="#zip-1014">16</a>, which describes the high-level requirements for that fund.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">16</a>.</p>
|
||||
<p>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="footnote-reference-9" class="footnote_reference" href="#zip-1014">16</a>.</p>
|
||||
<p>This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">14</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">16</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="footnote-reference-10" class="footnote_reference" href="#zip-0214">14</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 <a id="footnote-reference-11" class="footnote_reference" href="#zip-1014">16</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>As for the original Founders' Reward, a mechanism is provided to allow addresses for a given funding stream to be changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We use the following constants and functions defined in <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, <a id="id13" class="footnote_reference" href="#protocol-diffadjustment">6</a>, <a id="id14" class="footnote_reference" href="#protocol-subsidies">7</a>, and <a id="id15" class="footnote_reference" href="#protocol-foundersreward">8</a>:</p>
|
||||
<p>We use the following constants and functions defined in <a id="footnote-reference-12" class="footnote_reference" href="#protocol-constants">5</a>, <a id="footnote-reference-13" class="footnote_reference" href="#protocol-diffadjustment">6</a>, <a id="footnote-reference-14" class="footnote_reference" href="#protocol-subsidies">7</a>, and <a id="footnote-reference-15" class="footnote_reference" href="#protocol-foundersreward">8</a>:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BlossomActivationHeight}\)</span>
|
||||
|
|
@ -74,7 +74,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="funding-streams"><h3><span class="section-heading">Funding streams</span><span class="section-anchor"> <a rel="bookmark" href="#funding-streams"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).</p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="id16" class="footnote_reference" href="#zip-0208">11</a></p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="footnote-reference-16" class="footnote_reference" href="#zip-0208">11</a></p>
|
||||
<p>The value of a funding stream at a given block height is defined as:</p>
|
||||
<div class="math">\(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
|
||||
\mathsf{floor}\left(
|
||||
|
|
@ -196,21 +196,21 @@ License: MIT</pre>
|
|||
<p>On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.</p>
|
||||
</section>
|
||||
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rules"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id17" class="footnote_reference" href="#protocol-foundersreward">8</a></p>
|
||||
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="footnote-reference-17" class="footnote_reference" href="#protocol-foundersreward">8</a></p>
|
||||
<p>Once the Canopy network upgrade activates:</p>
|
||||
<ul>
|
||||
<li>The existing consensus rule for payment of the Founders' Reward <a id="id18" class="footnote_reference" href="#protocol-foundersreward">8</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The existing consensus rule for payment of the Founders' Reward <a id="footnote-reference-18" class="footnote_reference" href="#protocol-foundersreward">8</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
|
||||
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id19" class="footnote_reference" href="#zip-0213">13</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="footnote-reference-19" class="footnote_reference" href="#zip-0213">13</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
|
||||
<span class="math">\(\mathbf{0x02}\)</span>
|
||||
, as specified in <a id="id20" class="footnote_reference" href="#zip-0212">12</a>.</li>
|
||||
, as specified in <a id="footnote-reference-20" class="footnote_reference" href="#zip-0212">12</a>.</li>
|
||||
</ul>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id21" class="footnote_reference" href="#zip-0214">14</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id22" class="footnote_reference" href="#zip-0000">9</a></p>
|
||||
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="footnote-reference-21" class="footnote_reference" href="#zip-0214">14</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="footnote-reference-22" class="footnote_reference" href="#zip-0000">9</a></p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id23" class="footnote_reference" href="#zip-0251">15</a></p>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="footnote-reference-23" class="footnote_reference" href="#zip-0251">15</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
|
|
|
|||
|
|
@ -17,13 +17,13 @@ Created: 2019-01-10
|
|||
License: MIT
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/237">https://github.com/zcash/zips/pull/237</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">9</a>.</p>
|
||||
<p>The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-diffadjustment">6</a>.)</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-networks">4</a>.</p>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">9</a>.</p>
|
||||
<p>The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-diffadjustment">6</a>.)</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol-networks">4</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="id5" class="footnote_reference" href="#zip-0206">11</a>.</p>
|
||||
<p>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="footnote-reference-5" class="footnote_reference" href="#zip-0206">11</a>.</p>
|
||||
<p>The emission schedule of mined ZEC will be approximately the same in terms of time, but this requires the emission per block to be adjusted to take account of the changed block target spacing.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -33,15 +33,15 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/237">https://githu
|
|||
<li>Greater throughput of transactions in unit time.</li>
|
||||
</ul>
|
||||
<p>The latter goal could alternatively be achieved by increasing the block size limit, but that would not also achieve the former goal.</p>
|
||||
<p>Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See <a id="id6" class="footnote_reference" href="#slowfastblocks">13</a> for further analysis in various attack models.</p>
|
||||
<p>Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See <a id="footnote-reference-6" class="footnote_reference" href="#slowfastblocks">13</a> for further analysis in various attack models.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes described in this section are to be made in the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol">3</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
|
||||
<p>The changes described in this section are to be made in the Zcash Protocol Specification <a id="footnote-reference-7" class="footnote_reference" href="#protocol">3</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
|
||||
<section id="consensus-changes"><h3><span class="section-heading">Consensus changes</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from <a id="id8" class="footnote_reference" href="#preblossom-protocol">2</a> of 840000 (blocks) and 150 (seconds) respectively.</p>
|
||||
<p>Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from <a id="footnote-reference-8" class="footnote_reference" href="#preblossom-protocol">2</a> of 840000 (blocks) and 150 (seconds) respectively.</p>
|
||||
<p>In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing to the list of integer constants.</p>
|
||||
<p>In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.</p>
|
||||
<p>For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in <a id="id9" class="footnote_reference" href="#zip-0206">11</a>.</p>
|
||||
<p>For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in <a id="footnote-reference-9" class="footnote_reference" href="#zip-0206">11</a>.</p>
|
||||
<p>In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the following changes:</p>
|
||||
<p>Define IsBlossomActivated(<em>height</em>) to return true if <em>height</em> ≥ BlossomActivationHeight, otherwise false.</p>
|
||||
<p>This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.</p>
|
||||
|
|
@ -111,9 +111,9 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/237">https://githu
|
|||
<p>The change in the effective value of PoWTargetSpacing will cause the block spacing to adjust to the new target, at the normal rate for a difficulty adjustment. The results of simulations are consistent with this expected behaviour.</p>
|
||||
<p>Note that the change in AveragingWindowTimespan(height) takes effect immediately when calculating the target difficulty starting from the block at the Blossom activation height, even though the difficulty of the preceding PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target spacing. Therefore it is likely that the difficulty adjustment for the first few blocks after activation will be limited by PoWMaxAdjustDown. This is not anticipated to cause any problem.</p>
|
||||
<section id="minimum-difficulty-blocks-on-testnet"><h4><span class="section-heading">Minimum difficulty blocks on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-testnet"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>On Testnet from block height 299188 onward, the difficulty adjustment algorithm <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">6</a> allows minimum-difficulty blocks, as described in <a id="id11" class="footnote_reference" href="#zip-0205">10</a>, when the block time is greater than a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
|
||||
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is greater than 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
|
||||
<p>Note: a previous revision of this ZIP (and <a id="id14" class="footnote_reference" href="#zip-0205">10</a>) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
|
||||
<p>On Testnet from block height 299188 onward, the difficulty adjustment algorithm <a id="footnote-reference-10" class="footnote_reference" href="#protocol-diffadjustment">6</a> allows minimum-difficulty blocks, as described in <a id="footnote-reference-11" class="footnote_reference" href="#zip-0205">10</a>, when the block time is greater than a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
|
||||
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is greater than 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="footnote-reference-12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="footnote-reference-13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
|
||||
<p>Note: a previous revision of this ZIP (and <a id="footnote-reference-14" class="footnote_reference" href="#zip-0205">10</a>) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
|
||||
<p>This change does not affect Mainnet.</p>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -127,7 +127,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/237">https://githu
|
|||
<p>If the <code>-txexpirydelta</code> option is set, then the set value SHOULD be used both before and after Blossom activation.</p>
|
||||
</section>
|
||||
<section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-to-sapling-migration"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ZIP 308 <a id="id15" class="footnote_reference" href="#zip-0308">12</a> defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.</p>
|
||||
<p>ZIP 308 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0308">12</a> defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.</p>
|
||||
<p>The 500-block constant has not been changed. Therefore, migration transactions are now sent roughly every 10.42 hours after Blossom activation. This has been noted in the ZIP, and a table showing the expected time to complete migration has been updated accordingly.</p>
|
||||
</section>
|
||||
<section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a rel="bookmark" href="#fingerprinting-mitigation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
|
|
@ -137,7 +137,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/237">https://githu
|
|||
// chain if they are valid, and no more than a month older (both in time, and in
|
||||
// best equivalent proof of work) than the best header chain we know about.</pre>
|
||||
<p>We make no assertion about the significance of fingerprinting for Zcash, and (despite the word "prevent" in the above comment) no claim about the effectiveness of this mitigation.</p>
|
||||
<p>In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.7.5 of the Zcash Protocol Specification <a id="id16" class="footnote_reference" href="#protocol-workdef">8</a>, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
|
||||
<p>In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.7.5 of the Zcash Protocol Specification <a id="footnote-reference-16" class="footnote_reference" href="#protocol-workdef">8</a>, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
|
||||
<p>It is not a requirement of the Zcash protocol that this fingerprinting mitigation is used; however, if it is used, then it SHOULD use the target block spacing at the same block height that is used for the current work estimate.</p>
|
||||
</section>
|
||||
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
|
|
@ -194,7 +194,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Blossom network upgrade. <a id="id17" class="footnote_reference" href="#zip-0206">11</a></p>
|
||||
<p>This proposal will be deployed with the Blossom network upgrade. <a id="footnote-reference-17" class="footnote_reference" href="#zip-0206">11</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
|
|
|
|||
|
|
@ -15,12 +15,12 @@ Category: Consensus
|
|||
Created: 2019-02-25
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "block chain" and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "block chain" and "network upgrade" are to be interpreted as defined in <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The "Sprout chain value pool balance" for a given block chain is the sum of all <code>vpub_old</code> fields for transactions in the block chain, minus the sum of all <code>vpub_new</code> fields for transactions in the block chain.</p>
|
||||
<p>The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceSapling</code> fields for transactions in the block chain.</p>
|
||||
<p>The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceOrchard</code> fields for transactions in the block chain. (Before NU5 has activated, the Orchard chain value pool balance is zero.)</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines how the consensus rules are altered such that blocks that produce negative shielded chain value pool balances are prohibited.</p>
|
||||
|
|
@ -34,9 +34,9 @@ License: MIT</pre>
|
|||
<p>Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned restriction.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 <a id="id4" class="footnote_reference" href="#zip-0200">3</a> and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.</p>
|
||||
<p>This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0200">3</a> and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.</p>
|
||||
<p>There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s) will be produced that violate it, potentially leading to network fragmentation. This is considered sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.</p>
|
||||
<p>This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet. The application to the Orchard chain value pool balance will be deployed from NU5 activation <a id="id5" class="footnote_reference" href="#zip-0252">4</a>.</p>
|
||||
<p>This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet. The application to the Orchard chain value pool balance will be deployed from NU5 activation <a id="footnote-reference-5" class="footnote_reference" href="#zip-0252">4</a>.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
|
|
|
|||
|
|
@ -14,19 +14,19 @@ Category: Consensus
|
|||
Created: 2019-03-27
|
||||
License: MIT</pre>
|
||||
<section id="status"><h2><span class="section-heading">Status</span><span class="section-anchor"> <a rel="bookmark" href="#status"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP has been withdrawn because a similar change has been incorporated into the ZIP 225 proposal for a version 5 transaction format. <a id="id1" class="footnote_reference" href="#zip-0225">5</a></p>
|
||||
<p>This ZIP has been withdrawn because a similar change has been incorporated into the ZIP 225 proposal for a version 5 transaction format. <a id="footnote-reference-1" class="footnote_reference" href="#zip-0225">5</a></p>
|
||||
</section>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id2" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id4" class="footnote_reference" href="#zip-0205">4</a>.</p>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-2" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-3" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0205">4</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a modification to the transaction format whereby a single Sapling anchor is used for all Sapling spends. This change removes a potential implementation fingerprint, and reduces the size of Sapling transactions within the block chain.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Sapling network upgrade <a id="id5" class="footnote_reference" href="#zip-0205">4</a> introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.</p>
|
||||
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="id6" class="footnote_reference" href="#protocol-txnencoding">2</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
|
||||
<p>The Sapling network upgrade <a id="footnote-reference-5" class="footnote_reference" href="#zip-0205">4</a> introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.</p>
|
||||
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="footnote-reference-6" class="footnote_reference" href="#protocol-txnencoding">2</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
|
||||
<p>Modifying the transaction format to have a single Sapling anchor field, instead of one field per Sapling spend, removes the ability (within the new transaction format version) to create transactions with this fingerprint. It also reduces the size of the transaction, costing 32 bytes per transaction instead of 32 bytes per spend.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -15,22 +15,22 @@ Category: Consensus
|
|||
Created: 2019-03-29
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a>.</p>
|
||||
<p>The term "Sprout shielded protocol" in this document refers to the shielded payment protocol defined at the launch of the Zcash network.</p>
|
||||
<p>The term "Sapling shielded protocol" in this document refers to the shielded payment protocol introduced in the Sapling network upgrade <a id="id3" class="footnote_reference" href="#zip-0205">4</a> <a id="id4" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>The term "Sprout chain value pool balance" in this document is to be interpreted as described in ZIP 209 <a id="id5" class="footnote_reference" href="#zip-0209">5</a>.</p>
|
||||
<p>The term "Sapling shielded protocol" in this document refers to the shielded payment protocol introduced in the Sapling network upgrade <a id="footnote-reference-3" class="footnote_reference" href="#zip-0205">4</a> <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>The term "Sprout chain value pool balance" in this document is to be interpreted as described in ZIP 209 <a id="footnote-reference-5" class="footnote_reference" href="#zip-0209">5</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal disables the ability to add new value to the Sprout chain value pool balance. This takes a step toward being able to remove the Sprout shielded protocol, thus reducing the overall complexity and attack surface of Zcash.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The first iteration of the Zcash network, called Sprout, provided a shielded payment protocol that was relatively closely based on the original Zerocash proposal. <a id="id6" class="footnote_reference" href="#zerocash">8</a></p>
|
||||
<p>The Sapling network upgrade <a id="id7" class="footnote_reference" href="#zip-0205">4</a> introduced significant efficiency and functionality improvements for shielded transactions. It is expected that over time, the use of Sapling will replace the use of Sprout in shielded transactions.</p>
|
||||
<p>The first iteration of the Zcash network, called Sprout, provided a shielded payment protocol that was relatively closely based on the original Zerocash proposal. <a id="footnote-reference-6" class="footnote_reference" href="#zerocash">8</a></p>
|
||||
<p>The Sapling network upgrade <a id="footnote-reference-7" class="footnote_reference" href="#zip-0205">4</a> introduced significant efficiency and functionality improvements for shielded transactions. It is expected that over time, the use of Sapling will replace the use of Sprout in shielded transactions.</p>
|
||||
<p>The Sapling and Sprout shielded protocols employ different cryptographic designs. Since an adversary could potentially exploit any vulnerability in either design, supporting both presents additional risk over supporting only the newer Sapling shielded protocol.</p>
|
||||
<p>For example, a vulnerability was discovered in the zero-knowledge proving system originally used by Zcash that could have allowed counterfeiting <a id="id8" class="footnote_reference" href="#counterfeiting">9</a>. While this particular vulnerability was addressed (also for Sprout shielded transactions) by the Sapling upgrade, and we are not aware of others at the time of writing, the possibility of other cryptographic weaknesses cannot be entirely ruled out.</p>
|
||||
<p>For example, a vulnerability was discovered in the zero-knowledge proving system originally used by Zcash that could have allowed counterfeiting <a id="footnote-reference-8" class="footnote_reference" href="#counterfeiting">9</a>. While this particular vulnerability was addressed (also for Sprout shielded transactions) by the Sapling upgrade, and we are not aware of others at the time of writing, the possibility of other cryptographic weaknesses cannot be entirely ruled out.</p>
|
||||
<p>In addition, the Zcash specification and implementation incurs complexity and "technical debt" from the requirement to support and test both shielded payment protocols.</p>
|
||||
<p>Removing the ability to add to the Sprout chain value pool balance, is a first step toward reducing this complexity and potential risk. This does not prevent extracting value held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses via the migration tool <a id="id9" class="footnote_reference" href="#zip-0308">7</a>.</p>
|
||||
<p>Removing the ability to add to the Sprout chain value pool balance, is a first step toward reducing this complexity and potential risk. This does not prevent extracting value held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses via the migration tool <a id="footnote-reference-9" class="footnote_reference" href="#zip-0308">7</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Consensus rule: From the relevant activation height, the <code>vpub_old</code> field of each JoinSplit description MUST be zero.</p>
|
||||
|
|
@ -47,7 +47,7 @@ License: MIT</pre>
|
|||
<p>During the development of this proposal, alternative designs were considered that would have removed some fields of a JoinSplit description. These alternatives were abandoned for several reasons:</p>
|
||||
<ul>
|
||||
<li>Privacy concerns raised as a consequence of preventing the use of internal change between JoinSplits, and/or change sent back to the input Sprout addresses. This would have required the total value of the input Sprout notes (or, for some considered designs, the total value of the two Sprout inputs to each JoinSplit) to be leaked. As it is, there is an unavoidable leak of the total value extracted from the Sprout value pool, but not of the sum of values of particular subsets of notes.</li>
|
||||
<li>Modifications would have been needed to the design of the Sprout to Sapling migration procedure described in <a id="id10" class="footnote_reference" href="#zip-0308">7</a>.</li>
|
||||
<li>Modifications would have been needed to the design of the Sprout to Sapling migration procedure described in <a id="footnote-reference-10" class="footnote_reference" href="#zip-0308">7</a>.</li>
|
||||
<li>A new transaction version would have been required.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
|
@ -56,7 +56,7 @@ License: MIT</pre>
|
|||
<p>Since all clients change their behaviour at the same time from this proposal's activation height, there is no additional client distinguisher.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id11" class="footnote_reference" href="#zip-0251">6</a></p>
|
||||
<p>This proposal will be deployed with the Canopy network upgrade. <a id="footnote-reference-11" class="footnote_reference" href="#zip-0251">6</a></p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/4489">https://github.com/zcash/zcash/pull/4489</a></p>
|
||||
|
|
|
|||
|
|
@ -15,37 +15,37 @@ Category: Consensus
|
|||
Created: 2019-03-31
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The following functions are defined in the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol">2</a> according to the type (Sapling or Orchard) of note plaintext being processed:</p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The following functions are defined in the Zcash Protocol Specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol">2</a> according to the type (Sapling or Orchard) of note plaintext being processed:</p>
|
||||
<ul>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{ToScalar}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{ToScalar^{Sapling}}\)</span>
|
||||
defined in section 4.2.2 <a id="id3" class="footnote_reference" href="#protocol-saplingkeycomponents">5</a> or
|
||||
defined in section 4.2.2 <a id="footnote-reference-3" class="footnote_reference" href="#protocol-saplingkeycomponents">5</a> or
|
||||
<span class="math">\(\mathsf{ToScalar^{Orchard}}\)</span>
|
||||
defined in section 4.2.3 <a id="id4" class="footnote_reference" href="#protocol-orchardkeycomponents">6</a>;</li>
|
||||
defined in section 4.2.3 <a id="footnote-reference-4" class="footnote_reference" href="#protocol-orchardkeycomponents">6</a>;</li>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{DiversifyHash}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathsf{DiversifyHash^{Orchard}}\)</span>
|
||||
defined in section 5.4.1.6 <a id="id5" class="footnote_reference" href="#protocol-concretediversifyhash">12</a>;</li>
|
||||
defined in section 5.4.1.6 <a id="footnote-reference-5" class="footnote_reference" href="#protocol-concretediversifyhash">12</a>;</li>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{KA}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{KA^{Sapling}}\)</span>
|
||||
defined in section 5.4.5.3 <a id="id6" class="footnote_reference" href="#protocol-concretesaplingkeyagreement">13</a> or
|
||||
defined in section 5.4.5.3 <a id="footnote-reference-6" class="footnote_reference" href="#protocol-concretesaplingkeyagreement">13</a> or
|
||||
<span class="math">\(\mathsf{KA^{Orchard}}\)</span>
|
||||
defined in section 5.4.5.5 <a id="id7" class="footnote_reference" href="#protocol-concreteorchardkeyagreement">14</a>;</li>
|
||||
defined in section 5.4.5.5 <a id="footnote-reference-7" class="footnote_reference" href="#protocol-concreteorchardkeyagreement">14</a>;</li>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{NoteCommit}\)</span>
|
||||
be
|
||||
<span class="math">\(\mathsf{NoteCommit^{Sapling}}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathsf{NoteCommit^{Orchard}}\)</span>
|
||||
defined in section 4.1.8 <a id="id8" class="footnote_reference" href="#protocol-abstractcommit">4</a>.</li>
|
||||
defined in section 4.1.8 <a id="footnote-reference-8" class="footnote_reference" href="#protocol-abstractcommit">4</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -113,8 +113,8 @@ License: MIT</pre>
|
|||
.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
|
||||
<p>The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification <a id="footnote-reference-9" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification <a id="footnote-reference-10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
|
||||
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
|
||||
for the purposes of this ZIP. This function is keyed by a 256-bit key
|
||||
<span class="math">\(\mathsf{sk}\)</span>
|
||||
|
|
@ -122,7 +122,7 @@ License: MIT</pre>
|
|||
<span class="math">\(64\)</span>
|
||||
-byte sequence as output.</p>
|
||||
<section id="changes-to-sapling-and-orchard-note-plaintexts"><h3><span class="section-heading">Changes to Sapling and Orchard Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-and-orchard-note-plaintexts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-notept">15</a>. Before activation of this ZIP, the encoding of a Sapling note plaintext required that the first byte take the form
|
||||
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="footnote-reference-11" class="footnote_reference" href="#protocol-notept">15</a>. Before activation of this ZIP, the encoding of a Sapling note plaintext required that the first byte take the form
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
, indicating the version of the note plaintext. In addition, a
|
||||
<span class="math">\(256\)</span>
|
||||
|
|
@ -151,7 +151,7 @@ License: MIT</pre>
|
|||
field be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from descriptions of note plaintexts in the Zcash Protocol Specification.</p>
|
||||
</section>
|
||||
<section id="changes-to-the-process-of-sending-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of sending Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling <a id="id12" class="footnote_reference" href="#protocol-saplingsend">7</a> and section 4.7.3 for Orchard <a id="id13" class="footnote_reference" href="#protocol-orchardsend">8</a>. In addition, the process of encrypting a note is described (currently) in section 4.19.1 of the Zcash Protocol Specification <a id="id14" class="footnote_reference" href="#protocol-saplingandorchardencrypt">9</a>. Prior to activation of this ZIP, the sender sampled
|
||||
<p>The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling <a id="footnote-reference-12" class="footnote_reference" href="#protocol-saplingsend">7</a> and section 4.7.3 for Orchard <a id="footnote-reference-13" class="footnote_reference" href="#protocol-orchardsend">8</a>. In addition, the process of encrypting a note is described (currently) in section 4.19.1 of the Zcash Protocol Specification <a id="footnote-reference-14" class="footnote_reference" href="#protocol-saplingandorchardencrypt">9</a>. Prior to activation of this ZIP, the sender sampled
|
||||
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||
and the ephemeral private key
|
||||
<span class="math">\(\mathsf{esk}\)</span>
|
||||
|
|
@ -178,10 +178,10 @@ License: MIT</pre>
|
|||
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>For Orchard, an encoding of ρ is appended to these PRF inputs, as specified in section 4.7.3 of the Zcash Protocol Specification <a id="id15" class="footnote_reference" href="#protocol-orchardsend">8</a>.</p>
|
||||
<p>For Orchard, an encoding of ρ is appended to these PRF inputs, as specified in section 4.7.3 of the Zcash Protocol Specification <a id="footnote-reference-15" class="footnote_reference" href="#protocol-orchardsend">8</a>.</p>
|
||||
</section>
|
||||
<section id="changes-to-the-process-of-receiving-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The process of receiving notes in Sapling is described in sections 4.19.2 and 4.19.3 of the Zcash Protocol Specification. <a id="id16" class="footnote_reference" href="#protocol-decryptivk">10</a> <a id="id17" class="footnote_reference" href="#protocol-decryptovk">11</a></p>
|
||||
<p>The process of receiving notes in Sapling is described in sections 4.19.2 and 4.19.3 of the Zcash Protocol Specification. <a id="footnote-reference-16" class="footnote_reference" href="#protocol-decryptivk">10</a> <a id="footnote-reference-17" class="footnote_reference" href="#protocol-decryptovk">11</a></p>
|
||||
<p>There is a "grace period" of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
MUST still be accepted.</p>
|
||||
|
|
@ -223,11 +223,11 @@ License: MIT</pre>
|
|||
, failing decryption if this check is not satisfied. For Orchard, an encoding of ρ is appended to the PRF inputs, as for encryption.</p>
|
||||
</section>
|
||||
<section id="consensus-rule-change-for-coinbase-transactions"><h3><span class="section-heading">Consensus rule change for coinbase transactions</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rule-change-for-coinbase-transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <a id="id18" class="footnote_reference" href="#zip-0213">17</a>, MUST have note plaintext lead byte equal to
|
||||
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <a id="footnote-reference-18" class="footnote_reference" href="#zip-0213">17</a>, MUST have note plaintext lead byte equal to
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
.</p>
|
||||
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="id19" class="footnote_reference" href="#zip-0207">16</a> sent to shielded payment addresses, if there are any.</p>
|
||||
<p>Since NU5 activates after the end of the grace period <a id="id20" class="footnote_reference" href="#zip-0252">19</a>, Orchard outputs will always require a note plaintext lead byte equal to
|
||||
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="footnote-reference-19" class="footnote_reference" href="#zip-0207">16</a> sent to shielded payment addresses, if there are any.</p>
|
||||
<p>Since NU5 activates after the end of the grace period <a id="footnote-reference-20" class="footnote_reference" href="#zip-0252">19</a>, Orchard outputs will always require a note plaintext lead byte equal to
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
|
|
@ -253,7 +253,7 @@ License: MIT</pre>
|
|||
that were sent conformantly and not mined before the upgrade.</p>
|
||||
<p>Historical note: in practice some note plaintexts with lead byte
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
were non-conformantly sent even after the end of the specified grace period. ZecWallet extended its implementation of the grace period by a further 161280 blocks (approximately 20 weeks) in order to allow for recovery of these funds <a id="id21" class="footnote_reference" href="#zecwallet-grace-extension">20</a>.</p>
|
||||
were non-conformantly sent even after the end of the specified grace period. ZecWallet extended its implementation of the grace period by a further 161280 blocks (approximately 20 weeks) in order to allow for recovery of these funds <a id="footnote-reference-21" class="footnote_reference" href="#zecwallet-grace-extension">20</a>.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub (or Pallas) elliptic curve, for it could perform a linkability attack trivially in that case.</p>
|
||||
|
|
@ -264,7 +264,7 @@ License: MIT</pre>
|
|||
) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id22" class="footnote_reference" href="#zip-0251">18</a></p>
|
||||
<p>This proposal will be deployed with the Canopy network upgrade. <a id="footnote-reference-22" class="footnote_reference" href="#zip-0251">18</a></p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>In zcashd:</p>
|
||||
|
|
|
|||
|
|
@ -14,18 +14,18 @@ Category: Consensus
|
|||
Created: 2019-03-30
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">2</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id3" class="footnote_reference" href="#zip-0205">3</a>.</p>
|
||||
<p>The terms "Founders' Reward" and "funding stream" in this document are to be interpreted as described in ZIP 207 <a id="id4" class="footnote_reference" href="#zip-0207">4</a>.</p>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">2</a>.</p>
|
||||
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="footnote-reference-3" class="footnote_reference" href="#zip-0205">3</a>.</p>
|
||||
<p>The terms "Founders' Reward" and "funding stream" in this document are to be interpreted as described in ZIP 207 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0207">4</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines modifications to the Zcash consensus rules that enable coinbase funds to be mined to Sapling (and later Orchard) addresses. It does not disable the use of transparent addresses in coinbase transactions.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions inside each block that are allowed to have no inputs. These transactions are created by miners during block creation, and collect the block reward and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the Founders' Reward (and potentially for funding streams <a id="id5" class="footnote_reference" href="#zip-0207">4</a>).</p>
|
||||
<p>Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions inside each block that are allowed to have no inputs. These transactions are created by miners during block creation, and collect the block reward and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the Founders' Reward (and potentially for funding streams <a id="footnote-reference-5" class="footnote_reference" href="#zip-0207">4</a>).</p>
|
||||
<p>On the path to deprecating and removing Bitcoin-inherited transparent addresses within the Zcash network, a required step is to be able to create coinbase transactions that have no transparent outputs. However, Zcash was launched with a consensus rule preventing coinbase transactions from containing shielded outputs, instead enforcing that coinbase funds could not be spent in transactions with transparent outputs. This was partly in order to reduce the complexity of the original Zcash modifications to the Bitcoin Core codebase, but also because at the time, shielded transactions required significant memory and CPU resources to create.</p>
|
||||
<p>The Sapling network upgrade <a id="id6" class="footnote_reference" href="#zip-0205">3</a> deployed architectural changes and performance improvements that make shielding funds directly in the coinbase transaction feasible. In order to reduce the complexity of the Sapling network upgrade, the existing consensus rules preventing coinbase transactions from containing shielded outputs were extended to cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in order to enable miners to start using Sapling addresses. It will also be possible for miners to use Orchard addresses starting from activation of the NU5 upgrade <a id="id7" class="footnote_reference" href="#zip-0252">6</a>.</p>
|
||||
<p>The Sapling network upgrade <a id="footnote-reference-6" class="footnote_reference" href="#zip-0205">3</a> deployed architectural changes and performance improvements that make shielding funds directly in the coinbase transaction feasible. In order to reduce the complexity of the Sapling network upgrade, the existing consensus rules preventing coinbase transactions from containing shielded outputs were extended to cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in order to enable miners to start using Sapling addresses. It will also be possible for miners to use Orchard addresses starting from activation of the NU5 upgrade <a id="footnote-reference-7" class="footnote_reference" href="#zip-0252">6</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to activation of the Heartwood network upgrade, this existing consensus rule on coinbase transactions is enforced:</p>
|
||||
|
|
@ -71,7 +71,7 @@ License: MIT</pre>
|
|||
<p>Revealing the coinbase output notes does not enable anyone else to detect when the note is spent, which removes the need for a separate shielding step like is enforced for transparent coinbase outputs.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal will be deployed with the Heartwood network upgrade. <a id="id8" class="footnote_reference" href="#zip-0250">5</a></p>
|
||||
<p>This proposal will be deployed with the Heartwood network upgrade. <a id="footnote-reference-8" class="footnote_reference" href="#zip-0250">5</a></p>
|
||||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p><a href="https://github.com/zcash/zcash/pull/4256">https://github.com/zcash/zcash/pull/4256</a></p>
|
||||
|
|
|
|||
|
|
@ -15,13 +15,13 @@ Created: 2020-02-28
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560">https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHALL", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (<a id="id2" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">8</a> and the Zcash Trademark Donation and License Agreement (<a id="id4" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
|
||||
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-subsidyconcepts">3</a>.</p>
|
||||
<p>The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-subsidies">5</a>.</p>
|
||||
<p>The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="id7" class="footnote_reference" href="#zip-1014">12</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id8" class="footnote_reference" href="#protocol-networks">4</a>.</p>
|
||||
<p>The key words "MUST", "SHALL", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (<a id="footnote-reference-2" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-3" class="footnote_reference" href="#zip-0200">8</a> and the Zcash Trademark Donation and License Agreement (<a id="footnote-reference-4" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
|
||||
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol-subsidyconcepts">3</a>.</p>
|
||||
<p>The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification <a id="footnote-reference-6" class="footnote_reference" href="#protocol-subsidies">5</a>.</p>
|
||||
<p>The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="footnote-reference-7" class="footnote_reference" href="#zip-1014">12</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-8" class="footnote_reference" href="#protocol-networks">4</a>.</p>
|
||||
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -31,7 +31,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/community-sentim
|
|||
<p>This ZIP concerns the Zcash Mainnet and Testnet, and is not intended to be applicable to other block chains using Zcash technology.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Motivation for the Zcash Development Fund itself is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">12</a>, which gives a high-level description of the intended structure of the fund.</p>
|
||||
<p>Motivation for the Zcash Development Fund itself is considered in ZIP 1014 <a id="footnote-reference-9" class="footnote_reference" href="#zip-1014">12</a>, which gives a high-level description of the intended structure of the fund.</p>
|
||||
<p>An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -42,9 +42,9 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/community-sentim
|
|||
<p>This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="id10" class="footnote_reference" href="#zip-0208">10</a>, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.</p>
|
||||
<p>The Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="footnote-reference-10" class="footnote_reference" href="#zip-0208">10</a>, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.</p>
|
||||
<p>Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.</p>
|
||||
<p>ZIP 207 <a id="id11" class="footnote_reference" href="#zip-0207">9</a> SHALL be activated in Canopy.</p>
|
||||
<p>ZIP 207 <a id="footnote-reference-11" class="footnote_reference" href="#zip-0207">9</a> SHALL be activated in Canopy.</p>
|
||||
<p>The following funding streams are defined for Mainnet:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
|
|
@ -82,7 +82,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/community-sentim
|
|||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p>As specified in <a id="id12" class="footnote_reference" href="#zip-0207">9</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
|
||||
<p>As specified in <a id="footnote-reference-12" class="footnote_reference" href="#zip-0207">9</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
|
||||
<p>The following funding streams are defined for Testnet:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
|
|
@ -132,10 +132,10 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/community-sentim
|
|||
<li>ZF SHALL generate the addresses for the <code>FS_ZIP214_ZF</code> and <code>FS_ZIP214_MG</code> funding streams, which on Mainnet correspond to the <strong>ZF slice</strong> and <strong>MG slice</strong> respectively.</li>
|
||||
</ul>
|
||||
<p>Within each stream, the addresses MAY be independent, or MAY be repeated between funding periods. Each party SHOULD take account of operational security issues associated with potential compromise of the associated spending keys.</p>
|
||||
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="id13" class="footnote_reference" href="#zip-1014">12</a>.</p>
|
||||
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="footnote-reference-13" class="footnote_reference" href="#zip-1014">12</a>.</p>
|
||||
<p>No requirements are imposed on the use of funds sent to Testnet funding streams.</p>
|
||||
<section id="direct-grant-option"><h4><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a rel="bookmark" href="#direct-grant-option"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the <strong>MG slice</strong> may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. <a id="id14" class="footnote_reference" href="#zip-1014">12</a></p>
|
||||
<p>ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the <strong>MG slice</strong> may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. <a id="footnote-reference-14" class="footnote_reference" href="#zip-1014">12</a></p>
|
||||
<p>The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total value of funding streams assigned to direct grantees MUST be subtracted from the value of the funding stream for the remaining <strong>MG slice</strong> (or, if all Major Grants are direct, replace the funding stream for the <strong>MG slice</strong>).</p>
|
||||
<p>For each network upgrade after Canopy requiring modifications to the set of direct grantees, a separate ZIP SHOULD be published specifying those modifications.</p>
|
||||
</section>
|
||||
|
|
@ -259,12 +259,12 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
|
|||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The rationale for ZF generating the addresses for the <code>FS_ZIP214_MG</code> funding stream is that ZF is the financial recipient of the <strong>MG slice</strong> as specified in ZIP 1014. <a id="id15" class="footnote_reference" href="#zip-1014">12</a></p>
|
||||
<p>The rationale for ZF generating the addresses for the <code>FS_ZIP214_MG</code> funding stream is that ZF is the financial recipient of the <strong>MG slice</strong> as specified in ZIP 1014. <a id="footnote-reference-15" class="footnote_reference" href="#zip-1014">12</a></p>
|
||||
<p>Generation of recipient addresses for Testnet is specified to be done by the same parties as on Mainnet, in order to allow practicing each party's security procedures.</p>
|
||||
<p>It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="id16" class="footnote_reference" href="#zip-0251">11</a></p>
|
||||
<p>This proposal is intended to be deployed with Canopy. <a id="footnote-reference-16" class="footnote_reference" href="#zip-0251">11</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
|
|
|
|||
|
|
@ -15,19 +15,19 @@ Category: Consensus
|
|||
Created: 2020-04-27
|
||||
License: BSD-2-Clause</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="id2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature validity from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 validity criteria and changing them to be compatible with batch validation.</p>
|
||||
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="footnote-reference-2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature validity from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 validity criteria and changing them to be compatible with batch validation.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The lack of clear validity criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validity criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-2020-1-1">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validity criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validity criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
|
||||
<p>The lack of clear validity criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validity criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-2020-1-1">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validity criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validity criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
|
||||
<p>In addition, the validity criteria used by Zcash preclude the use of batch validation of Ed25519 signatures. While signature validation is not the primary bottleneck for Zcash, it would be nice to be able to batch-validate signatures, as is the case for RedJubjub.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>After activation of this ZIP, the
|
||||
<span class="math">\(\mathsf{JoinSplitSig}\)</span>
|
||||
validation rules in <a id="id4" class="footnote_reference" href="#protocol-concreteed25519">5</a> are changed to the following:</p>
|
||||
validation rules in <a id="footnote-reference-4" class="footnote_reference" href="#protocol-concreteed25519">5</a> are changed to the following:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\underline{A}\)</span>
|
||||
|
|
@ -51,11 +51,11 @@ License: BSD-2-Clause</pre>
|
|||
<span class="math">\(k\)</span>
|
||||
and
|
||||
<span class="math">\(B\)</span>
|
||||
are defined as in RFC 8032 sections §5.1.7 and §5.1 respectively. <a id="id5" class="footnote_reference" href="#rfc8032">2</a></li>
|
||||
are defined as in RFC 8032 sections §5.1.7 and §5.1 respectively. <a id="footnote-reference-5" class="footnote_reference" href="#rfc8032">2</a></li>
|
||||
</ul>
|
||||
<p>The language about
|
||||
<span class="math">\(\mathsf{ExcludedPointEncodings}\)</span>
|
||||
in §5.4.5 of the Zcash specification <a id="id6" class="footnote_reference" href="#protocol-concreteed25519">5</a> no longer applies.</p>
|
||||
in §5.4.5 of the Zcash specification <a id="footnote-reference-6" class="footnote_reference" href="#protocol-concreteed25519">5</a> no longer applies.</p>
|
||||
<p>It is <em>not</em> required that
|
||||
<span class="math">\(\underline{A}\)</span>
|
||||
and
|
||||
|
|
@ -77,7 +77,7 @@ License: BSD-2-Clause</pre>
|
|||
<p>This change has no effect on honestly-generated signatures. Unlike the current validation rules, it makes it possible for a user to generate weak signing keys or to generate signing keys with nonzero torsion component and submit them to the blockchain. However, doing so provides them with no advantage, only compromise to their own security. Moreover, these cases are not a failure mode of any deployed implementation.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This is intended to be deployed with the Canopy Network Upgrade <a id="id7" class="footnote_reference" href="#zip-0251">6</a>, which is scheduled to activate on Mainnet <a id="id8" class="footnote_reference" href="#protocol-networks">4</a> at block height 1046400.</p>
|
||||
<p>This is intended to be deployed with the Canopy Network Upgrade <a id="footnote-reference-7" class="footnote_reference" href="#zip-0251">6</a>, which is scheduled to activate on Mainnet <a id="footnote-reference-8" class="footnote_reference" href="#protocol-networks">4</a> at block height 1046400.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
|
|
|
|||
|
|
@ -17,15 +17,15 @@ Created: 2021-02-11
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://github.com/zcash/zips/issues/400</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">12</a></p>
|
||||
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">12</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP fixes an oversight in the implementation of the Sapling consensus rules, by rejecting all non-canonical representations of Jubjub points.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Sapling specification was originally written with the intent that all values, including Jubjub points, are strongly typed with canonical representations. <a id="id3" class="footnote_reference" href="#protocol-jubjub">6</a> This has significant advantages for security analysis, because it allows the protocol to be modelled with just the abstract types.</p>
|
||||
<p>The intention of the Jubjub implementation (both in the <cite>jubjub</cite> crate <a id="id4" class="footnote_reference" href="#jubjub-crate">15</a> and its prior implementations) was to ensure that only canonical point encodings would be accepted by the decoding logic. However, an oversight in the implementation allowed an edge case to slip through: for each point on the curve where the
|
||||
<p>The Sapling specification was originally written with the intent that all values, including Jubjub points, are strongly typed with canonical representations. <a id="footnote-reference-3" class="footnote_reference" href="#protocol-jubjub">6</a> This has significant advantages for security analysis, because it allows the protocol to be modelled with just the abstract types.</p>
|
||||
<p>The intention of the Jubjub implementation (both in the <cite>jubjub</cite> crate <a id="footnote-reference-4" class="footnote_reference" href="#jubjub-crate">15</a> and its prior implementations) was to ensure that only canonical point encodings would be accepted by the decoding logic. However, an oversight in the implementation allowed an edge case to slip through: for each point on the curve where the
|
||||
<span class="math">\(u\!\)</span>
|
||||
-coordinate is zero, there are two encodings that will be accepted:</p>
|
||||
<pre data-language="rust"><span class="c1">// Fix the sign of `u` if necessary</span>
|
||||
|
|
@ -58,7 +58,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
<span class="math">\(\mathsf{repr}_{\mathbb{J}}\)</span>
|
||||
, and
|
||||
<span class="math">\(q_{\mathbb{J}}\)</span>
|
||||
be as defined in <a id="id5" class="footnote_reference" href="#protocol-jubjub">6</a>.</p>
|
||||
be as defined in <a id="footnote-reference-5" class="footnote_reference" href="#protocol-jubjub">6</a>.</p>
|
||||
<p>Define a non-canonical compressed encoding of a Jubjub point to be a sequence of
|
||||
<span class="math">\(256\)</span>
|
||||
bits,
|
||||
|
|
@ -80,7 +80,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
<span class="math">\(\mathtt{0x80}\)</span>
|
||||
byte.</p>
|
||||
<p>Once this ZIP activates, the following places within the Sapling consensus protocol where Jubjub points occur MUST reject non-canonical Jubjub point encodings.</p>
|
||||
<p>In Sapling Spend descriptions <a id="id6" class="footnote_reference" href="#protocol-spenddesc">3</a>:</p>
|
||||
<p>In Sapling Spend descriptions <a id="footnote-reference-6" class="footnote_reference" href="#protocol-spenddesc">3</a>:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>the
|
||||
|
|
@ -92,7 +92,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
RedDSA signature.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p>In transactions <a id="id7" class="footnote_reference" href="#protocol-txnencoding">10</a>:</p>
|
||||
<p>In transactions <a id="footnote-reference-7" class="footnote_reference" href="#protocol-txnencoding">10</a>:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>the
|
||||
|
|
@ -106,7 +106,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
</blockquote>
|
||||
<p>In the plaintext obtained by decrypting the
|
||||
<span class="math">\(\mathsf{C^{out}}\)</span>
|
||||
field of a Sapling transmitted note ciphertext <a id="id8" class="footnote_reference" href="#protocol-decryptovk">5</a>:</p>
|
||||
field of a Sapling transmitted note ciphertext <a id="footnote-reference-8" class="footnote_reference" href="#protocol-decryptovk">5</a>:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -116,7 +116,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
</blockquote>
|
||||
<p>(This affects decryption of
|
||||
<span class="math">\(\mathsf{C^{out}}\)</span>
|
||||
in all cases, but is consensus-critical only in the case of a shielded coinbase output. <a id="id9" class="footnote_reference" href="#protocol-txnencoding">10</a>)</p>
|
||||
in all cases, but is consensus-critical only in the case of a shielded coinbase output. <a id="footnote-reference-9" class="footnote_reference" href="#protocol-txnencoding">10</a>)</p>
|
||||
<p>There are some additional fields in the consensus protocol that encode Jubjub points, but where non-canonical encodings MUST already be rejected as a side-effect of existing consensus rules.</p>
|
||||
<p>In Sapling Spend descriptions:</p>
|
||||
<blockquote>
|
||||
|
|
@ -129,7 +129,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p>In Sapling Output descriptions <a id="id10" class="footnote_reference" href="#protocol-outputdesc">4</a>:</p>
|
||||
<p>In Sapling Output descriptions <a id="footnote-reference-10" class="footnote_reference" href="#protocol-outputdesc">4</a>:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -145,7 +145,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
<p>In addition, Sapling addresses and full viewing keys MUST be considered invalid when imported if they contain non-canonical Jubjub point encodings, or encodings of points that are not in the prime-order subgroup
|
||||
<span class="math">\(\mathbb{J}^{(r)}\)</span>
|
||||
. These requirements MAY be enforced in advance of NU5 activation.</p>
|
||||
<p>In Sapling addresses <a id="id11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">8</a>:</p>
|
||||
<p>In Sapling addresses <a id="footnote-reference-11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">8</a>:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>the encoding of
|
||||
|
|
@ -153,7 +153,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p>In Sapling full viewing keys <a id="id12" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">9</a> and extended full viewing keys <a id="id13" class="footnote_reference" href="#zip-0032-extfvk">11</a>:</p>
|
||||
<p>In Sapling full viewing keys <a id="footnote-reference-12" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">9</a> and extended full viewing keys <a id="footnote-reference-13" class="footnote_reference" href="#zip-0032-extfvk">11</a>:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>the encoding of
|
||||
|
|
@ -169,7 +169,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
<p>The above is intended to be a complete list of the places where compressed encodings of Jubjub points occur in the Zcash consensus protocol and in plaintext, address, or key formats.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash previously had a similar issue with non-canonical representations of points in Ed25519 public keys and signatures. In that case, given the prevalence of Ed25519 signatures in the wider ecosystem, the decision was made in ZIP 215 <a id="id14" class="footnote_reference" href="#zip-0215">13</a> (which activated with the Canopy network upgrade <a id="id15" class="footnote_reference" href="#zip-0251">14</a>) to allow non-canonical representations of points.</p>
|
||||
<p>Zcash previously had a similar issue with non-canonical representations of points in Ed25519 public keys and signatures. In that case, given the prevalence of Ed25519 signatures in the wider ecosystem, the decision was made in ZIP 215 <a id="footnote-reference-14" class="footnote_reference" href="#zip-0215">13</a> (which activated with the Canopy network upgrade <a id="footnote-reference-15" class="footnote_reference" href="#zip-0251">14</a>) to allow non-canonical representations of points.</p>
|
||||
<p>In Sapling, we are motivated instead to reject these non-canonical points:</p>
|
||||
<ul>
|
||||
<li>The chance of the identity occurring anywhere within the Sapling components of transactions from implementations following the standard protocol is cryptographically negligible.</li>
|
||||
|
|
@ -197,7 +197,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/400">https://g
|
|||
, and BLS12-381
|
||||
<span class="math">\(\mathbb{G}_2\)</span>
|
||||
are not affected.</p>
|
||||
<p>Encodings of elliptic curve points on the Pallas and Vesta curves in the NU5 proposal <a id="id16" class="footnote_reference" href="#protocol-pallasandvesta">7</a> are also not affected.</p>
|
||||
<p>Encodings of elliptic curve points on the Pallas and Vesta curves in the NU5 proposal <a id="footnote-reference-16" class="footnote_reference" href="#protocol-pallasandvesta">7</a> are also not affected.</p>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP eliminates a potential source of consensus divergence between differing full node implementations. At the time of writing (February 2021), no such divergence exists for any production implementation of Zcash, but the alpha-stage <cite>zebrad</cite> node implementation would be susceptible to this issue.</p>
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ Category: Consensus
|
|||
Created: 2019-03-30
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">8</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">8</a></p>
|
||||
<dl>
|
||||
<dt><em>Light client</em></dt>
|
||||
<dd>A client that is not a full participant in the network of Zcash peers. It can send and receive payments, but does not store or validate a copy of the block chain.</dd>
|
||||
|
|
@ -40,7 +40,7 @@ License: MIT</pre>
|
|||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP specifies modifications to the Zcash block header semantics and consensus rules in order to support the probabilistic verification FlyClient protocol <a id="id3" class="footnote_reference" href="#flyclient">2</a>. The <code>hashFinalSaplingRoot</code> commitment in the block header is replaced with a commitment to the root of a Merkle Mountain Range (MMR), that in turn commits to various features of the chain's history, including the Sapling commitment tree.</p>
|
||||
<p>This ZIP specifies modifications to the Zcash block header semantics and consensus rules in order to support the probabilistic verification FlyClient protocol <a id="footnote-reference-3" class="footnote_reference" href="#flyclient">2</a>. The <code>hashFinalSaplingRoot</code> commitment in the block header is replaced with a commitment to the root of a Merkle Mountain Range (MMR), that in turn commits to various features of the chain's history, including the Sapling commitment tree.</p>
|
||||
</section>
|
||||
<section id="background"><h2><span class="section-heading">Background</span><span class="section-anchor"> <a rel="bookmark" href="#background"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>An MMR is a Merkle tree which allows for efficient appends, proofs, and verifications. Informally, appending data to an MMR consists of creating a new leaf and then iteratively merging neighboring subtrees with the same size. This takes at most
|
||||
|
|
@ -48,7 +48,7 @@ License: MIT</pre>
|
|||
operations and only requires knowledge of the previous subtree roots, of which there are fewer than
|
||||
<span class="math">\(\log(n)\)</span>
|
||||
.</p>
|
||||
<p>(example adapted from <a id="id4" class="footnote_reference" href="#mimblewimble">6</a>) To illustrate this, consider a list of 11 leaves. We first construct the biggest perfect binary subtrees possible by joining any balanced sibling trees that are the same size. We do this starting from the left to the right, adding a parent as soon as 2 children exist. This leaves us with three subtrees ("mountains") of altitudes 3, 1, and 0:</p>
|
||||
<p>(example adapted from <a id="footnote-reference-4" class="footnote_reference" href="#mimblewimble">6</a>) To illustrate this, consider a list of 11 leaves. We first construct the biggest perfect binary subtrees possible by joining any balanced sibling trees that are the same size. We do this starting from the left to the right, adding a parent as soon as 2 children exist. This leaves us with three subtrees ("mountains") of altitudes 3, 1, and 0:</p>
|
||||
<pre data-language="text"> /\
|
||||
/ \
|
||||
/\ /\
|
||||
|
|
@ -151,7 +151,7 @@ License: MIT</pre>
|
|||
<p>MMR trees allow for efficient incremental set update operations (push, pop, prune). In addition, MMR update operations and Merkle proofs for recent additions to the leaf set are more efficient than other incremental Merkle tree implementations (e.g. Bitcoin's padded leafset, sparse Merkle trees, and Zcash's incremental note commitment trees).</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>MMR proofs are used in the FlyClient protocol <a id="id5" class="footnote_reference" href="#flyclient">2</a>, to reduce the proof size needed for light clients to verify:</p>
|
||||
<p>MMR proofs are used in the FlyClient protocol <a id="footnote-reference-5" class="footnote_reference" href="#flyclient">2</a>, to reduce the proof size needed for light clients to verify:</p>
|
||||
<ul>
|
||||
<li>the validity of a block chain received from a full node, and</li>
|
||||
<li>the inclusion of a block
|
||||
|
|
@ -171,7 +171,7 @@ License: MIT</pre>
|
|||
<p>(
|
||||
<span class="math">\(x\)</span>
|
||||
is the activation height of the preceding network upgrade.)</p>
|
||||
<p>FlyClient reduces the number of block headers needed for light client verification of a valid chain, from linear (as in the current reference protocol) to logarithmic in block chain length. This verification is correct with high probability. It also allows creation of subtree proofs, so light clients need only check blocks later than the most recently verified block index. Following that, verification of a transaction inclusion within that block follows the usual reference protocol <a id="id6" class="footnote_reference" href="#zip-0307">13</a>.</p>
|
||||
<p>FlyClient reduces the number of block headers needed for light client verification of a valid chain, from linear (as in the current reference protocol) to logarithmic in block chain length. This verification is correct with high probability. It also allows creation of subtree proofs, so light clients need only check blocks later than the most recently verified block index. Following that, verification of a transaction inclusion within that block follows the usual reference protocol <a id="footnote-reference-6" class="footnote_reference" href="#zip-0307">13</a>.</p>
|
||||
<p>A smaller proof size could enable the verification of Zcash SPV Proofs in block-chain protocols such as Ethereum, enabling efficient cross-chain communication and pegs. It also reduces bandwidth and storage requirements for resource-limited clients like mobile or IoT devices.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -196,7 +196,7 @@ License: MIT</pre>
|
|||
<span class="math">\(x\)</span>
|
||||
is defined as above. We extend the standard MMR to allow metadata to propagate upwards through the tree by either summing the metadata of both children, or inheriting the metadata of a specific child as necessary. This allows us to create efficient proofs of selected properties of a range of blocks without transmitting the entire range of blocks or headers.</p>
|
||||
<section id="tree-node-specification"><h3><span class="section-heading">Tree Node specification</span><span class="section-anchor"> <a rel="bookmark" href="#tree-node-specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Unless otherwise noted, all hashes use BLAKE2b-256 with the personalization field set to <code>'ZcashHistory' || CONSENSUS_BRANCH_ID</code>. <code>CONSENSUS_BRANCH_ID</code> is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the commitment. <a id="id7" class="footnote_reference" href="#zip-0200">8</a> Which is to say, each node in the tree commits to the consensus branch that produced it.</p>
|
||||
<p>Unless otherwise noted, all hashes use BLAKE2b-256 with the personalization field set to <code>'ZcashHistory' || CONSENSUS_BRANCH_ID</code>. <code>CONSENSUS_BRANCH_ID</code> is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the commitment. <a id="footnote-reference-7" class="footnote_reference" href="#zip-0200">8</a> Which is to say, each node in the tree commits to the consensus branch that produced it.</p>
|
||||
<p>Each MMR node is defined as follows:</p>
|
||||
<ol type="1">
|
||||
<li><code>hashSubtreeCommitment</code>
|
||||
|
|
@ -287,7 +287,7 @@ License: MIT</pre>
|
|||
<dt>Leaf node</dt>
|
||||
<dd>The protocol-defined work of the block:
|
||||
<span class="math">\(\mathsf{floor}(2^{256} / (\mathsf{ToTarget}(\mathsf{nBits}) + 1))\)</span>
|
||||
. <a id="id8" class="footnote_reference" href="#protocol-workdef">4</a></dd>
|
||||
. <a id="footnote-reference-8" class="footnote_reference" href="#protocol-workdef">4</a></dd>
|
||||
<dt>Internal or root node</dt>
|
||||
<dd>
|
||||
<p>The sum of the <code>nSubTreeTotalWork</code> fields of both children.</p>
|
||||
|
|
@ -357,7 +357,7 @@ License: MIT</pre>
|
|||
<p>Serialized as <code>CompactSize uint</code>.</p>
|
||||
</li>
|
||||
</ol>
|
||||
<p>The fields marked "[NU5 onward]" are omitted before NU5 activation <a id="id9" class="footnote_reference" href="#zip-0252">11</a>.</p>
|
||||
<p>The fields marked "[NU5 onward]" are omitted before NU5 activation <a id="footnote-reference-9" class="footnote_reference" href="#zip-0252">11</a>.</p>
|
||||
<p>Each node, when serialized, is between 147 and 171 bytes long (between 212 and 244 bytes after NU5 activation). The canonical serialized representation of a node is used whenever creating child commitments for future nodes. Other than the metadata commitments, the MMR tree's construction is standard.</p>
|
||||
<p>Once the MMR has been generated, we produce <code>hashChainHistoryRoot</code>, which we define as the BLAKE2b-256 digest of the serialization of the root node.</p>
|
||||
</section>
|
||||
|
|
@ -393,8 +393,8 @@ License: MIT</pre>
|
|||
<span class="k">def</span> <span class="nf">from_block</span><span class="p">(</span><span class="n">Z</span><span class="p">,</span> <span class="n">block</span><span class="p">:</span> <span class="n">ZcashBlock</span><span class="p">)</span> <span class="o">-></span> <span class="n">ZcashMMRNode</span><span class="p">:</span>
|
||||
<span class="sd">'''Create a leaf node from a block'''</span>
|
||||
<span class="k">return</span> <span class="n">Z</span><span class="p">(</span>
|
||||
<span class="n">left_child</span><span class="o">=</span><span class="bp">None</span><span class="p">,</span>
|
||||
<span class="n">right_child</span><span class="o">=</span><span class="bp">None</span><span class="p">,</span>
|
||||
<span class="n">left_child</span><span class="o">=</span><span class="kc">None</span><span class="p">,</span>
|
||||
<span class="n">right_child</span><span class="o">=</span><span class="kc">None</span><span class="p">,</span>
|
||||
<span class="n">hashSubtreeCommitment</span><span class="o">=</span><span class="n">block</span><span class="o">.</span><span class="n">header_hash</span><span class="p">,</span>
|
||||
<span class="n">nEarliestTimestamp</span><span class="o">=</span><span class="n">block</span><span class="o">.</span><span class="n">timestamp</span><span class="p">,</span>
|
||||
<span class="n">nLatestTimestamp</span><span class="o">=</span><span class="n">block</span><span class="o">.</span><span class="n">timestamp</span><span class="p">,</span>
|
||||
|
|
@ -424,7 +424,7 @@ License: MIT</pre>
|
|||
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nEarliestHeight</span><span class="p">)</span>
|
||||
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nLatestHeight</span><span class="p">)</span>
|
||||
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nSaplingTxCount</span><span class="p">))</span>
|
||||
<span class="k">if</span> <span class="n">hashEarliestOrchardRoot</span> <span class="ow">is</span> <span class="ow">not</span> <span class="bp">None</span><span class="p">:</span>
|
||||
<span class="k">if</span> <span class="n">hashEarliestOrchardRoot</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span><span class="p">:</span>
|
||||
<span class="n">buf</span> <span class="o">+=</span> <span class="p">(</span><span class="n">hashEarliestOrchardRoot</span>
|
||||
<span class="o">+</span> <span class="n">hashLatestOrchardRoot</span>
|
||||
<span class="o">+</span> <span class="n">serialize_compact_uint</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">nOrchardTxCount</span><span class="p">))</span>
|
||||
|
|
@ -452,8 +452,8 @@ License: MIT</pre>
|
|||
<span class="n">hashEarliestOrchardRoot</span><span class="o">=</span><span class="n">left_child</span><span class="o">.</span><span class="n">orchard_root</span><span class="p">,</span>
|
||||
<span class="n">hashLatestOrchardRoot</span><span class="o">=</span><span class="n">right_child</span><span class="o">.</span><span class="n">orchard_root</span><span class="p">,</span>
|
||||
<span class="n">nOrchardTxCount</span><span class="o">=</span><span class="p">(</span><span class="n">left_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="o">+</span> <span class="n">right_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span>
|
||||
<span class="k">if</span> <span class="n">left_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="bp">None</span> <span class="ow">and</span> <span class="n">right_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="bp">None</span>
|
||||
<span class="k">else</span> <span class="bp">None</span><span class="p">),</span>
|
||||
<span class="k">if</span> <span class="n">left_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span> <span class="ow">and</span> <span class="n">right_child</span><span class="o">.</span><span class="n">nOrchardTxCount</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span>
|
||||
<span class="k">else</span> <span class="kc">None</span><span class="p">),</span>
|
||||
<span class="n">consensusBranchId</span><span class="o">=</span><span class="n">left_child</span><span class="o">.</span><span class="n">consensusBranchId</span><span class="p">)</span>
|
||||
|
||||
<span class="k">def</span> <span class="nf">make_root_commitment</span><span class="p">(</span><span class="n">root</span><span class="p">:</span> <span class="n">ZcashMMRNode</span><span class="p">)</span> <span class="o">-></span> <span class="nb">bytes</span><span class="p">:</span>
|
||||
|
|
@ -465,7 +465,7 @@ License: MIT</pre>
|
|||
<span class="math">\(B_n\)</span>
|
||||
, we append a new MMR leaf node corresponding to block
|
||||
<span class="math">\(B_{n-1}\)</span>
|
||||
. The <code>append</code> operation is detailed below in pseudocode (adapted from <a id="id10" class="footnote_reference" href="#flyclient">2</a>):</p>
|
||||
. The <code>append</code> operation is detailed below in pseudocode (adapted from <a id="footnote-reference-10" class="footnote_reference" href="#flyclient">2</a>):</p>
|
||||
<pre data-language="python"><span class="k">def</span> <span class="nf">get_peaks</span><span class="p">(</span><span class="n">node</span><span class="p">:</span> <span class="n">ZcashMMRNode</span><span class="p">)</span> <span class="o">-></span> <span class="n">List</span><span class="p">[</span><span class="n">ZcashMMRNode</span><span class="p">]:</span>
|
||||
<span class="n">peaks</span><span class="p">:</span> <span class="n">List</span><span class="p">[</span><span class="n">ZcashMMRNode</span><span class="p">]</span> <span class="o">=</span> <span class="p">[]</span>
|
||||
|
||||
|
|
@ -553,9 +553,9 @@ License: MIT</pre>
|
|||
<span class="k">return</span> <span class="n">new_root</span></pre>
|
||||
</section>
|
||||
<section id="block-header-semantics-and-consensus-rules"><h3><span class="section-heading">Block header semantics and consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-semantics-and-consensus-rules"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The following specification is accurate before NU5 activation. See <a id="id11" class="footnote_reference" href="#zip-0244">9</a> for header field changes in NU5.</p>
|
||||
<p>The <code>hashFinalSaplingRoot</code> block header field (which was named <code>hashReserved</code> prior to the Sapling network upgrade) is renamed to <code>hashLightClientRoot</code>, to reflect its usage by light clients. (In NU5, this field is renamed again to <code>hashBlockCommitments</code> as specified in <a id="id12" class="footnote_reference" href="#zip-0244">9</a>.)</p>
|
||||
<p>Prior to activation of the network upgrade that deploys this ZIP, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: <a id="id13" class="footnote_reference" href="#protocol-blockheader">3</a></p>
|
||||
<p>The following specification is accurate before NU5 activation. See <a id="footnote-reference-11" class="footnote_reference" href="#zip-0244">9</a> for header field changes in NU5.</p>
|
||||
<p>The <code>hashFinalSaplingRoot</code> block header field (which was named <code>hashReserved</code> prior to the Sapling network upgrade) is renamed to <code>hashLightClientRoot</code>, to reflect its usage by light clients. (In NU5, this field is renamed again to <code>hashBlockCommitments</code> as specified in <a id="footnote-reference-12" class="footnote_reference" href="#zip-0244">9</a>.)</p>
|
||||
<p>Prior to activation of the network upgrade that deploys this ZIP, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: <a id="footnote-reference-13" class="footnote_reference" href="#protocol-blockheader">3</a></p>
|
||||
<blockquote>
|
||||
<p>[Sapling onward] <code>hashLightClientRoot</code> MUST be
|
||||
<span class="math">\(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\)</span>
|
||||
|
|
@ -625,7 +625,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="header-format-change"><h3><span class="section-heading">Header Format Change</span><span class="section-anchor"> <a rel="bookmark" href="#header-format-change"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary goal of the original authors was to minimize header changes; in particular, they preferred not to introduce changes that could affect mining hardware or embedded software. Altering the block header format would require changes throughout the ecosystem, so we decided against adding <code>hashChainHistoryRoot</code> to the header as a new field.</p>
|
||||
<p>ZIP 301 states that "[Miner client software] SHOULD alert the user upon receiving jobs containing block header versions they do not know about or support, and MUST ignore such jobs." <a id="id14" class="footnote_reference" href="#zip-0301">12</a> As the only formally defined block header version is 4, any header version change requires changes to miner client software in order for miners to handle new jobs from mining pools. We therefore do not alter the block version for this semantic change. This does not make block headers ambiguous to interpret, because blocks commit to their block height inside their coinbase transaction, <a id="id15" class="footnote_reference" href="#bip-0034">7</a> and they are never handled in a standalone context (unlike transactions, which exist in the mempool outside of blocks).</p>
|
||||
<p>ZIP 301 states that "[Miner client software] SHOULD alert the user upon receiving jobs containing block header versions they do not know about or support, and MUST ignore such jobs." <a id="footnote-reference-14" class="footnote_reference" href="#zip-0301">12</a> As the only formally defined block header version is 4, any header version change requires changes to miner client software in order for miners to handle new jobs from mining pools. We therefore do not alter the block version for this semantic change. This does not make block headers ambiguous to interpret, because blocks commit to their block height inside their coinbase transaction, <a id="footnote-reference-15" class="footnote_reference" href="#bip-0034">7</a> and they are never handled in a standalone context (unlike transactions, which exist in the mempool outside of blocks).</p>
|
||||
<p>Replacing <code>hashFinalSaplingRoot</code> with <code>hashChainHistoryRoot</code> does introduce the theoretical possibility of an attack where a miner constructs a Sapling commitment tree update that results in the same 32-byte value as the MMR root. We don't consider this a realistic attack, both because the adversary would need to find a preimage over 32 layers of Pedersen hash, and because light clients already need to update their code to include the consensus branch ID for the Heartwood network upgrade, and can simultaneously make changes to not rely on the value of this header field being the Sapling tree root.</p>
|
||||
<p>We also considered putting <code>hashChainHistoryRoot</code> in the <code>hashPrevBlock</code> field as it commits to the entire chain history, but quickly realized it would require massive refactoring of the existing code base and would negatively impact performance. Reorgs in particular are fragile, performance-critical, and rely on backwards iteration over the chain history. If a chain were to be designed from scratch there may be some efficient implementation that would join these commitments, but it is clearly not appropriate for Zcash as it exists.</p>
|
||||
<p>The calculation of <code>hashChainHistoryRoot</code> is not well-defined for the genesis block, since then
|
||||
|
|
@ -641,11 +641,11 @@ License: MIT</pre>
|
|||
<p>Generally, header commitments have no impact on privacy. However, FlyClient has additional security and privacy implications. Because FlyClient is a motivating factor for this ZIP, it seems prudent to include a brief overview. A more in-depth security analysis of FlyClient should be performed before designing a FlyClient-based light client ecosystem for Zcash.</p>
|
||||
<p>FlyClient, like all light clients, requires a connection to a light client server. That server may collect information about client requests, and may use that information to attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and publicly verifiable, they could be shared among many light clients after the initial server interaction.</p>
|
||||
<p>FlyClient proofs are probabilistic. When properly constructed, there is negligible probability that a dishonest chain commitment will be accepted by the verifier. The security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node and knows the genesis block.</p>
|
||||
<p>In addition, <a id="id16" class="footnote_reference" href="#flyclient">2</a> only analyses these security properties in chain models with slowly adjusting difficulty, such as Bitcoin. That paper leaves their analysis in chains with rapidly adjusting difficulty –such as Zcash or Ethereum– as an open problem, and states that the FlyClient protocol provides only heuristic security guarantees in that case. However, as mentioned in <a href="#flyclient-requirements-and-recommendations">FlyClient Requirements and Recommendations</a>, additional commitments allowing light clients to reason about application of the difficulty adjustment algorithm were added in discussion with an author of the FlyClient paper. The use of these fields has not been analysed in the academic security literature. It would be possible to update them in a future network upgrade if further security analysis were to find any deficiencies.</p>
|
||||
<p>In addition, <a id="footnote-reference-16" class="footnote_reference" href="#flyclient">2</a> only analyses these security properties in chain models with slowly adjusting difficulty, such as Bitcoin. That paper leaves their analysis in chains with rapidly adjusting difficulty –such as Zcash or Ethereum– as an open problem, and states that the FlyClient protocol provides only heuristic security guarantees in that case. However, as mentioned in <a href="#flyclient-requirements-and-recommendations">FlyClient Requirements and Recommendations</a>, additional commitments allowing light clients to reason about application of the difficulty adjustment algorithm were added in discussion with an author of the FlyClient paper. The use of these fields has not been analysed in the academic security literature. It would be possible to update them in a future network upgrade if further security analysis were to find any deficiencies.</p>
|
||||
</section>
|
||||
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>On the Zcash Mainnet and Testnet, this proposal will be deployed with the Heartwood network upgrade. <a id="id17" class="footnote_reference" href="#zip-0250">10</a></p>
|
||||
<p>Additional fields are added on activation of the NU5 network upgrade <a id="id18" class="footnote_reference" href="#zip-0252">11</a>, to support the new Orchard shielded protocol.</p>
|
||||
<p>On the Zcash Mainnet and Testnet, this proposal will be deployed with the Heartwood network upgrade. <a id="footnote-reference-17" class="footnote_reference" href="#zip-0250">10</a></p>
|
||||
<p>Additional fields are added on activation of the NU5 network upgrade <a id="footnote-reference-18" class="footnote_reference" href="#zip-0252">11</a>, to support the new Orchard shielded protocol.</p>
|
||||
</section>
|
||||
<section id="additional-reading"><h2><span class="section-heading">Additional Reading</span><span class="section-anchor"> <a rel="bookmark" href="#additional-reading"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -18,17 +18,17 @@ Category: Consensus
|
|||
Created: 2019-07-01
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">6</a>.</p>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">6</a>.</p>
|
||||
<p>The term "prefix-free" in this document is to be interpreted as to mean that no valid encoding of a value may have the same binary representation as any prefix of the binary encoding of another value of the same type.</p>
|
||||
<p>The term "non-malleable" in this document is to be interpreted as described in ZIP 244 <a id="id3" class="footnote_reference" href="#zip-0244">7</a>.</p>
|
||||
<p>The value <code>MAX_MONEY</code> is as defined in section 5.3 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-constants">3</a>.</p>
|
||||
<p>The term "non-malleable" in this document is to be interpreted as described in ZIP 244 <a id="footnote-reference-3" class="footnote_reference" href="#zip-0244">7</a>.</p>
|
||||
<p>The value <code>MAX_MONEY</code> is as defined in section 5.3 of the Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol-constants">3</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a modification to the consensus rules that enables complex forms of transparent output preconditions to be deployed in network upgrades. This in turn enables the creation of "transparent Zcash extensions" that augment the network's functionality in a carefully-defined and auditable fashion.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash supports a limited set of preconditions that may be imposed upon how funds, both transparent and shielded, may be spent. Spending limitations on transparent funds are defined by what may be encoded in Bitcoin script, and spending of shielded funds is even more restricted. As such, some use cases (for example, integration of BOLT support <a id="id5" class="footnote_reference" href="#zip-draft-bolt">9</a>) are not yet supportable.</p>
|
||||
<p>Zcash supports a limited set of preconditions that may be imposed upon how funds, both transparent and shielded, may be spent. Spending limitations on transparent funds are defined by what may be encoded in Bitcoin script, and spending of shielded funds is even more restricted. As such, some use cases (for example, integration of BOLT support <a id="footnote-reference-5" class="footnote_reference" href="#zip-draft-bolt">9</a>) are not yet supportable.</p>
|
||||
<p>Transparent Zcash Extensions are intended to make it possible to incrementally add new functionality without modifying interpretation of the existing Bitcoin script, which is complex and potentially error-prone. Extensions may also serve as laboratories for evaluating demand for functionality which may eventually be candidates for inclusion in the consensus rules for shielded transactions.</p>
|
||||
</section>
|
||||
<section id="definitions"><h2><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -249,7 +249,7 @@ License: MIT</pre>
|
|||
<li>Non-coinbase transactions MUST have at least one of the following: - nonempty transparent inputs - nonempty shielded inputs - nonempty <code>tze_inputs</code></li>
|
||||
</ul>
|
||||
<p>The above rule replaces <code>[Sapling onward] At least one of tx_in_count,
|
||||
nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="footnote_reference" href="#protocol-txnconsensus">4</a>.</p>
|
||||
nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="footnote-reference-6" class="footnote_reference" href="#protocol-txnconsensus">4</a>.</p>
|
||||
<ul>
|
||||
<li>Transactions MUST have at least one of the following: - nonempty transparent outputs - nonempty shielded outputs - nonempty <code>tze_outputs</code></li>
|
||||
<li>All <code>amount</code> field values of <code>tze_output</code> records MUST be nonnegative and not greater than <code>MAX_MONEY</code>.</li>
|
||||
|
|
@ -257,8 +257,8 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
|
|||
</ul>
|
||||
</section>
|
||||
<section id="changes-to-signatures-over-transaction-digests"><h3><span class="section-heading">Changes to signatures over transaction digests</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-signatures-over-transaction-digests"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This ZIP MUST be deployed in conjunction with or after ZIP 244 <a id="id7" class="footnote_reference" href="#zip-0244">7</a>, which defines new non-malleable transaction identifier and signature digest algorithms.</p>
|
||||
<p>The newly added parts of the transaction, excluding witness information (i.e. not the <code>witness</code> fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 <a id="id8" class="footnote_reference" href="#zip-0245">8</a> for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.</p>
|
||||
<p>This ZIP MUST be deployed in conjunction with or after ZIP 244 <a id="footnote-reference-7" class="footnote_reference" href="#zip-0244">7</a>, which defines new non-malleable transaction identifier and signature digest algorithms.</p>
|
||||
<p>The newly added parts of the transaction, excluding witness information (i.e. not the <code>witness</code> fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 <a id="footnote-reference-8" class="footnote_reference" href="#zip-0245">8</a> for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -277,8 +277,8 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
|
|||
</section>
|
||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Librustzcash reference implementation of TZE API: <a id="id9" class="footnote_reference" href="#librustzcash-zip222">10</a></li>
|
||||
<li>Zcashd reference implementation of consensus rule changes: <a id="id10" class="footnote_reference" href="#zcashd-zip222">11</a></li>
|
||||
<li>Librustzcash reference implementation of TZE API: <a id="footnote-reference-9" class="footnote_reference" href="#librustzcash-zip222">10</a></li>
|
||||
<li>Zcashd reference implementation of consensus rule changes: <a id="footnote-reference-10" class="footnote_reference" href="#zcashd-zip222">11</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -20,8 +20,8 @@ Created: 2021-02-27
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://github.com/zcash/zips/issues/435</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-networks">5</a>.</p>
|
||||
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol-networks">5</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This document proposes the Orchard shielded protocol, which defines a new shielded pool with spending keys and payment addresses that are amenable to future scalability improvements.</p>
|
||||
|
|
@ -29,18 +29,18 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash currently has two active shielded protocols and associated shielded pools:</p>
|
||||
<ul>
|
||||
<li>The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes <a id="id3" class="footnote_reference" href="#protocol-differences">21</a>), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.</li>
|
||||
<li>The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes <a id="footnote-reference-3" class="footnote_reference" href="#protocol-differences">21</a>), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.</li>
|
||||
<li>The Sapling shielded protocol, which consisted of numerous improvements to functionality and improved performance by orders of magnitude, and as of Feburary 2021 is the "active" shielded pool.</li>
|
||||
</ul>
|
||||
<p>Both of these shielded protocols suffer from two issues:</p>
|
||||
<ul>
|
||||
<li>Neither Sprout nor Sapling are compatible with known efficient scalability techniques. Recursive zero-knowledge proofs (where a proof verifies an earlier instance of itself along with new state) that are suitable for deployment in a block chain like Zcash require a cycle of elliptic curves. The Sprout protocol does not use elliptic curves and thus is an inherently inefficient protocol to implement inside a circuit, while the Sapling protocol uses curves for which there is no known way to construct an efficient curve cycle (or path to one).</li>
|
||||
<li>The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later <a id="id4" class="footnote_reference" href="#zcash-paramgen">2</a>), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, <a id="id5" class="footnote_reference" href="#bctv14-vuln">3</a> which needed to be resolved by changing the proving system and running a new MPC.</li>
|
||||
<li>The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later <a id="footnote-reference-4" class="footnote_reference" href="#zcash-paramgen">2</a>), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, <a id="footnote-reference-5" class="footnote_reference" href="#bctv14-vuln">3</a> which needed to be resolved by changing the proving system and running a new MPC.</li>
|
||||
</ul>
|
||||
<p>We are thus motivated to deploy a new shielded protocol designed around a curve cycle, using a proving system that is both amenable to recursion and does not require an SRS.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-orchard">4</a>.</p>
|
||||
<p>The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification <a id="footnote-reference-6" class="footnote_reference" href="#protocol-orchard">4</a>.</p>
|
||||
<p>Given that the Orchard protocol largely follows the design of the Sapling protocol, we provide here a list of differences, with references to their normative specifications and associated design rationale.</p>
|
||||
<section id="curves"><h3><span class="section-heading">Curves</span><span class="section-anchor"> <a rel="bookmark" href="#curves"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its embedded curve Jubjub:</p>
|
||||
|
|
@ -50,41 +50,41 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
</ul>
|
||||
<p>We use the "simplified SWU" algorithm to define an infallible
|
||||
<span class="math">\(\mathsf{GroupHash}\)</span>
|
||||
, instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft <a id="id7" class="footnote_reference" href="#ietf-hash-to-curve">33</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
|
||||
, instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft <a id="footnote-reference-7" class="footnote_reference" href="#ietf-hash-to-curve">33</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
|
||||
<p>The presence of the curve cycle is an explicit design choice. This proposal only uses half of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future protocol updates.</p>
|
||||
<ul>
|
||||
<li>Curve specifications: <a id="id8" class="footnote_reference" href="#protocol-pallasandvesta">15</a></li>
|
||||
<li>Curve specifications: <a id="footnote-reference-8" class="footnote_reference" href="#protocol-pallasandvesta">15</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{GroupHash}\)</span>
|
||||
: <a id="id9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">16</a></li>
|
||||
<li>Supporting evidence: <a id="id10" class="footnote_reference" href="#pasta-evidence">34</a></li>
|
||||
: <a id="footnote-reference-9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">16</a></li>
|
||||
<li>Supporting evidence: <a id="footnote-reference-10" class="footnote_reference" href="#pasta-evidence">34</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="proving-system"><h3><span class="section-heading">Proving system</span><span class="section-anchor"> <a rel="bookmark" href="#proving-system"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard uses the Halo 2 proving system <a id="id11" class="footnote_reference" href="#halo2-proving-system">23</a> with the PLONKish arithmetization <a id="id12" class="footnote_reference" href="#halo2-arithmetization">22</a>, instead of Groth16 and R1CS.</p>
|
||||
<p>Orchard uses the Halo 2 proving system <a id="footnote-reference-11" class="footnote_reference" href="#halo2-proving-system">23</a> with the PLONKish arithmetization <a id="footnote-reference-12" class="footnote_reference" href="#halo2-arithmetization">22</a>, instead of Groth16 and R1CS.</p>
|
||||
<p>This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates.</p>
|
||||
</section>
|
||||
<section id="circuit"><h3><span class="section-heading">Circuit</span><span class="section-anchor"> <a rel="bookmark" href="#circuit"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard uses a single circuit for both spends and outputs, similar to Sprout. An "action" contains both a single (possibly dummy) note being spent, and a single (possibly dummy) note being created.</p>
|
||||
<p>An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that covers all of the actions in the bundle.</p>
|
||||
<ul>
|
||||
<li>Action description: <a id="id13" class="footnote_reference" href="#protocol-actions">8</a></li>
|
||||
<li>Circuit statement: <a id="id14" class="footnote_reference" href="#protocol-actionstatement">9</a></li>
|
||||
<li>Design rationale: <a id="id15" class="footnote_reference" href="#orchard-actions">25</a></li>
|
||||
<li>Action description: <a id="footnote-reference-13" class="footnote_reference" href="#protocol-actions">8</a></li>
|
||||
<li>Circuit statement: <a id="footnote-reference-14" class="footnote_reference" href="#protocol-actionstatement">9</a></li>
|
||||
<li>Design rationale: <a id="footnote-reference-15" class="footnote_reference" href="#orchard-actions">25</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="commitments"><h3><span class="section-heading">Commitments</span><span class="section-anchor"> <a rel="bookmark" href="#commitments"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the PLONKish-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.</p>
|
||||
<ul>
|
||||
<li>Sinsemilla hash function: <a id="id16" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
|
||||
<li>Sinsemilla commitments: <a id="id17" class="footnote_reference" href="#protocol-concretesinsemillacommit">14</a></li>
|
||||
<li>Design rationale: <a id="id18" class="footnote_reference" href="#orchard-commitments">26</a></li>
|
||||
<li>Sinsemilla hash function: <a id="footnote-reference-16" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
|
||||
<li>Sinsemilla commitments: <a id="footnote-reference-17" class="footnote_reference" href="#protocol-concretesinsemillacommit">14</a></li>
|
||||
<li>Design rationale: <a id="footnote-reference-18" class="footnote_reference" href="#orchard-commitments">26</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="commitment-tree"><h3><span class="section-heading">Commitment tree</span><span class="section-anchor"> <a rel="bookmark" href="#commitment-tree"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe–Hopwood Pedersen hash.</p>
|
||||
<ul>
|
||||
<li>Design rationale and considered alternatives: <a id="id19" class="footnote_reference" href="#orchard-tree">27</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="footnote-reference-19" class="footnote_reference" href="#orchard-tree">27</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="keys-and-addresses"><h3><span class="section-heading">Keys and addresses</span><span class="section-anchor"> <a rel="bookmark" href="#keys-and-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -105,14 +105,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
, instead of being a component of the spending key.</li>
|
||||
<li>All diversifiers now result in valid payment addresses.</li>
|
||||
</ul>
|
||||
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="id20" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="id21" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a>.</p>
|
||||
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="footnote-reference-20" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="footnote-reference-21" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a>.</p>
|
||||
<p>Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).</p>
|
||||
<ul>
|
||||
<li>Key components diagram: <a id="id22" class="footnote_reference" href="#protocol-addressesandkeys">6</a></li>
|
||||
<li>Key components specification: <a id="id23" class="footnote_reference" href="#protocol-orchardkeycomponents">10</a></li>
|
||||
<li>Encodings: <a id="id24" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">17</a> <a id="id25" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">18</a> <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">19</a> <a id="id27" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a></li>
|
||||
<li>HD key derivation specification: <a id="id28" class="footnote_reference" href="#zip-0032">29</a></li>
|
||||
<li>Design rationale: <a id="id29" class="footnote_reference" href="#orchard-keys">24</a></li>
|
||||
<li>Key components diagram: <a id="footnote-reference-22" class="footnote_reference" href="#protocol-addressesandkeys">6</a></li>
|
||||
<li>Key components specification: <a id="footnote-reference-23" class="footnote_reference" href="#protocol-orchardkeycomponents">10</a></li>
|
||||
<li>Encodings: <a id="footnote-reference-24" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">17</a> <a id="footnote-reference-25" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">18</a> <a id="footnote-reference-26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">19</a> <a id="footnote-reference-27" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a></li>
|
||||
<li>HD key derivation specification: <a id="footnote-reference-28" class="footnote_reference" href="#zip-0032">29</a></li>
|
||||
<li>Design rationale: <a id="footnote-reference-29" class="footnote_reference" href="#orchard-keys">24</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a rel="bookmark" href="#notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -123,9 +123,9 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
<span class="math">\(\psi\)</span>
|
||||
and
|
||||
<span class="math">\(\mathsf{rcm}\)</span>
|
||||
are derived from a random seed (as with Sapling after ZIP 212 <a id="id30" class="footnote_reference" href="#zip-0212">30</a>).</p>
|
||||
are derived from a random seed (as with Sapling after ZIP 212 <a id="footnote-reference-30" class="footnote_reference" href="#zip-0212">30</a>).</p>
|
||||
<ul>
|
||||
<li>Orchard notes: <a id="id31" class="footnote_reference" href="#protocol-notes">7</a></li>
|
||||
<li>Orchard notes: <a id="footnote-reference-31" class="footnote_reference" href="#protocol-notes">7</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="nullifiers"><h3><span class="section-heading">Nullifiers</span><span class="section-anchor"> <a rel="bookmark" href="#nullifiers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -139,14 +139,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
<span class="math">\(\mathcal{G}\)</span>
|
||||
is a fixed independent base.</p>
|
||||
<ul>
|
||||
<li>Poseidon: <a id="id32" class="footnote_reference" href="#protocol-poseidonhash">12</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="id33" class="footnote_reference" href="#orchard-nullifiers">28</a></li>
|
||||
<li>Poseidon: <a id="footnote-reference-32" class="footnote_reference" href="#protocol-poseidonhash">12</a></li>
|
||||
<li>Design rationale and considered alternatives: <a id="footnote-reference-33" class="footnote_reference" href="#orchard-nullifiers">28</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="signatures"><h3><span class="section-heading">Signatures</span><span class="section-anchor"> <a rel="bookmark" href="#signatures"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).</p>
|
||||
<ul>
|
||||
<li>RedPallas: <a id="id34" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
|
||||
<li>RedPallas: <a id="footnote-reference-34" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -166,7 +166,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/435">https://g
|
|||
field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.</li>
|
||||
<li>Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
|
||||
<ul>
|
||||
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="id35" class="footnote_reference" href="#zip-0315">31</a></li>
|
||||
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="footnote-reference-35" class="footnote_reference" href="#zip-0315">31</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -20,12 +20,12 @@ Created: 2021-02-28
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://github.com/zcash/zips/issues/440</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The character § is used when referring to sections of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The character § is used when referring to sections of the Zcash Protocol Specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol <a id="id3" class="footnote_reference" href="#protocol">2</a>. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.</p>
|
||||
<p>This ZIP also depends upon and defines modifications to the computation of the values <strong>TxId Digest</strong>, <strong>Signature Digest</strong>, and <strong>Authorizing Data Commitment</strong> defined by ZIP 244 <a id="id4" class="footnote_reference" href="#zip-0244">7</a>.</p>
|
||||
<p>This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol <a id="footnote-reference-3" class="footnote_reference" href="#protocol">2</a>. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.</p>
|
||||
<p>This ZIP also depends upon and defines modifications to the computation of the values <strong>TxId Digest</strong>, <strong>Signature Digest</strong>, and <strong>Authorizing Data Commitment</strong> defined by ZIP 244 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0244">7</a>.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The new Orchard shielded pool requires serialized data elements that are distinct from any previous Zcash transaction. In addition, with the activation of ZIP 244, the serialized transaction format will no longer be consensus-critical. It makes sense at this point to define a format that can readily accommodate future extension in a systematic fashion, where elements required for support for a given pool are kept separate.</p>
|
||||
|
|
@ -262,7 +262,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://g
|
|||
<li>The fields <code>valueBalanceSapling</code> and <code>bindingSigSapling</code> are present if and only if
|
||||
<span class="math">\(\mathtt{nSpendsSapling} + \mathtt{nOutputsSapling} > 0\)</span>
|
||||
. If <code>valueBalanceSapling</code> is not present, then
|
||||
<span class="math">\(\mathsf{v^{balanceSapling}}\)</span>
|
||||
<span class="math">\(\mathsf{v^{balanceSapling}}`\)</span>
|
||||
is defined to be 0.</li>
|
||||
<li>The field <code>anchorSapling</code> is present if and only if
|
||||
<span class="math">\(\mathtt{nSpendsSapling} > 0\)</span>
|
||||
|
|
@ -310,7 +310,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://g
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-spenddesc">3</a>.</p>
|
||||
<p>The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol-spenddesc">3</a>.</p>
|
||||
</section>
|
||||
<section id="sapling-output-description-outputdescriptionv5"><h3><span class="section-heading">Sapling Output Description (<code>OutputDescriptionV5</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-output-description-outputdescriptionv5"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<table>
|
||||
|
|
@ -355,7 +355,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://g
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-outputdesc">4</a>.</p>
|
||||
<p>The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="footnote-reference-6" class="footnote_reference" href="#protocol-outputdesc">4</a>.</p>
|
||||
</section>
|
||||
<section id="orchard-action-description-orchardaction"><h3><span class="section-heading">Orchard Action Description (<code>OrchardAction</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-action-description-orchardaction"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<table>
|
||||
|
|
@ -412,7 +412,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://g
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-actiondesc">5</a>.</p>
|
||||
<p>The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification <a id="footnote-reference-7" class="footnote_reference" href="#protocol-actiondesc">5</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="alternatives"><h2><span class="section-heading">Alternatives</span><span class="section-anchor"> <a rel="bookmark" href="#alternatives"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -423,9 +423,9 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://g
|
|||
<p>Removing these fields reduces the complexity of the NU5 upgrade in the following ways:</p>
|
||||
<ul>
|
||||
<li>V5 parsing and serialization code does not need to take these fields into account.</li>
|
||||
<li>ZIP 244 <a id="id8" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
|
||||
<li>ZIP 244 <a id="footnote-reference-8" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
|
||||
</ul>
|
||||
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="id9" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
|
||||
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="footnote-reference-9" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
|
||||
<p>The original definitions for the transaction fields that have been removed are:</p>
|
||||
<table>
|
||||
<tbody>
|
||||
|
|
|
|||
|
|
@ -17,11 +17,11 @@ License: MIT
|
|||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/515">https://github.com/zcash/zips/issues/515</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/516">https://github.com/zcash/zips/pull/516</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
<p>The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in <a id="id4" class="footnote_reference" href="#zip-0244">6</a> for v5 and later transactions.</p>
|
||||
<p>The term "authorizing data commitment" (denoted <code>auth_digest</code>), defined only for v5 and later transactions, is to be interpreted as described in <a id="id5" class="footnote_reference" href="#zip-0244">6</a>.</p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">4</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
|
||||
<p>The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in <a id="footnote-reference-4" class="footnote_reference" href="#zip-0244">6</a> for v5 and later transactions.</p>
|
||||
<p>The term "authorizing data commitment" (denoted <code>auth_digest</code>), defined only for v5 and later transactions, is to be interpreted as described in <a id="footnote-reference-5" class="footnote_reference" href="#zip-0244">6</a>.</p>
|
||||
<p>The term "witnessed transaction identifier" ("wtxid"), defined only for v5 and later transactions, is a 64-byte value given by concatenating the txid and the authorizing data commitment of the transaction.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -29,23 +29,23 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/516">https://githu
|
|||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Historically, as in Bitcoin, the <code>inv</code> and <code>getdata</code> messages sent on the Zcash peer-to-peer network to announce or request transactions have referred to those transactions by txid.</p>
|
||||
<p>Prior to the introduction of v5 transactions <a id="id6" class="footnote_reference" href="#zip-0225">5</a> in the NU5 network upgrade <a id="id7" class="footnote_reference" href="#zip-0252">7</a>, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.</p>
|
||||
<p>For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data <a id="id8" class="footnote_reference" href="#zip-0244">6</a>. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.</p>
|
||||
<p>Prior to the introduction of v5 transactions <a id="footnote-reference-6" class="footnote_reference" href="#zip-0225">5</a> in the NU5 network upgrade <a id="footnote-reference-7" class="footnote_reference" href="#zip-0252">7</a>, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.</p>
|
||||
<p>For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data <a id="footnote-reference-8" class="footnote_reference" href="#zip-0244">6</a>. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.</p>
|
||||
<p>Not committing to the witness data in v5 transaction announcements would create inefficiencies: because a v5 transaction's witness can be malleated without altering the txid, a node in receipt of a v5 transaction that the node does not accept would generally still have to download that same transaction when announced by other peers. This is because the alternative — of not downloading a v5 transaction with a given txid after rejecting a previous transaction with that txid — would allow a third party to interfere with transaction relay by malleating a transaction's witness and announcing the resulting invalid transaction to nodes, preventing relay of the valid version of the transaction as well.</p>
|
||||
<p>This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade <a id="id9" class="footnote_reference" href="#bip-0141">8</a>, until the adoption of BIP 339 <a id="id10" class="footnote_reference" href="#bip-0339">9</a>. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is also called the wtxid, but it encodes the pair (txid, auth_digest).</p>
|
||||
<p>This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade <a id="footnote-reference-9" class="footnote_reference" href="#bip-0141">8</a>, until the adoption of BIP 339 <a id="footnote-reference-10" class="footnote_reference" href="#bip-0339">9</a>. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is also called the wtxid, but it encodes the pair (txid, auth_digest).</p>
|
||||
<p>This ZIP is modelled after BIP 339: it adds a <code>MSG_WTX</code> inv type to the peer-to-peer protocol, analogous to BIP 339's <code>MSG_WTX</code> inv type, that announces transactions by their wtxid. Note that the encoding and length of a Zcash wtxid is different to that of a Bitcoin wtxid.</p>
|
||||
<p>This ZIP does not introduce any equivalent of BIP 339's <code>wtxidrelay</code> message, since that is not needed for compatibility given that Zcash full nodes are required to support <code>MSG_WTX</code> based on the negotiated peer protocol version (see <a href="#deployment">Deployment</a>).</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A new inv type <code>MSG_WTX</code> (0x00000005) is added, for use in both <code>inv</code> messages and <code>getdata</code> requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value <code>txid</code> || <code>auth_digest</code>). This inv type MUST be used when announcing v5 transactions. The <code>txid</code> and <code>auth_digest</code> are as defined in <a id="id11" class="footnote_reference" href="#zip-0244">6</a>.</p>
|
||||
<p>In the case of <code>getdata</code> requests, the format of a v5 transaction obtained by a <code>MSG_WTX</code> inv type is as given in the Zcash protocol specification. <a id="id12" class="footnote_reference" href="#protocol-txnencoding">3</a></p>
|
||||
<p>A new inv type <code>MSG_WTX</code> (0x00000005) is added, for use in both <code>inv</code> messages and <code>getdata</code> requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value <code>txid</code> || <code>auth_digest</code>). This inv type MUST be used when announcing v5 transactions. The <code>txid</code> and <code>auth_digest</code> are as defined in <a id="footnote-reference-11" class="footnote_reference" href="#zip-0244">6</a>.</p>
|
||||
<p>In the case of <code>getdata</code> requests, the format of a v5 transaction obtained by a <code>MSG_WTX</code> inv type is as given in the Zcash protocol specification. <a id="footnote-reference-12" class="footnote_reference" href="#protocol-txnencoding">3</a></p>
|
||||
<p>An <code>inv</code> or <code>getdata</code> message MUST NOT use the <code>MSG_WTX</code> inv type for v4 or earlier transactions, or on peer connections that have not negotiated at least the peer protocol version specified in <a href="#deployment">Deployment</a>.</p>
|
||||
<p>Note that <code>MSG_WTX</code> might also be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified for now.</p>
|
||||
<p><code>MSG_TX</code> and <code>MSG_WTX</code> entries may be mixed in arbitrary order in an <code>inv</code> message or a <code>getdata</code> message. Since these entry types are of different lengths (36 bytes or 68 bytes respectively including the 4-byte type field), this implies that the size of the message is not determined by its initial <code>count</code> field, and has to be determined by parsing the whole message.</p>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5.</p>
|
||||
<p>The peer protocol version that enables support for this specification is defined to be 170014 (on both Testnet and Mainnet). This is in advance of the minimum protocol version that signals support for NU5 on Testnet. <a id="id13" class="footnote_reference" href="#zip-0252">7</a></p>
|
||||
<p>As specified in <a id="id14" class="footnote_reference" href="#zip-0200">4</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
|
||||
<p>The peer protocol version that enables support for this specification is defined to be 170014 (on both Testnet and Mainnet). This is in advance of the minimum protocol version that signals support for NU5 on Testnet. <a id="footnote-reference-13" class="footnote_reference" href="#zip-0252">7</a></p>
|
||||
<p>As specified in <a id="footnote-reference-14" class="footnote_reference" href="#zip-0200">4</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
|
||||
<p>Nevertheless, it is possible for a node to receive an <code>inv</code> or <code>getdata</code> message containing an inventory entry of type <code>MSG_WTX</code>, on a peer connection that has negotiated protocol version 170014 or later, before NU5 has activated. In this case, the node MUST NOT advertise, fetch, or provide v5 transactions.</p>
|
||||
<p>Note that the behaviour of a node receiving an <code>inv</code> or <code>getdata</code> message with one or more inventory entries of an unrecognized type was previously unspecified. The behaviour of <cite>zcashd</cite> in such a case was to assume that the length of each inventory entry is 36 bytes (including the type field), regardless of the type. This would result in misparsing the <code>inv</code> or <code>getdata</code> message if the length of the corresponding inventory entry were not 36 bytes.</p>
|
||||
<p>The RECOMMENDED behaviour is to parse the <code>inv</code> or <code>getdata</code> message completely, and reject the message if it contains any inventory entries of an unrecognized type. For a <code>getdata</code> message, the set of recognized inventory types, and corresponding entry lengths including the type field, is:</p>
|
||||
|
|
@ -57,15 +57,15 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/516">https://githu
|
|||
</ul>
|
||||
<p>For an <code>inv</code> message, the set of recognized inventory types is the same, but the <code>MSG_FILTERED_BLOCK</code> type has no useful purpose. Senders of <code>inv</code> messages SHOULD NOT include <code>MSG_FILTERED_BLOCK</code> entries. In order to allow using the same parser for the two message types, a node receiving a <code>MSG_FILTERED_BLOCK</code> entry in an <code>inv</code> message SHOULD ignore it.</p>
|
||||
<p>As the <code>MSG_WTX</code> inv type is only enabled between peers that both support it, older clients remain fully compatible and interoperable before NU5 activates, or on a chain in which it does not activate.</p>
|
||||
<p>Further information on how <cite>zcashd</cite> handles data propagation in the peer-to-peer network is given in <a id="id15" class="footnote_reference" href="#zcashd-propagation">12</a>.</p>
|
||||
<p>Further information on how <cite>zcashd</cite> handles data propagation in the peer-to-peer network is given in <a id="footnote-reference-15" class="footnote_reference" href="#zcashd-propagation">12</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A previous draft of this ZIP left as an open question whether to redefine <code>inv</code> and <code>getdata</code> to segregate <code>MSG_TX</code> and <code>MSG_WTX</code>. This could potentially have made these messages simpler or more efficient to parse, by avoiding variable-length entries in the message data. (See <a id="id16" class="footnote_reference" href="#p2p-inv">10</a> and <a id="id17" class="footnote_reference" href="#p2p-getdata">11</a> for how <code>inv</code> and <code>getdata</code> respectively are currently defined in Bitcoin.)</p>
|
||||
<p>A previous draft of this ZIP left as an open question whether to redefine <code>inv</code> and <code>getdata</code> to segregate <code>MSG_TX</code> and <code>MSG_WTX</code>. This could potentially have made these messages simpler or more efficient to parse, by avoiding variable-length entries in the message data. (See <a id="footnote-reference-16" class="footnote_reference" href="#p2p-inv">10</a> and <a id="footnote-reference-17" class="footnote_reference" href="#p2p-getdata">11</a> for how <code>inv</code> and <code>getdata</code> respectively are currently defined in Bitcoin.)</p>
|
||||
<p>This option was rejected because the current specification is simple enough.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is partly based on BIP 339, written by Suhas Daftuar. <a id="id18" class="footnote_reference" href="#bip-0339">9</a></p>
|
||||
<p>This ZIP is partly based on BIP 339, written by Suhas Daftuar. <a id="footnote-reference-18" class="footnote_reference" href="#bip-0339">9</a></p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
|
|
|
|||
216
zip-0243.html
216
zip-0243.html
File diff suppressed because one or more lines are too long
|
|
@ -18,9 +18,9 @@ Created: 2021-01-06
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/411">https://github.com/zcash/zips/issues/411</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">2</a>.</p>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-txnencoding">2</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines a new transaction digest algorithm for the NU5 network upgrade onward, in order to introduce non-malleable transaction identifiers that commit to all transaction data except for attestations to transaction validity.</p>
|
||||
|
|
@ -75,7 +75,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/411">https://g
|
|||
├── valueBalanceOrchard
|
||||
└── anchorOrchard</pre>
|
||||
<p>Each node written as <code>snake_case</code> in this tree is a BLAKE2b-256 hash of its children, initialized with a personalization string specific to that branch of the tree. Nodes that are not themselves digests are written in <code>camelCase</code>. In the specification below, nodes of the tree are presented in depth-first order.</p>
|
||||
<section id="id4"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id4"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<section id="txid-digest-1"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<p>A BLAKE2b-256 hash of the following values</p>
|
||||
<pre>T.1: header_digest (32-byte hash output)
|
||||
T.2: transparent_digest (32-byte hash output)
|
||||
|
|
@ -84,7 +84,7 @@ T.4: orchard_digest (32-byte hash output)</pre>
|
|||
<p>The personalization field of this hash is set to:</p>
|
||||
<pre>"ZcashTxHash_" || CONSENSUS_BRANCH_ID</pre>
|
||||
<p><code>ZcashTxHash_</code> has 1 underscore character.</p>
|
||||
<p>As in ZIP 143 <a id="id5" class="footnote_reference" href="#zip-0143">6</a>, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.</p>
|
||||
<p>As in ZIP 143 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0143">6</a>, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.</p>
|
||||
<p>This signature hash personalization prefix has been changed to reflect the new role of this hash (relative to <code>ZcashSigHash</code> as specified in ZIP 143) as a transaction identifier rather than a commitment that is exclusively used for signature purposes. The previous computation of the transaction identifier was a SHA256d hash of the serialized transaction contents, and was not personalized.</p>
|
||||
<section id="t-1-header-digest"><h6><span class="section-heading">T.1: header_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-1-header-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
|
||||
<p>A BLAKE2b-256 hash of the following values</p>
|
||||
|
|
@ -128,7 +128,7 @@ T.2c: outputs_digest (32-byte hash)</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="t-3-sapling-digest"><h6><span class="section-heading">T.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3-sapling-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
|
||||
<p>In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the <code>CompactBlock</code> representation of Sapling data specified by the ZIP 307 Light Client Protocol <a id="id6" class="footnote_reference" href="#zip-0307">8</a>.</p>
|
||||
<p>In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the <code>CompactBlock</code> representation of Sapling data specified by the ZIP 307 Light Client Protocol <a id="footnote-reference-5" class="footnote_reference" href="#zip-0307">8</a>.</p>
|
||||
<p>This digest is a BLAKE2b-256 hash of the following values</p>
|
||||
<pre>T.3a: sapling_spends_digest (32-byte hash)
|
||||
T.3b: sapling_outputs_digest (32-byte hash)
|
||||
|
|
@ -170,7 +170,7 @@ T.3b.iii: sapling_outputs_noncompact_digest (32-byte hash)</pre>
|
|||
<p>In the case that the transaction has Sapling spends but no Sapling outputs, <code>sapling_outputs_digest</code> is</p>
|
||||
<pre>BLAKE2b-256("ZTxIdSOutputHash", [])</pre>
|
||||
<section id="t-3b-i-sapling-outputs-compact-digest"><h8><span class="section-heading">T.3b.i: sapling_outputs_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-i-sapling-outputs-compact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h8>
|
||||
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="id7" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
|
||||
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="footnote-reference-6" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
|
||||
<pre>T.3b.i.1: cmu (field encoding bytes)
|
||||
T.3b.i.2: ephemeral_key (field encoding bytes)
|
||||
T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
|
||||
|
|
@ -184,7 +184,7 @@ T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
|
|||
<pre>"ZTxIdSOutM__Hash" (2 underscore characters)</pre>
|
||||
</section>
|
||||
<section id="t-3b-iii-sapling-outputs-noncompact-digest"><h8><span class="section-heading">T.3b.iii: sapling_outputs_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-iii-sapling-outputs-noncompact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h8>
|
||||
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="id8" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
|
||||
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="footnote-reference-7" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
|
||||
<pre>T.3b.iii.1: cv (field encoding bytes)
|
||||
T.3b.iii.2: enc_ciphertext[564..] (post-memo Poly1305 AEAD tag of field encoding)
|
||||
T.3b.iii.3: out_ciphertext (field encoding bytes)</pre>
|
||||
|
|
@ -206,7 +206,7 @@ T.4f: anchorOrchard (32 bytes)</pre>
|
|||
<p>In the case that the transaction has no Orchard actions, <code>orchard_digest</code> is</p>
|
||||
<pre>BLAKE2b-256("ZTxIdOrchardHash", [])</pre>
|
||||
<section id="t-4a-orchard-actions-compact-digest"><h7><span class="section-heading">T.4a: orchard_actions_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4a-orchard-actions-compact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
|
||||
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id9" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
|
||||
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="footnote-reference-8" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
|
||||
<pre>T.4a.i : nullifier (field encoding bytes)
|
||||
T.4a.ii : cmx (field encoding bytes)
|
||||
T.4a.iii: ephemeralKey (field encoding bytes)
|
||||
|
|
@ -221,7 +221,7 @@ T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)</pre>
|
|||
<pre>"ZTxIdOrcActMHash"</pre>
|
||||
</section>
|
||||
<section id="t-4c-orchard-actions-noncompact-digest"><h7><span class="section-heading">T.4c: orchard_actions_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4c-orchard-actions-noncompact-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
|
||||
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id10" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
|
||||
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="footnote-reference-9" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
|
||||
<pre>T.4c.i : cv (field encoding bytes)
|
||||
T.4c.ii : rk (field encoding bytes)
|
||||
T.4c.iii: encCiphertext[564..] (post-memo suffix of field encoding)
|
||||
|
|
@ -233,14 +233,14 @@ T.4c.iv : outCiphertext (field encoding bytes)</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="signature-digest"><h4><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 <a id="id11" class="footnote_reference" href="#zip-0143">6</a> and ZIP 243 <a id="id12" class="footnote_reference" href="#zip-0243">7</a>. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.</p>
|
||||
<p>A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 <a id="footnote-reference-10" class="footnote_reference" href="#zip-0143">6</a> and ZIP 243 <a id="footnote-reference-11" class="footnote_reference" href="#zip-0243">7</a>. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.</p>
|
||||
<p>The overall structure of the hash is as follows; each name referenced here will be described in detail below:</p>
|
||||
<pre>signature_digest
|
||||
├── header_digest
|
||||
├── transparent_sig_digest
|
||||
├── sapling_digest
|
||||
└── orchard_digest</pre>
|
||||
<section id="id13"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id13"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<section id="signature-digest-1"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
|
||||
<p>A BLAKE2b-256 hash of the following values</p>
|
||||
<pre>S.1: header_digest (32-byte hash output)
|
||||
S.2: transparent_sig_digest (32-byte hash output)
|
||||
|
|
@ -284,14 +284,14 @@ transaction identifier in section T.2a.</pre>
|
|||
<pre>BLAKE2b-256(``ZTxIdPrevoutHash``, [])</pre>
|
||||
</section>
|
||||
<section id="s-2c-amounts-sig-digest"><h7><span class="section-heading">S.2c: amounts_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2c-amounts-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
|
||||
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>amounts_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all <code>value</code> fields <a id="id14" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
|
||||
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>amounts_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the 8-byte signed little-endian representations of all <code>value</code> fields <a id="footnote-reference-12" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
|
||||
<p>The personalization field of this hash is set to:</p>
|
||||
<pre>"ZTxTrAmountsHash"</pre>
|
||||
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is set, <code>amounts_sig_digest</code> is:</p>
|
||||
<pre>BLAKE2b-256("ZTxTrAmountsHash", [])</pre>
|
||||
</section>
|
||||
<section id="s-2d-scriptpubkeys-sig-digest"><h7><span class="section-heading">S.2d: scriptpubkeys_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2d-scriptpubkeys-sig-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h7>
|
||||
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>scriptpubkeys_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading <code>CompactSize</code>) of all <code>pk_script</code> fields <a id="id15" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
|
||||
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is not set, the value of <code>scriptpubkeys_sig_digest</code> is a BLAKE2b-256 hash of the concatenation of the field encodings (each including a leading <code>CompactSize</code>) of all <code>pk_script</code> fields <a id="footnote-reference-13" class="footnote_reference" href="#bdr-txout">14</a> for the coins spent by the transparent inputs to the transaction.</p>
|
||||
<p>The personalization field of this hash is set to:</p>
|
||||
<pre>"ZTxTrScriptsHash"</pre>
|
||||
<p>If the <code>SIGHASH_ANYONECANPAY</code> flag is set, <code>scriptpubkeys_sig_digest</code> is:</p>
|
||||
|
|
@ -325,7 +325,7 @@ S.2g.iv: nSequence (4-byte unsigned little-endian)</pre>
|
|||
<p>Notes:</p>
|
||||
<ul>
|
||||
<li><code>value</code> is defined in the consensus rules to be a nonnegative value <= <code>MAX_MONEY</code>, but all existing implementations parse this value as signed and enforce the nonnegative constraint as a consensus check. It is defined as signed here for consistency with those existing implementations.</li>
|
||||
<li><code>scriptPubKey</code> is the field encoding (including a leading <code>CompactSize</code>) of the <code>pk_script</code> field <a id="id16" class="footnote_reference" href="#bdr-txout">14</a> for the coin spent by the transparent input. For P2SH coins, this differs from the <code>redeemScript</code> committed to in ZIP 243 <a id="id17" class="footnote_reference" href="#zip-0243">7</a>.</li>
|
||||
<li><code>scriptPubKey</code> is the field encoding (including a leading <code>CompactSize</code>) of the <code>pk_script</code> field <a id="footnote-reference-14" class="footnote_reference" href="#bdr-txout">14</a> for the coin spent by the transparent input. For P2SH coins, this differs from the <code>redeemScript</code> committed to in ZIP 243 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0243">7</a>.</li>
|
||||
</ul>
|
||||
<p>If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, <code>txin_sig_digest</code> is:</p>
|
||||
<pre>BLAKE2b-256("Zcash___TxInHash", [])</pre>
|
||||
|
|
@ -397,7 +397,7 @@ A.3c: bindingSigOrchard (field encoding bytes)</pre>
|
|||
is well-defined because
|
||||
<span class="math">\(\mathsf{tx\_count} > 0\)</span>
|
||||
, due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string <code>"ZcashAuthDatHash"</code>.</p>
|
||||
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="id18" class="footnote_reference" href="#zip-0221">4</a>, is changed.</p>
|
||||
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="footnote-reference-16" class="footnote_reference" href="#zip-0221">4</a>, is changed.</p>
|
||||
<p><code>hashLightClientRoot</code> is renamed to <code>hashBlockCommitments</code>. The value of this hash is the BLAKE2b-256 hash personalized by the string <code>"ZcashBlockCommit"</code> of the following elements:</p>
|
||||
<pre>hashLightClientRoot (as described in ZIP 221)
|
||||
hashAuthDataRoot (as described below)
|
||||
|
|
@ -410,19 +410,19 @@ terminator [0u8;32]</pre>
|
|||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>In S.2, we use the same personalization strings for fields that have matching fields in T.2, in order to facilitate reuse of their digests. In particular, the "no transparent inputs or outputs" case of S.2 is identical to the equivalent case in T.2; thus for fully shielded transactions, <code>signature_digest</code> is equal to <code>txid_digest</code>.</p>
|
||||
<p>Several changes in this ZIP (relative to ZIP 243 <a id="id19" class="footnote_reference" href="#zip-0243">7</a>) were made to align with BIP 341 <a id="id20" class="footnote_reference" href="#bip-0341">9</a>:</p>
|
||||
<p>Several changes in this ZIP (relative to ZIP 243 <a id="footnote-reference-17" class="footnote_reference" href="#zip-0243">7</a>) were made to align with BIP 341 <a id="footnote-reference-18" class="footnote_reference" href="#bip-0341">9</a>:</p>
|
||||
<ul>
|
||||
<li>The <code>hash_type</code> field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 <a id="id21" class="footnote_reference" href="#bip-0341-hash-type">10</a>.
|
||||
<li>The <code>hash_type</code> field is now restricted via a new consensus rule to be one of a specific set of sighash type encodings. The rationale for this change is inherited from BIP 341 <a id="footnote-reference-19" class="footnote_reference" href="#bip-0341-hash-type">10</a>.
|
||||
<ul>
|
||||
<li>Note however that we do not define <code>SIGHASH_DEFAULT</code>, as it is equivalent to <code>SIGHASH_ALL</code>, and we prefer the encodings to be canonical.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Two new commitments (<code>amounts_sig_digest</code> and <code>scriptpubkeys_sig_digest</code>) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. <code>scriptpubkeys_sig_digest</code> helps the hardware wallet to determine the subset of inputs belonging to it <a id="id22" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. <code>amounts_sig_digest</code> prevents the transaction creator from lying to the hardware wallet about the transaction fee <a id="id23" class="footnote_reference" href="#bip-0341-amount">12</a>. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.</li>
|
||||
<li>The semantics of <code>sequence_sig_digest</code> were changed, to commit to <code>nSequence</code> even if <code>SIGHASH_SINGLE</code> or <code>SIGHASH_NONE</code> is set. The rationale for this change is inherited from BIP 341 <a id="id24" class="footnote_reference" href="#bip-0341-nsequence">13</a>.</li>
|
||||
<li>Two new commitments (<code>amounts_sig_digest</code> and <code>scriptpubkeys_sig_digest</code>) were added, to address difficulties in the case of a hardware wallet signing transparent inputs. <code>scriptpubkeys_sig_digest</code> helps the hardware wallet to determine the subset of inputs belonging to it <a id="footnote-reference-20" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. <code>amounts_sig_digest</code> prevents the transaction creator from lying to the hardware wallet about the transaction fee <a id="footnote-reference-21" class="footnote_reference" href="#bip-0341-amount">12</a>. Without these commitments, the hardware wallet would need to be sent every transaction containing an outpoint referenced in the transaction being signed.</li>
|
||||
<li>The semantics of <code>sequence_sig_digest</code> were changed, to commit to <code>nSequence</code> even if <code>SIGHASH_SINGLE</code> or <code>SIGHASH_NONE</code> is set. The rationale for this change is inherited from BIP 341 <a id="footnote-reference-22" class="footnote_reference" href="#bip-0341-nsequence">13</a>.</li>
|
||||
<li>The semantics of <code>outputs_sig_digest</code> were changed, via a new consensus rule that rejects transparent inputs for which <code>SIGHASH_SINGLE</code> is set without a corresponding transparent output at the same index. BIP 341 does not give a rationale for this change, but without it these inputs were effectively using <code>SIGHASH_NONE</code>, which is silently misleading.</li>
|
||||
<li>The semantics of <code>txin_sig_digest</code> were changed, to always commit to the <code>scriptPubKey</code> field of the transparent coin being spent, instead of the script actually being executed at the time <code>signature_digest</code> is calculated.
|
||||
<ul>
|
||||
<li>This ensures that the signature commits to the entire committed script. In Taproot, this makes it possible to prove to a hardware wallet what (unused) execution paths exist <a id="id25" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. Alternate execution paths don't exist for P2PKH (where the executed script is <code>scriptPubKey</code>) or P2SH (where <code>scriptPubKey</code> is fully executed prior to <code>redeemScript</code>).</li>
|
||||
<li>This ensures that the signature commits to the entire committed script. In Taproot, this makes it possible to prove to a hardware wallet what (unused) execution paths exist <a id="footnote-reference-23" class="footnote_reference" href="#bip-0341-scriptpubkey">11</a>. Alternate execution paths don't exist for P2PKH (where the executed script is <code>scriptPubKey</code>) or P2SH (where <code>scriptPubKey</code> is fully executed prior to <code>redeemScript</code>).</li>
|
||||
<li>For P2SH, this means we commit to the Hash160 digest of <code>redeemScript</code> instead of the actual script. Note that the Bitcoin P2SH design depends entirely on Hash160 being preimage-resistant, because otherwise anyone would be able to spend someone else's P2SH UTXO using a preimage. We do need to ensure that there is no collision attack; this holds because even if an adversary could find a Hash160 collision, it would only enable them to alter the input's <code>scriptSig</code> field. Doing so doesn't alter the effecting data of the transaction, which by definition means the transaction has the same effect under consensus (spends the same inputs and produces the same outputs).</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
|
|
|||
|
|
@ -15,15 +15,15 @@ Created: 2021-01-13
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/384">https://github.com/zcash/zips/issues/384</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">2</a></p>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">2</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines changes to ZIP 244 <a id="id3" class="footnote_reference" href="#zip-0244">4</a> transaction id and signature digest algorithms to accommodate the inclusion of transparent Zcash extensions (TZEs) as defined in ZIP 222 <a id="id4" class="footnote_reference" href="#zip-0222">3</a>.</p>
|
||||
<p>This proposal defines changes to ZIP 244 <a id="footnote-reference-3" class="footnote_reference" href="#zip-0244">4</a> transaction id and signature digest algorithms to accommodate the inclusion of transparent Zcash extensions (TZEs) as defined in ZIP 222 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0222">3</a>.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="txid-digest"><h3><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The tree of hashes defined by ZIP 244 <a id="id5" class="footnote_reference" href="#zip-0244">4</a> is re-structured to include a new branch for TZE hashes. The <code>tze_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
|
||||
<p>The tree of hashes defined by ZIP 244 <a id="footnote-reference-5" class="footnote_reference" href="#zip-0244">4</a> is re-structured to include a new branch for TZE hashes. The <code>tze_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
|
||||
<pre>txid_digest
|
||||
├── header_digest
|
||||
├── transparent_digest
|
||||
|
|
@ -32,7 +32,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/384">https://g
|
|||
│ └── tzeout_digest
|
||||
├── sprout_digest
|
||||
└── sapling_digest</pre>
|
||||
<section id="id6"><h4><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id6"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="txid-digest-1"><h4><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The top hash of the <code>txid_digest</code> tree is modified from the ZIP 244 structure to be a BLAKE2b-256 hash of the following values</p>
|
||||
<pre>T.1: header_digest (32-byte hash output)
|
||||
T.2: transparent_digest (32-byte hash output)
|
||||
|
|
@ -62,7 +62,7 @@ T.2b: tzeout_digest (32-byte hash)</pre>
|
|||
</section>
|
||||
</section>
|
||||
<section id="signature-digest"><h3><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The signature digest creation algorithm defined by ZIP 244 <a id="id7" class="footnote_reference" href="#zip-0244">4</a> is modified to include a new branch for TZE hashes. The <code>tze_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
|
||||
<p>The signature digest creation algorithm defined by ZIP 244 <a id="footnote-reference-6" class="footnote_reference" href="#zip-0244">4</a> is modified to include a new branch for TZE hashes. The <code>tze_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
|
||||
<pre>signature_digest
|
||||
├── header_digest
|
||||
├── transparent_digest
|
||||
|
|
@ -71,7 +71,7 @@ T.2b: tzeout_digest (32-byte hash)</pre>
|
|||
│ └── tzeout_digest
|
||||
├── sprout_digest
|
||||
└── sapling_digest</pre>
|
||||
<section id="id8"><h4><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id8"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<section id="signature-digest-1"><h4><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>A BLAKE2b-256 hash of the following values</p>
|
||||
<pre>S.1: header_digest (32-byte hash output)
|
||||
S.2: transparent_digest (32-byte hash output)
|
||||
|
|
@ -95,7 +95,7 @@ S.3e: value (8-byte little endian value of the output spent by this inp
|
|||
</section>
|
||||
</section>
|
||||
<section id="authorizing-data-commitment"><h3><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The tree of hashes defined by ZIP 244 <a id="id9" class="footnote_reference" href="#zip-0244">4</a> for authorizing data commitments is re-structured to include a new branch for TZE hashes. The <code>tze_witnesses_digest</code> branch is the only new addition to the tree; <code>transparent_auth_digest</code>, <code>sprout_auth_digest</code>, and <code>sapling_auth_digest</code> are as in ZIP 244:</p>
|
||||
<p>The tree of hashes defined by ZIP 244 <a id="footnote-reference-7" class="footnote_reference" href="#zip-0244">4</a> for authorizing data commitments is re-structured to include a new branch for TZE hashes. The <code>tze_witnesses_digest</code> branch is the only new addition to the tree; <code>transparent_auth_digest</code>, <code>sprout_auth_digest</code>, and <code>sapling_auth_digest</code> are as in ZIP 244:</p>
|
||||
<pre>auth_digest
|
||||
├── transparent_scripts_digest
|
||||
├── tze_witnesses_digest
|
||||
|
|
|
|||
|
|
@ -14,16 +14,16 @@ Category: Consensus / Network
|
|||
Created: 2020-02-28
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Heartwood</dt>
|
||||
<dd>Code-name for the fourth Zcash network upgrade, also known as Network Upgrade 3.</dd>
|
||||
<dt>Testnet</dt>
|
||||
<dd>The Zcash test network, as defined in <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dd>The Zcash test network, as defined in <a id="footnote-reference-3" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dd>The Zcash production network, as defined in <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -33,13 +33,13 @@ License: MIT</pre>
|
|||
<section id="heartwood-deployment"><h3><span class="section-heading">Heartwood deployment</span><span class="section-anchor"> <a rel="bookmark" href="#heartwood-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Heartwood consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a></li>
|
||||
<li>ZIP 213: Shielded Coinbase <a id="id7" class="footnote_reference" href="#zip-0213">5</a></li>
|
||||
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="id8" class="footnote_reference" href="#zip-0221">6</a>.</li>
|
||||
<li>The Zcash Protocol Specification <a id="footnote-reference-5" class="footnote_reference" href="#protocol">2</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">3</a></li>
|
||||
<li>ZIP 213: Shielded Coinbase <a id="footnote-reference-7" class="footnote_reference" href="#zip-0213">5</a></li>
|
||||
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="footnote-reference-8" class="footnote_reference" href="#zip-0221">6</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id9" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id10" class="footnote_reference" href="#zip-0200">3</a> are defined for the Heartwood upgrade:</p>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="footnote-reference-9" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="footnote-reference-10" class="footnote_reference" href="#zip-0200">3</a> are defined for the Heartwood upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0xF5B9230B</code></dd>
|
||||
|
|
@ -57,7 +57,7 @@ License: MIT</pre>
|
|||
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
|
||||
*/
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id11" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-11" class="footnote_reference" href="#zip-0201">4</a>.</p>
|
||||
<p>Once Heartwood activates on testnet or mainnet, Heartwood nodes SHOULD take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Heartwood nodes on that network;</li>
|
||||
|
|
@ -68,7 +68,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Heartwood and pre-Heartwood nodes are compatible and can connect to each other. However, Heartwood nodes will have a preference for connecting to other Heartwood nodes, so pre-Heartwood nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Heartwood nodes can still accept the numerically larger protocol version used by Heartwood as being valid, Heartwood nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom, Heartwood does not define a new transaction version. Heartwood transactions are therefore in the same v4 format as Sapling transactions, use the same version group ID, i.e. 0x892F2085 as defined in <a id="id12" class="footnote_reference" href="#protocol">2</a> section 7.1, and the same transaction digest algorithm as defined in <a id="id13" class="footnote_reference" href="#zip-0243">7</a>. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID. <a id="id14" class="footnote_reference" href="#zip-0243">7</a></p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom, Heartwood does not define a new transaction version. Heartwood transactions are therefore in the same v4 format as Sapling transactions, use the same version group ID, i.e. 0x892F2085 as defined in <a id="footnote-reference-12" class="footnote_reference" href="#protocol">2</a> section 7.1, and the same transaction digest algorithm as defined in <a id="footnote-reference-13" class="footnote_reference" href="#zip-0243">7</a>. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID. <a id="footnote-reference-14" class="footnote_reference" href="#zip-0243">7</a></p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Heartwood on testnet will be implemented in <code>zcashd</code> version 2.1.2, which will advertise protocol version 170010. Support for Heartwood on mainnet will be implemented in <code>zcashd</code> version 3.0.0, which will advertise protocol version 170011.</p>
|
||||
|
|
|
|||
|
|
@ -14,9 +14,9 @@ Category: Consensus / Network
|
|||
Created: 2020-02-28
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">5</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">5</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -26,17 +26,17 @@ License: MIT</pre>
|
|||
<section id="canopy-deployment"><h3><span class="section-heading">Canopy deployment</span><span class="section-anchor"> <a rel="bookmark" href="#canopy-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about Canopy consensus protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="id5" class="footnote_reference" href="#zip-0200">5</a></li>
|
||||
<li>ZIP 207: Funding Streams <a id="id6" class="footnote_reference" href="#zip-0207">7</a></li>
|
||||
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="id7" class="footnote_reference" href="#zip-0211">8</a></li>
|
||||
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="id8" class="footnote_reference" href="#zip-0212">9</a></li>
|
||||
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="id9" class="footnote_reference" href="#zip-0214">10</a></li>
|
||||
<li>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <a id="id10" class="footnote_reference" href="#zip-0215">11</a></li>
|
||||
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id11" class="footnote_reference" href="#zip-1014">13</a>.</li>
|
||||
<li>The Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="footnote-reference-5" class="footnote_reference" href="#zip-0200">5</a></li>
|
||||
<li>ZIP 207: Funding Streams <a id="footnote-reference-6" class="footnote_reference" href="#zip-0207">7</a></li>
|
||||
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="footnote-reference-7" class="footnote_reference" href="#zip-0211">8</a></li>
|
||||
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="footnote-reference-8" class="footnote_reference" href="#zip-0212">9</a></li>
|
||||
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="footnote-reference-9" class="footnote_reference" href="#zip-0214">10</a></li>
|
||||
<li>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <a id="footnote-reference-10" class="footnote_reference" href="#zip-0215">11</a></li>
|
||||
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="footnote-reference-11" class="footnote_reference" href="#zip-1014">13</a>.</li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id12" class="footnote_reference" href="#zip-0201">6</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="id13" class="footnote_reference" href="#zip-0200">5</a> are defined for the Canopy upgrade:</p>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="footnote-reference-12" class="footnote_reference" href="#zip-0201">6</a> also apply to this upgrade.</p>
|
||||
<p>The following network upgrade constants <a id="footnote-reference-13" class="footnote_reference" href="#zip-0200">5</a> are defined for the Canopy upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0xE9FF75A6</code></dd>
|
||||
|
|
@ -54,7 +54,7 @@ License: MIT</pre>
|
|||
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
|
||||
*/
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id14" class="footnote_reference" href="#zip-0201">6</a>.</p>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-14" class="footnote_reference" href="#zip-0201">6</a>.</p>
|
||||
<p>Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:</p>
|
||||
<ul>
|
||||
<li>reject new connections from pre-Canopy nodes on that network;</li>
|
||||
|
|
@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
|||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, Canopy and pre-Canopy nodes are compatible and can connect to each other. However, Canopy nodes will have a preference for connecting to other Canopy nodes, so pre-Canopy nodes will gradually be disconnected in the run up to activation.</p>
|
||||
<p>Once the network upgrades, even though pre-Canopy nodes can still accept the numerically larger protocol version used by Canopy as being valid, Canopy nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <a id="id15" class="footnote_reference" href="#protocol-txnencoding">4</a>; and use the same transaction digest algorithm as defined in <a id="id16" class="footnote_reference" href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id17" class="footnote_reference" href="#zip-0243">12</a></p>
|
||||
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <a id="footnote-reference-15" class="footnote_reference" href="#protocol-txnencoding">4</a>; and use the same transaction digest algorithm as defined in <a id="footnote-reference-16" class="footnote_reference" href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="footnote-reference-17" class="footnote_reference" href="#zip-0243">12</a></p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Support for Canopy on testnet will be implemented in <code>zcashd</code> version 3.1.0, which will advertise protocol version 170012. Support for Canopy on mainnet will be implemented in <code>zcashd</code> version 4.0.0, which will advertise protocol version 170013.</p>
|
||||
|
|
|
|||
|
|
@ -17,9 +17,9 @@ License: MIT
|
|||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/440">https://github.com/zcash/zips/issues/440</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/446">https://github.com/zcash/zips/pull/446</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">6</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">6</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines the deployment of the NU5 network upgrade.</p>
|
||||
|
|
@ -28,29 +28,29 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/446">https://githu
|
|||
<section id="nu5-deployment"><h3><span class="section-heading">NU5 deployment</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The primary sources of information about NU5 consensus and peer-to-peer protocol changes are:</p>
|
||||
<ul>
|
||||
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a> <a id="id5" class="footnote_reference" href="#protocol-txnencoding">4</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">6</a></li>
|
||||
<li>ZIP 216: Require Canonical Point Encodings <a id="id7" class="footnote_reference" href="#zip-0216">12</a></li>
|
||||
<li>ZIP 224: Orchard Shielded Protocol <a id="id8" class="footnote_reference" href="#zip-0224">14</a></li>
|
||||
<li>ZIP 225: Version 5 Transaction Format <a id="id9" class="footnote_reference" href="#zip-0225">15</a></li>
|
||||
<li>ZIP 239: Relay of Version 5 Transactions <a id="id10" class="footnote_reference" href="#zip-0239">16</a></li>
|
||||
<li>ZIP 244: Transaction Identifier Non-Malleability <a id="id11" class="footnote_reference" href="#zip-0244">17</a></li>
|
||||
<li>The Orchard Book <a id="id12" class="footnote_reference" href="#orchard-book">20</a></li>
|
||||
<li>The halo2 Book <a id="id13" class="footnote_reference" href="#halo2-book">21</a></li>
|
||||
<li>The Zcash Protocol Specification <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a> <a id="footnote-reference-5" class="footnote_reference" href="#protocol-txnencoding">4</a></li>
|
||||
<li>ZIP 200: Network Upgrade Mechanism <a id="footnote-reference-6" class="footnote_reference" href="#zip-0200">6</a></li>
|
||||
<li>ZIP 216: Require Canonical Point Encodings <a id="footnote-reference-7" class="footnote_reference" href="#zip-0216">12</a></li>
|
||||
<li>ZIP 224: Orchard Shielded Protocol <a id="footnote-reference-8" class="footnote_reference" href="#zip-0224">14</a></li>
|
||||
<li>ZIP 225: Version 5 Transaction Format <a id="footnote-reference-9" class="footnote_reference" href="#zip-0225">15</a></li>
|
||||
<li>ZIP 239: Relay of Version 5 Transactions <a id="footnote-reference-10" class="footnote_reference" href="#zip-0239">16</a></li>
|
||||
<li>ZIP 244: Transaction Identifier Non-Malleability <a id="footnote-reference-11" class="footnote_reference" href="#zip-0244">17</a></li>
|
||||
<li>The Orchard Book <a id="footnote-reference-12" class="footnote_reference" href="#orchard-book">20</a></li>
|
||||
<li>The halo2 Book <a id="footnote-reference-13" class="footnote_reference" href="#halo2-book">21</a></li>
|
||||
</ul>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id14" class="footnote_reference" href="#zip-0201">7</a> also apply to this upgrade.</p>
|
||||
<p>Unified addresses and viewing keys are described in ZIP 316 <a id="id15" class="footnote_reference" href="#zip-0316">18</a>.</p>
|
||||
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="footnote-reference-14" class="footnote_reference" href="#zip-0201">7</a> also apply to this upgrade.</p>
|
||||
<p>Unified addresses and viewing keys are described in ZIP 316 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0316">18</a>.</p>
|
||||
<p>The following ZIPs have been updated in varying degrees to take into account Orchard:</p>
|
||||
<ul>
|
||||
<li>ZIP 32: Shielded Hierarchical Deterministic Wallets <a id="id16" class="footnote_reference" href="#zip-0032">5</a></li>
|
||||
<li>ZIP 203: Transaction Expiry <a id="id17" class="footnote_reference" href="#zip-0203">8</a></li>
|
||||
<li>ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <a id="id18" class="footnote_reference" href="#zip-0209">9</a></li>
|
||||
<li>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <a id="id19" class="footnote_reference" href="#zip-0212">10</a></li>
|
||||
<li>ZIP 213: Shielded Coinbase <a id="id20" class="footnote_reference" href="#zip-0213">11</a></li>
|
||||
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="id21" class="footnote_reference" href="#zip-0221">13</a></li>
|
||||
<li>ZIP 401: Addressing Mempool Denial-of-Service <a id="id22" class="footnote_reference" href="#zip-0401">19</a></li>
|
||||
<li>ZIP 32: Shielded Hierarchical Deterministic Wallets <a id="footnote-reference-16" class="footnote_reference" href="#zip-0032">5</a></li>
|
||||
<li>ZIP 203: Transaction Expiry <a id="footnote-reference-17" class="footnote_reference" href="#zip-0203">8</a></li>
|
||||
<li>ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <a id="footnote-reference-18" class="footnote_reference" href="#zip-0209">9</a></li>
|
||||
<li>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <a id="footnote-reference-19" class="footnote_reference" href="#zip-0212">10</a></li>
|
||||
<li>ZIP 213: Shielded Coinbase <a id="footnote-reference-20" class="footnote_reference" href="#zip-0213">11</a></li>
|
||||
<li>ZIP 221: FlyClient - Consensus-Layer Changes <a id="footnote-reference-21" class="footnote_reference" href="#zip-0221">13</a></li>
|
||||
<li>ZIP 401: Addressing Mempool Denial-of-Service <a id="footnote-reference-22" class="footnote_reference" href="#zip-0401">19</a></li>
|
||||
</ul>
|
||||
<p>The following network upgrade constants <a id="id23" class="footnote_reference" href="#zip-0200">6</a> are defined for the NU5 upgrade:</p>
|
||||
<p>The following network upgrade constants <a id="footnote-reference-23" class="footnote_reference" href="#zip-0200">6</a> are defined for the NU5 upgrade:</p>
|
||||
<dl>
|
||||
<dt>CONSENSUS_BRANCH_ID</dt>
|
||||
<dd><code>0xc2d6d0b4</code></dd>
|
||||
|
|
@ -73,14 +73,14 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/446">https://githu
|
|||
<li>reject new connections from pre-NU5 nodes on that network;</li>
|
||||
<li>disconnect any existing connections to pre-NU5 nodes on that network.</li>
|
||||
</ul>
|
||||
<p>The change to the peer-to-peer protocol described in ZIP 239 took effect from peer protocol version 170014 onward, on both Testnet and Mainnet. <a id="id24" class="footnote_reference" href="#zip-0239">16</a></p>
|
||||
<p>The change to the peer-to-peer protocol described in ZIP 239 took effect from peer protocol version 170014 onward, on both Testnet and Mainnet. <a id="footnote-reference-24" class="footnote_reference" href="#zip-0239">16</a></p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Prior to the network upgrade activating on each network, NU5 and pre-NU5 nodes are compatible and can connect to each other. (In the case of Testnet, there was a prolonged period of network fracturing due to a consensus bug, but this is expected to be resolved with the release of <cite>zcashd</cite> v4.7.0.)</p>
|
||||
<p>Once the network upgrades, even though pre-NU5 nodes can still accept the numerically larger protocol version used by NU5 as being valid, NU5 nodes will always disconnect peers using lower protocol versions.</p>
|
||||
<p>Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by <a id="id25" class="footnote_reference" href="#zip-0225">15</a>. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.</p>
|
||||
<p>Backward compatibility of the new <code>MSG_WTX</code> inv type introduced for <code>inv</code> and <code>getdata</code> messages is discussed in <a id="id26" class="footnote_reference" href="#zip-0239">16</a>.</p>
|
||||
<p>Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by <a id="footnote-reference-25" class="footnote_reference" href="#zip-0225">15</a>. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.</p>
|
||||
<p>Backward compatibility of the new <code>MSG_WTX</code> inv type introduced for <code>inv</code> and <code>getdata</code> messages is discussed in <a id="footnote-reference-26" class="footnote_reference" href="#zip-0239">16</a>.</p>
|
||||
</section>
|
||||
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Several versions of <cite>zcashd</cite> have implemented versions of the NU5 consensus rules on Testnet:</p>
|
||||
|
|
@ -100,7 +100,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/446">https://githu
|
|||
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
|
||||
*/
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="id27" class="footnote_reference" href="#zip-0201">7</a>.</p>
|
||||
<p>The implementation is similar to that for Overwinter which was described in <a id="footnote-reference-27" class="footnote_reference" href="#zip-0201">7</a>.</p>
|
||||
<p>However, NU5 nodes will have a preference for connecting to other NU5 nodes, so pre-NU5 nodes will gradually be disconnected in the run up to activation.</p>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -19,17 +19,17 @@ Category: Standards / Ecosystem
|
|||
Created: 2016-09-23
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP describes the Zcash variant of the Stratum protocol, used by miners to communicate with mining pool servers.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Many existing cryptocurrency miners and pools use the original Stratum protocol <a id="id2" class="footnote_reference" href="#slushpool-stratum">4</a> <a id="id3" class="footnote_reference" href="#bitcointalk-stratum">5</a> for communication, in situations where the miner does not require any control over what they mine (for example, a miner connected to a local <a id="id4" class="footnote_reference" href="#p2pool">6</a> node). However, the protocol is very specific to Bitcoin, in that it makes assumptions about the block header format, and the available nonce space <a id="id5" class="footnote_reference" href="#bitcoin-block">7</a>. Zcash has made changes that invalidate these assumptions.</p>
|
||||
<p>Many existing cryptocurrency miners and pools use the original Stratum protocol <a id="footnote-reference-2" class="footnote_reference" href="#slushpool-stratum">4</a> <a id="footnote-reference-3" class="footnote_reference" href="#bitcointalk-stratum">5</a> for communication, in situations where the miner does not require any control over what they mine (for example, a miner connected to a local <a id="footnote-reference-4" class="footnote_reference" href="#p2pool">6</a> node). However, the protocol is very specific to Bitcoin, in that it makes assumptions about the block header format, and the available nonce space <a id="footnote-reference-5" class="footnote_reference" href="#bitcoin-block">7</a>. Zcash has made changes that invalidate these assumptions.</p>
|
||||
<p>Having a formal specification for a Zcash-compatible Stratum-style mining protocol means that existing pool operators and miner authors can quickly and easily migrate their frameworks to the Zcash network, with no ambiguity about interoperability.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Stratum protocol is an instance of <a id="id6" class="footnote_reference" href="#json-rpc-1-0">9</a>. The miner is a JSON-RPC client, and the Stratum server is a JSON-RPC server. The miner starts a session by opening a standard TCP connection to the server, which is then used for two-way line-based communication:</p>
|
||||
<p>The Stratum protocol is an instance of <a id="footnote-reference-6" class="footnote_reference" href="#json-rpc-1-0">9</a>. The miner is a JSON-RPC client, and the Stratum server is a JSON-RPC server. The miner starts a session by opening a standard TCP connection to the server, which is then used for two-way line-based communication:</p>
|
||||
<ul>
|
||||
<li>The miner can send requests to the server.</li>
|
||||
<li>The server can respond to requests.</li>
|
||||
|
|
@ -37,10 +37,10 @@ License: MIT</pre>
|
|||
</ul>
|
||||
<p>All communication for a particular session happens through a single connection, which is kept open for the duration of the session. If the connection is broken or either party disconnects, the active session is ended. Servers MAY support session resuming; this is negotiated between the client and server during initial setup (see <a href="#session-resuming">Session Resuming</a>).</p>
|
||||
<p>Each request or response is a JSON string, terminated by an ASCII LF character (denoted in the rest of this specification by <code>\n</code>). The LF character MUST NOT appear elsewhere in a request or response. Client and server implementations MAY assume that once they read a LF character, the current message has been completely received.</p>
|
||||
<p>Per <a id="id7" class="footnote_reference" href="#json-rpc-1-0">9</a>, there is no requirement for the <code>id</code> property in requests and responses to be unique; only that servers MUST set <code>id</code> in their responses equal to that in the request they are responding to (or <code>null</code> for notifications). However, it is RECOMMENDED that clients use unique ids for their requests, to simplify their response parsing.</p>
|
||||
<p>Per <a id="footnote-reference-7" class="footnote_reference" href="#json-rpc-1-0">9</a>, there is no requirement for the <code>id</code> property in requests and responses to be unique; only that servers MUST set <code>id</code> in their responses equal to that in the request they are responding to (or <code>null</code> for notifications). However, it is RECOMMENDED that clients use unique ids for their requests, to simplify their response parsing.</p>
|
||||
<p>In the protocol messages below, <code>(content)</code> indicates that <code>content</code> is optional. Variable names are indicated in <em>EMPHASIS</em>. All other characters are part of the protocol message.</p>
|
||||
<section id="error-objects"><h3><span class="section-heading">Error Objects</span><span class="section-anchor"> <a rel="bookmark" href="#error-objects"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The <a id="id8" class="footnote_reference" href="#json-rpc-1-0">9</a> specification allows for error objects in responses, but does not specify their format. The original Stratum protocol uses the following format for error responses <a id="id9" class="footnote_reference" href="#slushpool-stratum">4</a>:</p>
|
||||
<p>The <a id="footnote-reference-8" class="footnote_reference" href="#json-rpc-1-0">9</a> specification allows for error objects in responses, but does not specify their format. The original Stratum protocol uses the following format for error responses <a id="footnote-reference-9" class="footnote_reference" href="#slushpool-stratum">4</a>:</p>
|
||||
<blockquote>
|
||||
<p>{"id": ##, "result": null, "error": [<em>ERROR_CODE</em>, "<em>ERROR_MESSAGE</em>", <em>TRACEBACK</em>]} <code>\n</code></p>
|
||||
</blockquote>
|
||||
|
|
@ -52,7 +52,7 @@ License: MIT</pre>
|
|||
<dt><code>ERROR_CODE</code> (int)</dt>
|
||||
<dd>
|
||||
<p>Indicates the type of error that occurred.</p>
|
||||
<p>The error codes are to be interpreted as described in <a id="id10" class="footnote_reference" href="#json-rpc-2-0">10</a>. The following application error codes are defined:</p>
|
||||
<p>The error codes are to be interpreted as described in <a id="footnote-reference-10" class="footnote_reference" href="#json-rpc-2-0">10</a>. The following application error codes are defined:</p>
|
||||
<ul>
|
||||
<li>20 - Other/Unknown</li>
|
||||
<li>21 - Job not found (=stale)</li>
|
||||
|
|
@ -88,7 +88,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
<section id="nonce-parts"><h3><span class="section-heading">Nonce Parts</span><span class="section-anchor"> <a rel="bookmark" href="#nonce-parts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>In Bitcoin, blocks contain two nonces: the 4-byte block header nonce, and an extra nonce in the coinbase transaction <a id="id11" class="footnote_reference" href="#bitcoin-block">7</a>. The original Stratum protocol splits this extra nonce into two parts: one set by the server (used for splitting the search space amongst connected miners), and the other iterated by the miner <a id="id12" class="footnote_reference" href="#slushpool-stratum">4</a>. The nonce in Zcash's block header is 32 bytes long <a id="id13" class="footnote_reference" href="#protocol-blockheader">2</a>, and thus can serve both purposes simultaneously.</p>
|
||||
<p>In Bitcoin, blocks contain two nonces: the 4-byte block header nonce, and an extra nonce in the coinbase transaction <a id="footnote-reference-11" class="footnote_reference" href="#bitcoin-block">7</a>. The original Stratum protocol splits this extra nonce into two parts: one set by the server (used for splitting the search space amongst connected miners), and the other iterated by the miner <a id="footnote-reference-12" class="footnote_reference" href="#slushpool-stratum">4</a>. The nonce in Zcash's block header is 32 bytes long <a id="footnote-reference-13" class="footnote_reference" href="#protocol-blockheader">2</a>, and thus can serve both purposes simultaneously.</p>
|
||||
<p>We define two nonce parts:</p>
|
||||
<dl>
|
||||
<dt><code>NONCE_1</code></dt>
|
||||
|
|
@ -99,7 +99,7 @@ License: MIT</pre>
|
|||
<p>In hex, <code>lenHex(NONCE_2) = 64 - lenHex(NONCE_1)</code>, and both lengths are even.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
<p>The nonce in the block header is the concatenation of <code>NONCE_1</code> and <code>NONCE_2</code> in hex. This means that a miner using bignum representations of nonce MUST increment by <code>1 << len(NONCE_1)</code> to avoid altering <code>NONCE_1</code> (because the encoding of the nonce in the block header is little endian, in line with the other 32-byte fields <a id="id14" class="footnote_reference" href="#bitcoin-block">7</a> <a id="id15" class="footnote_reference" href="#protocol-blockheader">2</a>).</p>
|
||||
<p>The nonce in the block header is the concatenation of <code>NONCE_1</code> and <code>NONCE_2</code> in hex. This means that a miner using bignum representations of nonce MUST increment by <code>1 << len(NONCE_1)</code> to avoid altering <code>NONCE_1</code> (because the encoding of the nonce in the block header is little endian, in line with the other 32-byte fields <a id="footnote-reference-14" class="footnote_reference" href="#bitcoin-block">7</a> <a id="footnote-reference-15" class="footnote_reference" href="#protocol-blockheader">2</a>).</p>
|
||||
</section>
|
||||
<section id="session-resuming"><h3><span class="section-heading">Session Resuming</span><span class="section-anchor"> <a rel="bookmark" href="#session-resuming"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Servers that support session resuming identify this by setting a <code>SESSION_ID</code> in their initial response. Servers MAY set <code>SESSION_ID</code> to <code>null</code> to indicate that they do not support session resuming. Servers that do not set <code>SESSION_ID</code> to <code>null</code> MUST cache the following information:</p>
|
||||
|
|
@ -173,7 +173,7 @@ License: MIT</pre>
|
|||
</blockquote>
|
||||
<dl>
|
||||
<dt><code>AUTHORIZED</code> (bool)</dt>
|
||||
<dd>This MUST be <code>true</code> if authorization succeeded. Per <a id="id16" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
|
||||
<dd>This MUST be <code>true</code> if authorization succeeded. Per <a id="footnote-reference-16" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
|
||||
<dt><code>ERROR</code> (obj)</dt>
|
||||
<dd>
|
||||
<p>An error object. This MUST be <code>null</code> if authorization succeeded.</p>
|
||||
|
|
@ -189,7 +189,7 @@ License: MIT</pre>
|
|||
<dl>
|
||||
<dt><code>TARGET</code> (hex)</dt>
|
||||
<dd>
|
||||
<p>The server target for the next received job and all subsequent jobs (until the next time this message is sent). The miner compares proposed block hashes with this target as a 256-bit big-endian integer, and valid blocks MUST NOT have hashes larger than (above) the current target (in accordance with the Zcash network consensus rules <a id="id17" class="footnote_reference" href="#protocol-difficulty">3</a>).</p>
|
||||
<p>The server target for the next received job and all subsequent jobs (until the next time this message is sent). The miner compares proposed block hashes with this target as a 256-bit big-endian integer, and valid blocks MUST NOT have hashes larger than (above) the current target (in accordance with the Zcash network consensus rules <a id="footnote-reference-17" class="footnote_reference" href="#protocol-difficulty">3</a>).</p>
|
||||
<p>Miners SHOULD NOT submit work above this target. Miners SHOULD validate their solutions before submission (to avoid both unnecessary network traffic and wasted miner time).</p>
|
||||
<p>Servers MUST NOT accept submissions above this target for jobs sent after this message. Servers MAY accept submissions above this target for jobs sent before this message, but MUST check them against the previous target.</p>
|
||||
</dd>
|
||||
|
|
@ -251,7 +251,7 @@ License: MIT</pre>
|
|||
<dt><code>NONCE_2</code> (hex)</dt>
|
||||
<dd>The second part of the block header nonce (see <a href="#nonce-parts">Nonce Parts</a>).</dd>
|
||||
<dt><code>EQUIHASH_SOLUTION</code> (hex)</dt>
|
||||
<dd>The Equihash solution, encoded as in a block header (including the compactSize at the beginning in canonical form <a id="id18" class="footnote_reference" href="#bitcoin-compactsize">8</a>).</dd>
|
||||
<dd>The Equihash solution, encoded as in a block header (including the compactSize at the beginning in canonical form <a id="footnote-reference-18" class="footnote_reference" href="#bitcoin-compactsize">8</a>).</dd>
|
||||
</dl>
|
||||
<p>Result:</p>
|
||||
<blockquote>
|
||||
|
|
@ -259,10 +259,10 @@ License: MIT</pre>
|
|||
</blockquote>
|
||||
<dl>
|
||||
<dt><code>ACCEPTED</code> (bool)</dt>
|
||||
<dd>This MUST be <code>true</code> if the submission was accepted. Per <a id="id19" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
|
||||
<dd>This MUST be <code>true</code> if the submission was accepted. Per <a id="footnote-reference-19" class="footnote_reference" href="#json-rpc-1-0">9</a>, it MUST be <code>null</code> if there was an error.</dd>
|
||||
<dt><code>ERROR</code> (obj)</dt>
|
||||
<dd>
|
||||
<p>An error object. Per <a id="id20" class="footnote_reference" href="#json-rpc-1-0">9</a>, this MUST be <code>null</code> if the submission was accepted without error.</p>
|
||||
<p>An error object. Per <a id="footnote-reference-20" class="footnote_reference" href="#json-rpc-1-0">9</a>, this MUST be <code>null</code> if the submission was accepted without error.</p>
|
||||
<p>If the submission was not accepted, the server MUST provide an error object describing the reason for not accepting the submission. See <a href="#error-objects">Error Objects</a> for the object format.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/105">https://githu
|
|||
<p>A well-defined standard for formatting content within the encrypted memo field will help expand its use within the Zcash ecosystem by providing a commonly recognized format for memo values carrying different types of data. Users and third-party services benefit from standardized formatting rules that define the type and length of the data contained within.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Section 5.5 of the Zcash protocol specification <a id="id1" class="footnote_reference" href="#protocol">1</a> defines three cases for the encoding of a memo field:</p>
|
||||
<p>Section 5.5 of the Zcash protocol specification <a id="footnote-reference-1" class="footnote_reference" href="#protocol">1</a> defines three cases for the encoding of a memo field:</p>
|
||||
<ul>
|
||||
<li>a UTF-8 human-readable string <a id="id2" class="footnote_reference" href="#utf-8">2</a>, padded by appending zero bytes; or</li>
|
||||
<li>a UTF-8 human-readable string <a id="footnote-reference-2" class="footnote_reference" href="#utf-8">2</a>, padded by appending zero bytes; or</li>
|
||||
<li>the byte <code>0xF6</code> followed by 511 <code>0x00</code> bytes, indicating "no memo"; or</li>
|
||||
<li>any other sequence of 512 bytes starting with a byte value <code>0xF5</code> or greater (which is therefore not a valid UTF-8 string), as specified in ZIP 302.</li>
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ License: MIT
|
|||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/345">https://github.com/zcash/zips/issues/345</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://github.com/zcash/zips/pull/376</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST" and "SHOULD" in this document is to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal describes a mechanism for creating signatures with Sapling addresses, suitable for use by the <code>signmessage</code> and <code>verifymessage</code> RPC methods in <code>zcashd</code>.</p>
|
||||
|
|
@ -32,25 +32,25 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<p>One of the R&D achievements behind the Sapling protocol was the ability to use elliptic curves inside a circuit. With this primitive available, Sapling keys and payment addresses could be designed such that transaction authorization involved a signature. While this was designed to enable hardware wallets (which lack the power to create zero-knowledge proofs, but can easily create signatures), it also enables the creation of a mechanism for signing arbitrary messages. That mechanism is the subject of this ZIP.</p>
|
||||
</section>
|
||||
<section id="conventions"><h2><span class="section-heading">Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#conventions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following constants and functions used in this ZIP are defined in the Zcash protocol specification: <a id="id2" class="footnote_reference" href="#protocol">3</a></p>
|
||||
<p>The following constants and functions used in this ZIP are defined in the Zcash protocol specification: <a id="footnote-reference-2" class="footnote_reference" href="#protocol">3</a></p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{MerkleDepth}^\mathsf{Sapling}\)</span>
|
||||
and
|
||||
<span class="math">\(\mathsf{Uncommitted}^\mathsf{Sapling}\)</span>
|
||||
<a id="id3" class="footnote_reference" href="#protocol-constants">6</a></li>
|
||||
<a id="footnote-reference-3" class="footnote_reference" href="#protocol-constants">6</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{MerkleCRH}^\mathsf{Sapling}\)</span>
|
||||
<a id="id4" class="footnote_reference" href="#protocol-saplingmerklecrh">7</a></li>
|
||||
<a id="footnote-reference-4" class="footnote_reference" href="#protocol-saplingmerklecrh">7</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{DiversifyHash}(\mathsf{d})\)</span>
|
||||
<a id="id5" class="footnote_reference" href="#protocol-concretediversifyhash">8</a></li>
|
||||
<a id="footnote-reference-5" class="footnote_reference" href="#protocol-concretediversifyhash">8</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{MixingPedersenHash}(\mathsf{cm}, position)\)</span>
|
||||
<a id="id6" class="footnote_reference" href="#protocol-concretemixinghash">9</a></li>
|
||||
<a id="footnote-reference-6" class="footnote_reference" href="#protocol-concretemixinghash">9</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{PRF}^\mathsf{nfSapling}_\mathsf{nk}(ρ)\)</span>
|
||||
<a id="id7" class="footnote_reference" href="#protocol-concreteprfs">10</a></li>
|
||||
<a id="footnote-reference-7" class="footnote_reference" href="#protocol-concreteprfs">10</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{sk})\)</span>
|
||||
,
|
||||
|
|
@ -59,13 +59,13 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<span class="math">\(\mathsf{SpendAuthSig.Sign}(\mathsf{sk}, m)\)</span>
|
||||
, and
|
||||
<span class="math">\(\mathsf{SpendAuthSig.Verify}(\mathsf{vk}, m, σ)\)</span>
|
||||
<a id="id8" class="footnote_reference" href="#protocol-concretespendauthsig">11</a></li>
|
||||
<a id="footnote-reference-8" class="footnote_reference" href="#protocol-concretespendauthsig">11</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{NoteCommit}^\mathsf{Sapling}_\mathsf{rcm}(\mathsf{g_d}, \mathsf{pk_d}, value)\)</span>
|
||||
<a id="id9" class="footnote_reference" href="#protocol-concretewindowedcommit">12</a></li>
|
||||
<a id="footnote-reference-9" class="footnote_reference" href="#protocol-concretewindowedcommit">12</a></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{ValueCommit}_\mathsf{rcv}(value)\)</span>
|
||||
<a id="id10" class="footnote_reference" href="#protocol-concretehomomorphiccommit">13</a></li>
|
||||
<a id="footnote-reference-10" class="footnote_reference" href="#protocol-concretehomomorphiccommit">13</a></li>
|
||||
</ul>
|
||||
<p>We also reproduce some notation and functions here for convenience:</p>
|
||||
<ul>
|
||||
|
|
@ -80,7 +80,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
|
||||
is the representation of the Jubjub elliptic curve point
|
||||
<span class="math">\(P\)</span>
|
||||
as a bit sequence, defined in <a id="id11" class="footnote_reference" href="#protocol-jubjub">14</a>.</li>
|
||||
as a bit sequence, defined in <a id="footnote-reference-11" class="footnote_reference" href="#protocol-jubjub">14</a>.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\)</span>
|
||||
refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string
|
||||
|
|
@ -120,7 +120,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<li>Its corresponding expanded spending key
|
||||
<span class="math">\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk})\)</span>
|
||||
,</li>
|
||||
<li>The SLIP-44 <a id="id12" class="footnote_reference" href="#slip-0044">15</a> coin type, and</li>
|
||||
<li>The SLIP-44 <a id="footnote-reference-12" class="footnote_reference" href="#slip-0044">15</a> coin type, and</li>
|
||||
<li>The message
|
||||
<span class="math">\(msg\)</span>
|
||||
to be signed.</li>
|
||||
|
|
@ -151,7 +151,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<span class="math">\(path\)</span>
|
||||
be the Merkle path from position 0 to
|
||||
<span class="math">\(\mathsf{rt}\)</span>
|
||||
. <a id="id13" class="footnote_reference" href="#protocol-merklepath">4</a></li>
|
||||
. <a id="footnote-reference-13" class="footnote_reference" href="#protocol-merklepath">4</a></li>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{cv} = \mathsf{ValueCommit}_0(1)\)</span>
|
||||
.
|
||||
|
|
@ -174,7 +174,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<span class="math">\((\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})\)</span>
|
||||
and auxiliary input
|
||||
<span class="math">\((path, 0, \mathsf{g_d}, \mathsf{pk_d}, 1, 0, \mathsf{cm}, 0, α, \mathsf{ak}, \mathsf{nsk})\)</span>
|
||||
. <a id="id14" class="footnote_reference" href="#protocol-spendstatement">5</a></li>
|
||||
. <a id="footnote-reference-14" class="footnote_reference" href="#protocol-spendstatement">5</a></li>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{rsk} = \mathsf{SpendAuthSig.RandomizePrivate}(α, \mathsf{ask})\)</span>
|
||||
.</li>
|
||||
|
|
@ -198,7 +198,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<li>The payment address
|
||||
<span class="math">\((\mathsf{d}, \mathsf{pk_d})\)</span>
|
||||
,</li>
|
||||
<li>The SLIP-44 <a id="id15" class="footnote_reference" href="#slip-0044">15</a> coin type,</li>
|
||||
<li>The SLIP-44 <a id="footnote-reference-15" class="footnote_reference" href="#slip-0044">15</a> coin type,</li>
|
||||
<li>The message
|
||||
<span class="math">\(msg\)</span>
|
||||
that is claimed to be signed, and</li>
|
||||
|
|
@ -235,7 +235,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<span class="math">\(path\)</span>
|
||||
be the Merkle path from position 0 to
|
||||
<span class="math">\(\mathsf{rt}\)</span>
|
||||
. <a id="id16" class="footnote_reference" href="#protocol-merklepath">4</a></li>
|
||||
. <a id="footnote-reference-16" class="footnote_reference" href="#protocol-merklepath">4</a></li>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{cv} = \mathsf{ValueCommit}_0(1)\)</span>
|
||||
.
|
||||
|
|
@ -247,7 +247,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
<span class="math">\(zkproof\)</span>
|
||||
as a Sapling spend proof with primary input
|
||||
<span class="math">\((\mathsf{rt}, \mathsf{cv}, \mathsf{nf}, \mathsf{rk})\)</span>
|
||||
. <a id="id17" class="footnote_reference" href="#protocol-spendstatement">5</a> If verification fails, return false.</li>
|
||||
. <a id="footnote-reference-17" class="footnote_reference" href="#protocol-spendstatement">5</a> If verification fails, return false.</li>
|
||||
<li>Return true.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
|
@ -257,7 +257,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/376">https://githu
|
|||
, for a total size of 320 bytes.</p>
|
||||
<p>When encoding a ZIP 304 signature in a human-readable format, implementations <strong>SHOULD</strong> use standard Base64 for compatibility with the <code>signmessage</code> and <code>verifymessage</code> RPC methods in <code>zcashd</code>. ZIP 304 signatures in this form are 428 bytes. The encoded form is the string
|
||||
<span class="math">\(\texttt{"zip304:"}\)</span>
|
||||
followed by the result of Base64-encoding <a id="id18" class="footnote_reference" href="#rfc4648">2</a> the raw form of the signature.</p>
|
||||
followed by the result of Base64-encoding <a id="footnote-reference-18" class="footnote_reference" href="#rfc4648">2</a> the raw form of the signature.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Status: Draft
|
|||
Created: 2018-09-17
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Light client</dt>
|
||||
|
|
@ -39,7 +39,7 @@ License: MIT</pre>
|
|||
<li><strong>Light client</strong> that subscribes to the stream from a proxy server and uses that data to update its own view of the chain state. The light client MAY be attached to a wallet backend that will track particular Sapling notes.</li>
|
||||
</ul>
|
||||
<figure class="align-center" align="center">
|
||||
<img src="zip-0307-arch.png" />
|
||||
<img src="zip-0307-arch.png" alt="" />
|
||||
<figcaption>Outline of the light wallet architecture</figcaption>
|
||||
</figure>
|
||||
</section>
|
||||
|
|
@ -56,40 +56,40 @@ License: MIT</pre>
|
|||
<li>Detect a spend of your shielded Sapling notes</li>
|
||||
<li>Update your witnesses to generate new Sapling spend proofs.</li>
|
||||
</ol>
|
||||
<p>A compact block and its component compact transactions are encoded on the wire using the following Protocol Buffers <a id="id2" class="footnote_reference" href="#protocolbuffers">9</a> format:</p>
|
||||
<pre data-language="proto"><span class="kd">message</span> <span class="nc">BlockID</span> <span class="p">{</span>
|
||||
<span class="kt">uint64</span> <span class="na">blockHeight</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="kt">bytes</span> <span class="na">blockHash</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
|
||||
<p>A compact block and its component compact transactions are encoded on the wire using the following Protocol Buffers <a id="footnote-reference-2" class="footnote_reference" href="#protocolbuffers">9</a> format:</p>
|
||||
<pre data-language="proto"><span class="kd">message</span><span class="w"> </span><span class="nc">BlockID</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">blockHeight</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">blockHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="kd">message</span> <span class="nc">CompactBlock</span> <span class="p">{</span>
|
||||
<span class="n">BlockID</span> <span class="na">id</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="k">repeated</span> <span class="n">CompactTx</span> <span class="na">vtx</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">CompactBlock</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="k">repeated</span><span class="w"> </span><span class="n">CompactTx</span><span class="w"> </span><span class="na">vtx</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">3</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="kd">message</span> <span class="nc">CompactTx</span> <span class="p">{</span>
|
||||
<span class="kt">uint64</span> <span class="na">txIndex</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="kt">bytes</span> <span class="na">txHash</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">CompactTx</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">txIndex</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">txHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
|
||||
|
||||
<span class="k">repeated</span> <span class="n">CompactSpend</span> <span class="na">spends</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
|
||||
<span class="k">repeated</span> <span class="n">CompactOutput</span> <span class="na">outputs</span> <span class="o">=</span> <span class="mi">4</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="k">repeated</span><span class="w"> </span><span class="n">CompactSpend</span><span class="w"> </span><span class="na">spends</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">3</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="k">repeated</span><span class="w"> </span><span class="n">CompactOutput</span><span class="w"> </span><span class="na">outputs</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">4</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="kd">message</span> <span class="nc">CompactSpend</span> <span class="p">{</span>
|
||||
<span class="kt">bytes</span> <span class="na">nf</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">CompactSpend</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">nf</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="kd">message</span> <span class="nc">CompactOutput</span> <span class="p">{</span>
|
||||
<span class="kt">bytes</span> <span class="na">cmu</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="kt">bytes</span> <span class="na">epk</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
|
||||
<span class="kt">bytes</span> <span class="na">ciphertext</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">CompactOutput</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">cmu</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">epk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">ciphertext</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">3</span><span class="p">;</span>
|
||||
<span class="p">}</span></pre>
|
||||
<section id="encoding-details"><h3><span class="section-heading">Encoding Details</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-details"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p><code>blockHash</code>, <code>txHash</code>, <code>nf</code>, <code>cmu</code>, and <code>epk</code> are encoded as specified in the Zcash Protocol Spec.</p>
|
||||
<p>The output and spend descriptions are handled differently, as described in the following sections.</p>
|
||||
</section>
|
||||
<section id="output-compression"><h3><span class="section-heading">Output Compression</span><span class="section-anchor"> <a rel="bookmark" href="#output-compression"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a <em>note plaintext</em> <a id="id3" class="footnote_reference" href="#protocol-notept">5</a>:</p>
|
||||
<p>In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a <em>note plaintext</em> <a id="footnote-reference-3" class="footnote_reference" href="#protocol-notept">5</a>:</p>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
|
|
@ -107,7 +107,7 @@ License: MIT</pre>
|
|||
<p>Since the note commitment is sent outside the ciphertext and is authenticated by the binding signature over the entire transaction, it serves as an adequate check on the validity of the decrypted plaintext (assuming you trust the entity assembling transactions). We therefore recalculate the note commitment from the decrypted plaintext. If the recalculated commitment matches the one in the output, we accept the note as valid and spendable.</p>
|
||||
</section>
|
||||
<section id="spend-compression"><h3><span class="section-heading">Spend Compression</span><span class="section-anchor"> <a rel="bookmark" href="#spend-compression"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Recall that a full Sapling Spend description is 384 bytes long <a id="id4" class="footnote_reference" href="#protocol-spendencoding">6</a>:</p>
|
||||
<p>Recall that a full Sapling Spend description is 384 bytes long <a id="footnote-reference-4" class="footnote_reference" href="#protocol-spendencoding">6</a>:</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
|
|
@ -156,38 +156,38 @@ License: MIT</pre>
|
|||
<p>The proxy's purpose is to provide a scalable and bandwidth-efficient interface between a Zcash node and any number of light clients. It accomplishes this by parsing a blockwise stream of transactions from the node and converting them into the compact format described above.</p>
|
||||
<p><em>The details of the API described below may differ from the implementation.</em></p>
|
||||
<p>The proxy offers the following API to clients:</p>
|
||||
<pre data-language="proto"><span class="kd">service</span> <span class="n">CompactTxStreamer</span> <span class="p">{</span>
|
||||
<span class="k">rpc</span> <span class="n">GetLatestBlock</span><span class="p">(</span><span class="n">ChainSpec</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">BlockID</span><span class="p">)</span> <span class="p">{}</span>
|
||||
<span class="k">rpc</span> <span class="n">GetBlock</span><span class="p">(</span><span class="n">BlockID</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">CompactBlock</span><span class="p">)</span> <span class="p">{}</span>
|
||||
<span class="k">rpc</span> <span class="n">GetBlockRange</span><span class="p">(</span><span class="n">RangeFilter</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">stream</span> <span class="n">CompactBlock</span><span class="p">)</span> <span class="p">{}</span>
|
||||
<span class="k">rpc</span> <span class="n">GetTransaction</span><span class="p">(</span><span class="n">TxFilter</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">FullTransaction</span><span class="p">)</span> <span class="p">{}</span>
|
||||
<pre data-language="proto"><span class="kd">service</span><span class="w"> </span><span class="n">CompactTxStreamer</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetLatestBlock</span><span class="p">(</span><span class="n">ChainSpec</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">BlockID</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
|
||||
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetBlock</span><span class="p">(</span><span class="n">BlockID</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">CompactBlock</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
|
||||
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetBlockRange</span><span class="p">(</span><span class="n">RangeFilter</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">stream</span><span class="w"> </span><span class="n">CompactBlock</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
|
||||
<span class="w"> </span><span class="k">rpc</span><span class="w"> </span><span class="n">GetTransaction</span><span class="p">(</span><span class="n">TxFilter</span><span class="p">)</span><span class="w"> </span><span class="k">returns</span><span class="w"> </span><span class="p">(</span><span class="n">FullTransaction</span><span class="p">)</span><span class="w"> </span><span class="p">{}</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="c1">// Remember that proto3 fields are all optional.</span>
|
||||
|
||||
<span class="c1">// Someday we may want to specify e.g. a particular chain fork.</span>
|
||||
<span class="kd">message</span> <span class="nc">ChainSpec</span> <span class="p">{}</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">ChainSpec</span><span class="w"> </span><span class="p">{}</span>
|
||||
|
||||
|
||||
<span class="c1">// A BlockID message contains identifiers to select a block: either a</span>
|
||||
<span class="c1">// height or a hash.</span>
|
||||
<span class="kd">message</span> <span class="nc">BlockID</span> <span class="p">{</span>
|
||||
<span class="kt">uint64</span> <span class="na">blockHeight</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="kt">bytes</span> <span class="na">blockHash</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">BlockID</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">blockHeight</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">blockHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
|
||||
<span class="kd">message</span> <span class="nc">RangeFilter</span> <span class="p">{</span>
|
||||
<span class="n">BlockID</span> <span class="na">start</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="n">BlockID</span> <span class="na">end</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">RangeFilter</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">start</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">end</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
|
||||
<span class="p">}</span>
|
||||
|
||||
<span class="c1">// A TxFilter contains the information needed to identify a particular</span>
|
||||
<span class="c1">// transaction: either a block and an index, or a direct transaction hash.</span>
|
||||
<span class="kd">message</span> <span class="nc">TxFilter</span> <span class="p">{</span>
|
||||
<span class="n">BlockID</span> <span class="na">blockID</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
|
||||
<span class="kt">uint64</span> <span class="na">txIndex</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
|
||||
<span class="kt">bytes</span> <span class="na">txHash</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
|
||||
<span class="kd">message</span><span class="w"> </span><span class="nc">TxFilter</span><span class="w"> </span><span class="p">{</span>
|
||||
<span class="w"> </span><span class="n">BlockID</span><span class="w"> </span><span class="na">blockID</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">1</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="kt">uint64</span><span class="w"> </span><span class="na">txIndex</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">2</span><span class="p">;</span>
|
||||
<span class="w"> </span><span class="kt">bytes</span><span class="w"> </span><span class="na">txHash</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">3</span><span class="p">;</span>
|
||||
<span class="p">}</span></pre>
|
||||
</section>
|
||||
<section id="client-operation"><h2><span class="section-heading">Client operation</span><span class="section-anchor"> <a rel="bookmark" href="#client-operation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -201,7 +201,7 @@ License: MIT</pre>
|
|||
<span class="math">\((\mathtt{cmu}, \mathtt{ephemeralKey}, \mathsf{ciphertext})\)</span>
|
||||
with an incoming viewing key
|
||||
<span class="math">\(\mathsf{ivk}\)</span>
|
||||
is a slight deviation from the standard decryption process <a id="id5" class="footnote_reference" href="#protocol-saplingdecryptivk">4</a> (all constants and algorithms are as defined there):</p>
|
||||
is a slight deviation from the standard decryption process <a id="footnote-reference-5" class="footnote_reference" href="#protocol-saplingdecryptivk">4</a> (all constants and algorithms are as defined there):</p>
|
||||
<ul>
|
||||
<li>let
|
||||
<span class="math">\(\mathsf{epk} = \mathsf{abst}_{\mathbb{J}}(\mathtt{ephemeralKey})\)</span>
|
||||
|
|
@ -293,7 +293,7 @@ License: MIT</pre>
|
|||
</ul>
|
||||
</section>
|
||||
<section id="creating-and-updating-note-witnesses"><h4><span class="section-heading">Creating and updating note witnesses</span><span class="section-anchor"> <a rel="bookmark" href="#creating-and-updating-note-witnesses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>As <code>CompactBlocks</code> are received in height order, and the transactions within them have their order preserved, the <em>cmu</em> values in each <code>CompactOutput</code> can be sequentially appended to an incremental Merkle tree of depth 32 in order to maintain a local copy of the Sapling note commitment tree. <a id="id6" class="footnote_reference" href="#protocol-merkletree">2</a> This can then be used to create incremental witnesses for each unspent note the light client is tracking. <a id="id7" class="footnote_reference" href="#incremental-witness">10</a> An incremental witness updated to height <code>X</code> corresponds to a Merkle path from the note to the Sapling commitment tree anchor for block <code>X</code>. <a id="id8" class="footnote_reference" href="#protocol-merklepath">3</a></p>
|
||||
<p>As <code>CompactBlocks</code> are received in height order, and the transactions within them have their order preserved, the <em>cmu</em> values in each <code>CompactOutput</code> can be sequentially appended to an incremental Merkle tree of depth 32 in order to maintain a local copy of the Sapling note commitment tree. <a id="footnote-reference-6" class="footnote_reference" href="#protocol-merkletree">2</a> This can then be used to create incremental witnesses for each unspent note the light client is tracking. <a id="footnote-reference-7" class="footnote_reference" href="#incremental-witness">10</a> An incremental witness updated to height <code>X</code> corresponds to a Merkle path from the note to the Sapling commitment tree anchor for block <code>X</code>. <a id="footnote-reference-8" class="footnote_reference" href="#protocol-merklepath">3</a></p>
|
||||
<p>Let <code>tree</code> be the Sapling note commitment tree at height <code>X-1</code>, and <code>note_witnesses</code> be the incremental witnesses for unspent notes detected up to height <code>X-1</code>. When the <code>CompactBlock</code> at height <code>X</code> is received:</p>
|
||||
<ul>
|
||||
<li>For each <code>CompactTx</code> in <code>CompactBlock</code>:
|
||||
|
|
@ -319,7 +319,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="block-header-validation"><h4><span class="section-heading">Block header validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p><em>This section describes a proposed enhancement that has been only partially implemented: currently only</em> <code>prevHash</code> <em>is checked.</em></p>
|
||||
<p>If the <code>CompactBlock</code> for height <code>X</code> contains a block header, the light client can validate it in a similar way to SPV clients <a id="id9" class="footnote_reference" href="#spv-clients">11</a> by performing the following checks:</p>
|
||||
<p>If the <code>CompactBlock</code> for height <code>X</code> contains a block header, the light client can validate it in a similar way to SPV clients <a id="footnote-reference-9" class="footnote_reference" href="#spv-clients">11</a> by performing the following checks:</p>
|
||||
<ul>
|
||||
<li><code>version >= MIN_BLOCK_VERSION</code></li>
|
||||
<li><code>prevHash == prevBlock.id.blockHash</code> where <code>prevBlock</code> is the previous <code>CompactBlock</code> received (at height <code>X-1</code>).</li>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Category: Standards / RPC / Wallet
|
|||
Created: 2018-11-27
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Sprout protocol</dt>
|
||||
|
|
@ -29,9 +29,9 @@ License: MIT</pre>
|
|||
<p>This proposal describes privacy-preserving procedures to migrate funds from Sprout to Sapling z-addresses; and supporting RPC operations to enable, disable, and monitor the migration process.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash Sapling <a id="id2" class="footnote_reference" href="#zip-0205">4</a> introduces significant efficiency improvements relative to the previous iteration of the Zcash shielded protocol, Sprout. These improvements will pave the way for broad mobile, exchange and vendor adoption of shielded addresses.</p>
|
||||
<p>Zcash Sapling <a id="footnote-reference-2" class="footnote_reference" href="#zip-0205">4</a> introduces significant efficiency improvements relative to the previous iteration of the Zcash shielded protocol, Sprout. These improvements will pave the way for broad mobile, exchange and vendor adoption of shielded addresses.</p>
|
||||
<p>Therefore, we anticipate that users will want to migrate all their shielded funds from Sprout to Sapling.</p>
|
||||
<p>The Zcash consensus rules prohibit direct transfers from Sprout to Sapling z-addresses, unless the amount is revealed by sending it through the "transparent value pool" <a id="id3" class="footnote_reference" href="#transparent-value-pool">2</a>. The primary motivation for this is to allow detection of any overall inflation of the Zcash monetary base, due to exploitation of possible vulnerabilities in the shielded protocols or their implementation, or a compromise of the Sprout multi-party computation. (It is not necessary for Sprout -> Sapling transfers to go via a t-address.)</p>
|
||||
<p>The Zcash consensus rules prohibit direct transfers from Sprout to Sapling z-addresses, unless the amount is revealed by sending it through the "transparent value pool" <a id="footnote-reference-3" class="footnote_reference" href="#transparent-value-pool">2</a>. The primary motivation for this is to allow detection of any overall inflation of the Zcash monetary base, due to exploitation of possible vulnerabilities in the shielded protocols or their implementation, or a compromise of the Sprout multi-party computation. (It is not necessary for Sprout -> Sapling transfers to go via a t-address.)</p>
|
||||
<p>Since the exposure of the migrated amount potentially compromises the privacy of users, we wish to define a way to perform the migration that mitigates this privacy leak as far as possible. This can be done by hiding individual migration transactions among those of all users that are doing the migration at around the same time.</p>
|
||||
<p>The security analysis of migration strategies is quite subtle; the more obvious potential strategies can leak a lot of information.</p>
|
||||
</section>
|
||||
|
|
@ -68,7 +68,7 @@ License: MIT</pre>
|
|||
<section id="transaction-schedule"><h3><span class="section-heading">Transaction schedule</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-schedule"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When migration is enabled, a node will send up to 5 transactions for inclusion in each block with height a multiple of 500 (that is, they are sent immediately after seeing a block with height 499, modulo 500). Up to the limit of 5, as many transactions are sent as are needed to migrate the remaining funds (possibly with a remainder less than 0.01 ZEC left unmigrated).</p>
|
||||
<p>Nodes SHOULD NOT send migration transactions during initial block download, or if the timestamp of the triggering block (with height 499, modulo 500) is more than three hours in the past according to the node's adjusted local clock.</p>
|
||||
<p>Note: the 500-block interval has <em>not</em> been altered as a result of the halving of target block spacing to 75 seconds with the Blossom upgrade. <a id="id4" class="footnote_reference" href="#zip-0208">5</a></p>
|
||||
<p>Note: the 500-block interval has <em>not</em> been altered as a result of the halving of target block spacing to 75 seconds with the Blossom upgrade. <a id="footnote-reference-4" class="footnote_reference" href="#zip-0208">5</a></p>
|
||||
<p>The migration transactions to be sent in a particular batch can take significant time to generate, and this time depends on the speed of the user's computer. If they were generated only after a block is seen at the target height minus 1, then this could leak information. Therefore, for target height N, implementations SHOULD start generating the transactions at around height N-5 (provided that block's timestamp is not more than three hours in the past). Each migration transaction SHOULD specify an anchor at height N-10 for each Sprout JoinSplit description (and therefore only notes created before this anchor are eligible for migration).</p>
|
||||
<p>Open questions:</p>
|
||||
<ul>
|
||||
|
|
@ -130,7 +130,7 @@ License: MIT</pre>
|
|||
</table>
|
||||
<p>(The estimated times for larger amounts halved as a result of the target block spacing change in Blossom.)</p>
|
||||
<p>The simulation also depends on the amounts sent as specified in the next section. It includes the time spent waiting for the first batch to be sent.</p>
|
||||
<p>The code used for this simulation is at <a id="id5" class="footnote_reference" href="#migration-simulator">6</a>.</p>
|
||||
<p>The code used for this simulation is at <a id="footnote-reference-5" class="footnote_reference" href="#migration-simulator">6</a>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="how-much-to-send-in-each-transaction"><h3><span class="section-heading">How much to send in each transaction</span><span class="section-anchor"> <a rel="bookmark" href="#how-much-to-send-in-each-transaction"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -178,7 +178,7 @@ License: MIT</pre>
|
|||
<pre>-migration=0/1</pre>
|
||||
<p>The destination z-address can optionally be set by another option:</p>
|
||||
<pre>-migrationdestaddress=<zaddr></pre>
|
||||
<p>If this option is not present then the migration destination address is the address for Sapling account 0, with the default diversifier <a id="id6" class="footnote_reference" href="#zip-0032">3</a>.</p>
|
||||
<p>If this option is not present then the migration destination address is the address for Sapling account 0, with the default diversifier <a id="footnote-reference-6" class="footnote_reference" href="#zip-0032">3</a>.</p>
|
||||
<p>The state variable can also be set for a running node using the following RPC method:</p>
|
||||
<pre>z_setmigration true/false</pre>
|
||||
<p>It is intentional that the only option associated with the migration is the destination z-address. Other options could potentially distinguish users.</p>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ License: MIT</pre>
|
|||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<dl>
|
||||
<dt>Sapling FVK</dt>
|
||||
<dd>A Sapling full viewing key as described in <a id="id1" class="footnote_reference" href="#protocol">1</a>, or a Sapling extended full viewing key as described in <a id="id2" class="footnote_reference" href="#zip-0032">3</a>.</dd>
|
||||
<dd>A Sapling full viewing key as described in <a id="footnote-reference-1" class="footnote_reference" href="#protocol">1</a>, or a Sapling extended full viewing key as described in <a id="footnote-reference-2" class="footnote_reference" href="#zip-0032">3</a>.</dd>
|
||||
<dt>GUARANTEED</dt>
|
||||
<dd>Information that can be learned by the holder of a Sapling FVK, and ensured to be correct by the Sapling protocol, given the cryptographic assumptions underlying that protocol.</dd>
|
||||
<dt>UNVERIFIED</dt>
|
||||
|
|
@ -115,7 +115,7 @@ License: MIT</pre>
|
|||
<p>The balance of a tally after a particular block is defined as the sum of note values that are spendable, according to the Sapling protocol, using the extended spending key associated with the tally, in a block chain that extends from that block.</p>
|
||||
<p>Ian can attempt to keep track of a given tally’s balance as of a given block. This would be done as follows:</p>
|
||||
<ul>
|
||||
<li>Scan the chain from Sapling activation up to and including the specified block, collecting all of the Sapling spends and Sapling outputs up to and including that block that are relevant to the FVK, as specified in section 4.19 of the Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-saplingscan">2</a>. This produces a ReceivedSet of notes that were received by that tally, and a SpentSet of notes that were spent from it.</li>
|
||||
<li>Scan the chain from Sapling activation up to and including the specified block, collecting all of the Sapling spends and Sapling outputs up to and including that block that are relevant to the FVK, as specified in section 4.19 of the Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-saplingscan">2</a>. This produces a ReceivedSet of notes that were received by that tally, and a SpentSet of notes that were spent from it.</li>
|
||||
<li>Compute the balance as the sum of the values of all notes appearing in ReceivedSet but not in SpentSet.</li>
|
||||
</ul>
|
||||
<p>The following inaccuracies may occur in balance accounting:</p>
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/408">https://githu
|
|||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The goal of this ZIP is to gather wallet developers, miners & Zcash users for social consensus on reducing the conventional transaction fees and to get the Zcash conventional transaction fee reduced from 10,000 zatoshis to 1,000 zatoshis.</p>
|
||||
<p>In addition, this specification harmonizes transaction fees between different kinds of transaction (involving shielded addresses, transparent addresses, or both), as proposed in <a id="id1" class="footnote_reference" href="#zcash-2942">6</a>.</p>
|
||||
<p>In addition, this specification harmonizes transaction fees between different kinds of transaction (involving shielded addresses, transparent addresses, or both), as proposed in <a id="footnote-reference-1" class="footnote_reference" href="#zcash-2942">6</a>.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The conventional transaction fee presently is 0.0001 ZEC or 10,000 zatoshis. At a ZEC market price of USD 100, for example, a user can send 10,000 transactions for 1 ZEC. This works out to 1 U.S. cent per transaction and it rises with any increase in the price of ZEC.</p>
|
||||
|
|
@ -43,8 +43,8 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/408">https://githu
|
|||
</section>
|
||||
<section id="security-and-privacy-considerations"><h3><span class="section-heading">Security and privacy considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Unique transaction fees may reveal specific users or wallets or wallet versions, which would reduce privacy for those specific users and the rest of the network. Hence this change should be accepted by a majority of shielded transaction software providers before deploying the change.</p>
|
||||
<p>Varying/unique fees are bad for privacy. For the short term before blocks get full, it is fine for everyone to use a constant fee, as long as it is enough to compensate miners for including the transaction. <a id="id2" class="footnote_reference" href="#nathan-1">1</a></p>
|
||||
<p>Long term, the issue of fees needs to be re-visited in separate future proposals as the blocks start getting consistently full. New ZIPs with flexible fees, such as <a id="id3" class="footnote_reference" href="#ian-1">2</a>, along with scaling solutions, will need to be evaluated and applied.</p>
|
||||
<p>Varying/unique fees are bad for privacy. For the short term before blocks get full, it is fine for everyone to use a constant fee, as long as it is enough to compensate miners for including the transaction. <a id="footnote-reference-2" class="footnote_reference" href="#nathan-1">1</a></p>
|
||||
<p>Long term, the issue of fees needs to be re-visited in separate future proposals as the blocks start getting consistently full. New ZIPs with flexible fees, such as <a id="footnote-reference-3" class="footnote_reference" href="#ian-1">2</a>, along with scaling solutions, will need to be evaluated and applied.</p>
|
||||
<section id="denial-of-service-vulnerability"><h4><span class="section-heading">Denial of Service Vulnerability</span><span class="section-anchor"> <a rel="bookmark" href="#denial-of-service-vulnerability"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>A transaction-rate-based denial of service attack occurs when an attacker generates enough transactions over a window of time to prevent legitimate transactions from being mined, or to hinder syncing blocks for full nodes or miners.</p>
|
||||
<p>There are two primary protections to this kind of attack in Zcash: the block size limit, and transaction fees. The block size limit ensures that full nodes and miners can keep up with the block chain even if blocks are completely full. However, users sending legitimate transactions may not have their transactions confirmed in a timely manner.</p>
|
||||
|
|
@ -58,10 +58,10 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/408">https://githu
|
|||
<p>Wallets implementing this specification will use a default fee of 0.00001 ZEC (1000 zatoshis) from block 1,080,000, for all transactions.</p>
|
||||
<section id="transaction-relaying"><h3><span class="section-heading">Transaction relaying</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-relaying"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>zcashd, and potentially other node implementations, implements fee-based restrictions on relaying of mempool transactions. Nodes that normally relay transactions are expected to do so for transactions that pay at least the conventional fee, unless there are other reasons not to do so for robustness or denial-of-service mitigation.</p>
|
||||
<p>In zcashd 4.2.0, this change is implemented by <a id="id4" class="footnote_reference" href="#zcash-relaying">7</a>.</p>
|
||||
<p>In zcashd 4.2.0, this change is implemented by <a id="footnote-reference-4" class="footnote_reference" href="#zcash-relaying">7</a>.</p>
|
||||
</section>
|
||||
<section id="mempool-size-limiting"><h3><span class="section-heading">Mempool size limiting</span><span class="section-anchor"> <a rel="bookmark" href="#mempool-size-limiting"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>zcashd limits the size of the mempool as described in <a id="id5" class="footnote_reference" href="#zip-0401">8</a>. This specifies a <em>low_fee_penalty</em> that is added to the "eviction weight" if the transaction pays a fee less than (in the original ZIP) 10,000 zatoshis. This threshold is modified to match the new conventional fee in zcashd 4.2.0.</p>
|
||||
<p>zcashd limits the size of the mempool as described in <a id="footnote-reference-5" class="footnote_reference" href="#zip-0401">8</a>. This specifies a <em>low_fee_penalty</em> that is added to the "eviction weight" if the transaction pays a fee less than (in the original ZIP) 10,000 zatoshis. This threshold is modified to match the new conventional fee in zcashd 4.2.0.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="support"><h2><span class="section-heading">Support</span><span class="section-anchor"> <a rel="bookmark" href="#support"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -70,9 +70,9 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/408">https://githu
|
|||
<li>Zbay;</li>
|
||||
<li>Zecwallet Suite (Zecwallet Lite for Desktop/iOS/Android & Zecwallet FullNode);</li>
|
||||
<li>Nighthawk Wallet for Android & iOS;</li>
|
||||
<li>zcashd built-in wallet <a id="id6" class="footnote_reference" href="#zcash-4916">5</a>.</li>
|
||||
<li>zcashd built-in wallet <a id="footnote-reference-6" class="footnote_reference" href="#zcash-4916">5</a>.</li>
|
||||
</ul>
|
||||
<p>In zcashd this fee change is implemented in version 4.2.0 (not dependent on block height), and in that version is limited to transactions created using <cite>z_*</cite> RPC APIs. It is planned to extend this to all transactions in a future version <a id="id7" class="footnote_reference" href="#zcash-2942">6</a>.</p>
|
||||
<p>In zcashd this fee change is implemented in version 4.2.0 (not dependent on block height), and in that version is limited to transactions created using <cite>z_*</cite> RPC APIs. It is planned to extend this to all transactions in a future version <a id="footnote-reference-7" class="footnote_reference" href="#zcash-2942">6</a>.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Thanks to Nathan Wilcox for suggesting improvements to the denial of service section. Thanks to Daira Hopwood and Deirdre Connolly for reviewing and fixing the wording in this ZIP.</p>
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Created: 2021-04-07
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://github.com/zcash/zips/issues/482</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Recipient</dt>
|
||||
|
|
@ -62,7 +62,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<dt>Address Encoding</dt>
|
||||
<dd>The externally visible encoding of an Address (e.g. as a string of characters or a QR code).</dd>
|
||||
</dl>
|
||||
<p>Notation for sequences, conversions, and arithmetic operations follows the Zcash protocol specification <a id="id2" class="footnote_reference" href="#protocol-notation">3</a>.</p>
|
||||
<p>Notation for sequences, conversions, and arithmetic operations follows the Zcash protocol specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol-notation">3</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines Unified Addresses, which bundle together Zcash Addresses of different types in a way that can be presented as a single Address Encoding. It also defines Unified Viewing Keys, which perform a similar function for Zcash viewing keys.</p>
|
||||
|
|
@ -74,8 +74,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>Sprout Addresses</li>
|
||||
<li>Sapling Addresses</li>
|
||||
</ul>
|
||||
<p>Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding as described in <a id="id3" class="footnote_reference" href="#protocol-addressandkeyencoding">8</a>, for many purposes it suffices to consider the string encoding.)</p>
|
||||
<p>The Orchard proposal <a id="id4" class="footnote_reference" href="#zip-0224">24</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<p>Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding as described in <a id="footnote-reference-3" class="footnote_reference" href="#protocol-addressandkeyencoding">8</a>, for many purposes it suffices to consider the string encoding.)</p>
|
||||
<p>The Orchard proposal <a id="footnote-reference-4" class="footnote_reference" href="#zip-0224">24</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<p>The difficulty with defining new Address Encodings for each Address type, is that end-users are forced to be aware of the various types, and in particular which types are supported by a given Consumer or Recipient. In order to make sure that transfers are completed successfully, users may be forced to explicitly generate Addresses of different types and re-distribute encodings of them, which adds significant friction and cognitive overhead to understanding and using Zcash.</p>
|
||||
<p>The goals for a Unified Address standard are as follows:</p>
|
||||
<ul>
|
||||
|
|
@ -95,7 +95,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="overview"><h3><span class="section-heading">Overview</span><span class="section-anchor"> <a rel="bookmark" href="#overview"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Unified Addresses specify multiple methods for payment to a Recipient's Wallet. The Sender's Wallet can then non-interactively select the method of payment.</p>
|
||||
<p>Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id5" class="footnote_reference" href="#zip-0321">26</a> and similar schemes. Since Payment Requests encode addresses as alphanumeric strings, no change to ZIP 321 is required in order to use Unified Addresses in Payment Requests.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="footnote-reference-5" class="footnote_reference" href="#zip-0321">26</a> and similar schemes. Since Payment Requests encode addresses as alphanumeric strings, no change to ZIP 321 is required in order to use Unified Addresses in Payment Requests.</p>
|
||||
</section>
|
||||
<section id="concepts"><h3><span class="section-heading">Concepts</span><span class="section-anchor"> <a rel="bookmark" href="#concepts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallets follow a model <em>Interaction Flow</em> as follows:</p>
|
||||
|
|
@ -123,7 +123,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards.</p>
|
||||
<p>There is a well-defined encoding of a Unified Address (or UFVK or UIVK) as a QR Code, which produces QR codes that are reasonably compact and robust.</p>
|
||||
<p>There is a well-defined transformation between the QR Code and string encodings in either direction.</p>
|
||||
<p>The string encoding fits into ZIP-321 Payment URIs <a id="id6" class="footnote_reference" href="#zip-0321">26</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The string encoding fits into ZIP-321 Payment URIs <a id="footnote-reference-6" class="footnote_reference" href="#zip-0321">26</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion.</p>
|
||||
<p>The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.</p>
|
||||
</section>
|
||||
|
|
@ -140,8 +140,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>Unified Addresses and Unified Viewing Keys must be able to include Receivers and Viewing Keys of experimental types, possibly alongside non-experimental ones. These experimental Receivers or Viewing Keys must be used only by wallets whose users have explicitly opted into the corresponding experiment.</p>
|
||||
</section>
|
||||
<section id="viewing-keys"><h3><span class="section-heading">Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key) as described in the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="id8" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="id9" class="footnote_reference" href="#bip-0044">30</a>, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.</p>
|
||||
<p>A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key) as described in the Zcash Protocol Specification <a id="footnote-reference-7" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="footnote-reference-8" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="footnote-reference-9" class="footnote_reference" href="#bip-0044">30</a>, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.</p>
|
||||
<p>A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.</p>
|
||||
</section>
|
||||
<section id="open-issues-and-known-concerns"><h3><span class="section-heading">Open Issues and Known Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues-and-known-concerns"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -155,10 +155,10 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<ul>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x03}\)</span>
|
||||
— an Orchard raw address as defined in <a id="id10" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">10</a>;</li>
|
||||
— an Orchard raw address as defined in <a id="footnote-reference-10" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">10</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
— a Sapling raw address as defined in <a id="id11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">9</a>;</li>
|
||||
— a Sapling raw address as defined in <a id="footnote-reference-11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">9</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
— a Transparent P2SH address, <em>or</em> Typecode
|
||||
|
|
@ -196,9 +196,9 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
in practice.)</p>
|
||||
<p>A Receiver Encoding is the raw encoding of a Shielded Payment Address, or the
|
||||
<span class="math">\(160\!\)</span>
|
||||
-bit script hash of a P2SH address <a id="id12" class="footnote_reference" href="#p2sh">35</a>, or the
|
||||
-bit script hash of a P2SH address <a id="footnote-reference-12" class="footnote_reference" href="#p2sh">35</a>, or the
|
||||
<span class="math">\(160\!\)</span>
|
||||
-bit validating key hash of a P2PKH address <a id="id13" class="footnote_reference" href="#p2pkh">34</a>.</p>
|
||||
-bit validating key hash of a P2PKH address <a id="footnote-reference-13" class="footnote_reference" href="#p2pkh">34</a>.</p>
|
||||
<p>Let <code>padding</code> be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append <code>padding</code> to the concatenated encodings, and then apply the
|
||||
<span class="math">\(\mathsf{F4Jumble}\)</span>
|
||||
algorithm as described in <a href="#jumbling">Jumbling</a>. (In order for the limitation on the
|
||||
|
|
@ -207,7 +207,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\ell^\mathsf{MAX}_M - 16\)</span>
|
||||
bytes, where
|
||||
<span class="math">\(\ell^\mathsf{MAX}_M\)</span>
|
||||
is defined in <a href="#jumbling">Jumbling</a>.) The output is then encoded with Bech32m <a id="id14" class="footnote_reference" href="#bip-0350">33</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
is defined in <a href="#jumbling">Jumbling</a>.) The output is then encoded with Bech32m <a id="footnote-reference-14" class="footnote_reference" href="#bip-0350">33</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
<p>To decode a Unified Address Encoding, a Consumer MUST use the following procedure:</p>
|
||||
<ul>
|
||||
<li>Decode using Bech32m, rejecting any address with an incorrect checksum.</li>
|
||||
|
|
@ -217,7 +217,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>Let <code>padding</code> be the Human-Readable Part, padded to 16 bytes as for encoding. If the result ends in <code>padding</code>, remove these 16 bytes; otherwise reject.</li>
|
||||
<li>Parse the result as a raw encoding as described above, rejecting the entire Unified Address if it does not parse correctly.</li>
|
||||
</ul>
|
||||
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id15" class="footnote_reference" href="#bip-0350">33</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="footnote-reference-15" class="footnote_reference" href="#bip-0350">33</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>A wallet MAY allow its user(s) to configure which Receiver Types it can send to. It MUST NOT allow the user(s) to change the order of the Priority List used to choose the Receiver Type, except by opting into experiments.</p>
|
||||
</section>
|
||||
<section id="encoding-of-unified-full-incoming-viewing-keys"><h3><span class="section-heading">Encoding of Unified Full/Incoming Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-full-incoming-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -238,7 +238,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
|
||||
, where
|
||||
<span class="math">\(\mathsf{EncodeExtFVKParts}\)</span>
|
||||
is defined in <a id="id16" class="footnote_reference" href="#zip-0032-sapling-helper-functions">14</a>. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.</li>
|
||||
is defined in <a id="footnote-reference-16" class="footnote_reference" href="#zip-0032-sapling-helper-functions">14</a>. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.</li>
|
||||
<li>A Sapling IVK Encoding, also with Typecode
|
||||
<span class="math">\(\mathtt{0x02},\)</span>
|
||||
is an encoding of
|
||||
|
|
@ -249,19 +249,19 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be diversified in an unlinkable way). The Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
MUST NOT be included in a UFVK or UIVK by Producers, and MUST be treated as unrecognized by Consumers.</li>
|
||||
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <a id="id17" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="id18" class="footnote_reference" href="#bip-0044">30</a>, the FVK and IVK Encodings have Typecode
|
||||
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <a id="footnote-reference-17" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="footnote-reference-18" class="footnote_reference" href="#bip-0044">30</a>, the FVK and IVK Encodings have Typecode
|
||||
<span class="math">\(\mathtt{0x00}.\)</span>
|
||||
Both of these are encodings of the chain code and public key
|
||||
<span class="math">\((\mathsf{c}, \mathsf{pk})\)</span>
|
||||
given by
|
||||
<span class="math">\(\mathsf{c}\,||\,\mathsf{ser_P}(\mathsf{pk})\)</span>
|
||||
. (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 <a id="id19" class="footnote_reference" href="#bip-0032-serialization-format">28</a>.) However, the FVK uses the key at the Account level, i.e. at path
|
||||
. (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 <a id="footnote-reference-19" class="footnote_reference" href="#bip-0032-serialization-format">28</a>.) However, the FVK uses the key at the Account level, i.e. at path
|
||||
<span class="math">\(m / 44' / coin\_type' / account'\)</span>
|
||||
, while the IVK uses the external (non-change) child key at the Change level, i.e. at path
|
||||
<span class="math">\(m / 44' / coin\_type' / account' / 0\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>The Human-Readable Parts (as defined in <a id="id20" class="footnote_reference" href="#bip-0350">33</a>) of Unified Viewing Keys are defined as follows:</p>
|
||||
<p>The Human-Readable Parts (as defined in <a id="footnote-reference-20" class="footnote_reference" href="#bip-0350">33</a>) of Unified Viewing Keys are defined as follows:</p>
|
||||
<ul>
|
||||
<li>“<code>uivk</code>” for Unified Incoming Viewing Keys on Mainnet;</li>
|
||||
<li>“<code>uivktest</code>” for Unified Incoming Viewing Keys on Testnet;</li>
|
||||
|
|
@ -286,13 +286,13 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathtt{length}\)</span>
|
||||
fields are encoded as
|
||||
<span class="math">\(\mathtt{compactSize}.\)</span>
|
||||
<a id="id21" class="footnote_reference" href="#bitcoin-compactsize">36</a> (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.)</li>
|
||||
<a id="footnote-reference-21" class="footnote_reference" href="#bitcoin-compactsize">36</a> (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.)</li>
|
||||
<li>Within a single UA or UVK, all HD-derived Receivers, FVKs, and IVKs SHOULD represent an Address or Viewing Key for the same account (as used in the ZIP 32 or BIP 44 Account level).</li>
|
||||
<li>For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding.</li>
|
||||
<li>There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade <a id="id22" class="footnote_reference" href="#zip-0211">23</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade <a id="footnote-reference-22" class="footnote_reference" href="#zip-0211">23</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>Consumers MUST ignore constituent Items with Typecodes they do not recognize.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the same Typecode appears more than once, or that include both P2SH and P2PKH Transparent Addresses, or that contain only a Transparent Address.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification <a id="id23" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification <a id="footnote-reference-23" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the constituent Items are not ordered in ascending Typecode order. Note that this is different to priority order, and does not affect which Receiver in a Unified Address should be used by a Sender.</li>
|
||||
<li>There MUST NOT be additional bytes at the end of the raw encoding that cannot be interpreted as specified above.</li>
|
||||
<li>If the encoding of a Unified Address/Viewing Key is shown to a user in an abridged form due to lack of space, at least the first 20 characters MUST be included.</li>
|
||||
|
|
@ -305,7 +305,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</section>
|
||||
</section>
|
||||
<section id="adding-new-types"><h3><span class="section-heading">Adding new types</span><span class="section-anchor"> <a rel="bookmark" href="#adding-new-types"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id24" class="footnote_reference" href="#zip-0000">13</a>.</p>
|
||||
<p>It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="footnote-reference-24" class="footnote_reference" href="#zip-0000">13</a>.</p>
|
||||
<p>For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes
|
||||
<span class="math">\(\mathtt{0xFFFA}\)</span>
|
||||
to
|
||||
|
|
@ -320,7 +320,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathtt{0xFC}\)</span>
|
||||
inclusive are reserved to indicate Metadata Items other than Receivers or Viewing Keys. These items MAY affect the overall interpretation of the UA / UVK (for example, by specifying an expiration date).</p>
|
||||
<p>Since Metadata Items are not Receivers, they MUST NOT be selected by a Sender when choosing a Receiver to send to, and since they are not Viewing Keys, they MUST NOT provide additional authority to view information about transactions.</p>
|
||||
<p>Currently no Metadata Types are defined. New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id25" class="footnote_reference" href="#zip-0000">13</a>.</p>
|
||||
<p>Currently no Metadata Types are defined. New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="footnote-reference-25" class="footnote_reference" href="#zip-0000">13</a>.</p>
|
||||
</section>
|
||||
<section id="deriving-internal-keys"><h3><span class="section-heading">Deriving Internal Keys</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-internal-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>In addition to external addresses suitable for giving out to Senders, a wallet typically requires addresses for internal operations such as change and auto-shielding.</p>
|
||||
|
|
@ -344,7 +344,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathsf{CRH^{ivk}}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathsf{Commit^{ivk}}\)</span>
|
||||
(for Sapling and Orchard respectively). Derivation of an internal shielded FVK from an external shielded FVK is specified in the "Sapling internal key derivation" <a id="id26" class="footnote_reference" href="#zip-0032-sapling-internal-key-derivation">17</a> and "Orchard internal key derivation" <a id="id27" class="footnote_reference" href="#zip-0032-orchard-internal-key-derivation">19</a> sections of ZIP 32.</p>
|
||||
(for Sapling and Orchard respectively). Derivation of an internal shielded FVK from an external shielded FVK is specified in the "Sapling internal key derivation" <a id="footnote-reference-26" class="footnote_reference" href="#zip-0032-sapling-internal-key-derivation">17</a> and "Orchard internal key derivation" <a id="footnote-reference-27" class="footnote_reference" href="#zip-0032-orchard-internal-key-derivation">19</a> sections of ZIP 32.</p>
|
||||
<p>To satisfy the above properties for transparent (P2PKH) keys, we derive the external and internal
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
components from the transparent FVK
|
||||
|
|
@ -357,7 +357,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathsf{ser_P}(pk)\)</span>
|
||||
is
|
||||
<span class="math">\(33\)</span>
|
||||
bytes, as specified in <a id="id28" class="footnote_reference" href="#bip-0032-serialization-format">28</a>.</li>
|
||||
bytes, as specified in <a id="footnote-reference-28" class="footnote_reference" href="#bip-0032-serialization-format">28</a>.</li>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{ovk_{external}}\)</span>
|
||||
be the first
|
||||
|
|
@ -372,16 +372,16 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(I_\mathsf{ovk}\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 <a id="id29" class="footnote_reference" href="#bip-0044-path-change">31</a>. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.</p>
|
||||
<p>Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 <a id="footnote-reference-29" class="footnote_reference" href="#bip-0044-path-change">31</a>. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.</p>
|
||||
</section>
|
||||
<section id="deriving-a-uivk-from-a-ufvk"><h3><span class="section-heading">Deriving a UIVK from a UFVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-uivk-from-a-ufvk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The following derivations are applied to each component FVK:</p>
|
||||
<ul>
|
||||
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="id30" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in <a id="id31" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="footnote-reference-30" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in <a id="footnote-reference-31" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK is obtained by deriving the child key with non-hardened index
|
||||
<span class="math">\(0\)</span>
|
||||
as described in <a id="id32" class="footnote_reference" href="#bip-0032-public-to-public">29</a>.</li>
|
||||
as described in <a id="footnote-reference-32" class="footnote_reference" href="#bip-0032-public-to-public">29</a>.</li>
|
||||
</ul>
|
||||
<p>In each case, the Typecode remains the same as in the FVK.</p>
|
||||
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a UIVK from a UFVK.</p>
|
||||
|
|
@ -389,7 +389,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="deriving-a-unified-address-from-a-uivk"><h3><span class="section-heading">Deriving a Unified Address from a UIVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-unified-address-from-a-uivk"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,</p>
|
||||
<ul>
|
||||
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="id33" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">16</a>.</li>
|
||||
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="footnote-reference-33" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">16</a>.</li>
|
||||
<li>A Transparent diversifier index MUST be in the range
|
||||
<span class="math">\(0\)</span>
|
||||
to
|
||||
|
|
@ -399,9 +399,9 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</ul>
|
||||
<p>The following derivations are applied to each component IVK using the diversifier index:</p>
|
||||
<ul>
|
||||
<li>For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in <a id="id34" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in <a id="id35" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level <a id="id36" class="footnote_reference" href="#bip-0044-path-index">32</a> to derive the corresponding Transparent P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <a id="id37" class="footnote_reference" href="#bip-0032-public-to-public">29</a> MUST be used. The IVK is assumed to correspond to the extended public key for the external (non-change) element of the path. That is, if the UIVK was constructed correctly then the BIP 44 path of the Transparent P2PKH Receiver will be
|
||||
<li>For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in <a id="footnote-reference-34" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in <a id="footnote-reference-35" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level <a id="footnote-reference-36" class="footnote_reference" href="#bip-0044-path-index">32</a> to derive the corresponding Transparent P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <a id="footnote-reference-37" class="footnote_reference" href="#bip-0032-public-to-public">29</a> MUST be used. The IVK is assumed to correspond to the extended public key for the external (non-change) element of the path. That is, if the UIVK was constructed correctly then the BIP 44 path of the Transparent P2PKH Receiver will be
|
||||
<span class="math">\(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\)</span>
|
||||
</li>
|
||||
</ul>
|
||||
|
|
@ -409,8 +409,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a Receiver from a UIVK.</p>
|
||||
</section>
|
||||
<section id="usage-of-outgoing-viewing-keys"><h3><span class="section-heading">Usage of Outgoing Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#usage-of-outgoing-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When a Sender constructs a transaction that creates Sapling or Orchard notes, it uses an outgoing viewing key, as described in <a id="id38" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="id39" class="footnote_reference" href="#protocol-orchardsend">7</a>, to encrypt an outgoing ciphertext. Decryption with the outgoing viewing key allows recovering the sent note plaintext, including destination address, amount, and memo. The intention is that this outgoing viewing key should be associated with the source of the funds.</p>
|
||||
<p>However, the specification of which outgoing viewing key should be used is left somewhat open in <a id="id40" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="id41" class="footnote_reference" href="#protocol-orchardsend">7</a>; in particular, it was unclear whether transfers should be considered as being sent from an address, or from a ZIP 32 account <a id="id42" class="footnote_reference" href="#zip-0032-key-path-levels">20</a>. The adoption of multiple shielded protocols that support outgoing viewing keys (i.e. Sapling and Orchard) further complicates this question, since from NU5 activation, nothing at the consensus level prevents a wallet from spending both Sapling and Orchard notes in the same transaction. (Recommendations about wallet usage of multiple pools will be given in ZIP 315 <a id="id43" class="footnote_reference" href="#zip-0315">25</a>.)</p>
|
||||
<p>When a Sender constructs a transaction that creates Sapling or Orchard notes, it uses an outgoing viewing key, as described in <a id="footnote-reference-38" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="footnote-reference-39" class="footnote_reference" href="#protocol-orchardsend">7</a>, to encrypt an outgoing ciphertext. Decryption with the outgoing viewing key allows recovering the sent note plaintext, including destination address, amount, and memo. The intention is that this outgoing viewing key should be associated with the source of the funds.</p>
|
||||
<p>However, the specification of which outgoing viewing key should be used is left somewhat open in <a id="footnote-reference-40" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="footnote-reference-41" class="footnote_reference" href="#protocol-orchardsend">7</a>; in particular, it was unclear whether transfers should be considered as being sent from an address, or from a ZIP 32 account <a id="footnote-reference-42" class="footnote_reference" href="#zip-0032-key-path-levels">20</a>. The adoption of multiple shielded protocols that support outgoing viewing keys (i.e. Sapling and Orchard) further complicates this question, since from NU5 activation, nothing at the consensus level prevents a wallet from spending both Sapling and Orchard notes in the same transaction. (Recommendations about wallet usage of multiple pools will be given in ZIP 315 <a id="footnote-reference-43" class="footnote_reference" href="#zip-0315">25</a>.)</p>
|
||||
<p>Here we refine the protocol specification in order to allow more precise determination of viewing authority for UFVKs.</p>
|
||||
<p>A Sender will attempt to determine a "sending Account" for each transfer. The preferred approach is for the API used to perform a transfer to directly specify a sending Account. Otherwise, if the Sender can ascertain that all funds used in the transfer are from addresses associated with some Account, then it SHOULD treat that as the sending Account. If not, then the sending Account is undetermined.</p>
|
||||
<p>The Sender also determines a "preferred sending protocol" —one of "transparent", "Sapling", or "Orchard"— corresponding to the most preferred Receiver Type (as given in <a href="#encoding-of-unified-addresses">Encoding of Unified Addresses</a>) of any funds sent in the transaction.</p>
|
||||
|
|
@ -553,7 +553,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<span class="math">\(0 \text{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1].\)</span>
|
||||
</p>
|
||||
<figure class="align-center" align="center">
|
||||
<img width="372px" src="zip-0316-f4.png" />
|
||||
<img width="372" src="zip-0316-f4.png" alt="" />
|
||||
<figcaption>Diagram of 4-round unkeyed Feistel construction</figcaption>
|
||||
</figure>
|
||||
<p>(In practice the lengths
|
||||
|
|
@ -584,7 +584,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<section id="heuristic-analysis"><h4><span class="section-heading">Heuristic analysis</span><span class="section-anchor"> <a rel="bookmark" href="#heuristic-analysis"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>A 3-round unkeyed Feistel, as shown, is not sufficient:</p>
|
||||
<figure class="align-center" align="center">
|
||||
<img width="372px" src="zip-0316-f3.png" />
|
||||
<img width="372" src="zip-0316-f3.png" alt="" />
|
||||
<figcaption>Diagram of 3-round unkeyed Feistel construction</figcaption>
|
||||
</figure>
|
||||
<p>Suppose that an adversary has a target input/output pair
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/347">https://g
|
|||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/395">https://github.com/zcash/zips/pull/395</a>>
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-networks">10</a>.</p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol-networks">10</a>.</p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>payment</dt>
|
||||
|
|
@ -33,7 +33,7 @@ License: MIT</pre>
|
|||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>In order for a robust transactional ecosystem to evolve for Zcash, it is necessary for vendors to be able to issue requests for payment. At present, the best option available is to manually specify a payment address, a payment amount, and potentially memo field content. Of these three components, existing wallets only provide functionality for reading payment addresses in a semi-automated fashion. It is then necessary for the user to manually enter payment amounts and any associated memo information, which is tedious and may be error-prone, particularly if a payment is intended for multiple recipients or the memo field information contains structured data that must be faithfully reproduced.</p>
|
||||
<p>This ZIP seeks to eliminate these issues by proposing a standard format that wallet vendors may support so that human intervention is required only for approval, not creation, of such a transaction.</p>
|
||||
<p>In Bitcoin, two different standards exist to permit vendors to issue payment requests that are understood by wallets: BIP-0021 <a id="id3" class="footnote_reference" href="#bip-0021">5</a> and BIP-0070 <a id="id4" class="footnote_reference" href="#bip-0070">6</a>. BIP-0021 provides a URI format that can be interpreted by a wallet to construct simple, single-recipient transactions; BIP-0070 uses a protobuf-based protocol that permits requests for transactions of arbitrary complexity.</p>
|
||||
<p>In Bitcoin, two different standards exist to permit vendors to issue payment requests that are understood by wallets: BIP-0021 <a id="footnote-reference-3" class="footnote_reference" href="#bip-0021">5</a> and BIP-0070 <a id="footnote-reference-4" class="footnote_reference" href="#bip-0070">6</a>. BIP-0021 provides a URI format that can be interpreted by a wallet to construct simple, single-recipient transactions; BIP-0070 uses a protobuf-based protocol that permits requests for transactions of arbitrary complexity.</p>
|
||||
<p>The format proposed in this ZIP seeks a middle ground between these approaches: to provide a URI-based format which supports both the trivial use case and the slightly-more-complex situation where a transaction may include payments to multiple recipients.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -42,7 +42,7 @@ License: MIT</pre>
|
|||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="uri-syntax"><h3><span class="section-heading">URI Syntax</span><span class="section-anchor"> <a rel="bookmark" href="#uri-syntax"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The following syntax specification uses ABNF <a id="id5" class="footnote_reference" href="#rfc5234">2</a>.</p>
|
||||
<p>The following syntax specification uses ABNF <a id="footnote-reference-5" class="footnote_reference" href="#rfc5234">2</a>.</p>
|
||||
<pre data-language="EBNF"><span class="k">zcashurn </span><span class="o">=</span> <span class="s2">"zcash:"</span> <span class="p">(</span> <span class="k">zcashaddress </span><span class="p">[</span> <span class="s2">"?"</span> <span class="k">zcashparams </span><span class="p">]</span> <span class="err">/</span> <span class="s2">"?"</span> <span class="k">zcashparams </span><span class="p">)</span>
|
||||
<span class="k">zcashaddress </span><span class="err">=</span> <span class="err">1*</span><span class="p">(</span> <span class="k">ALPHA </span><span class="err">/</span> <span class="k">DIGIT </span><span class="p">)</span>
|
||||
<span class="k">zcashparams </span><span class="err">=</span> <span class="k">zcashparam </span><span class="p">[</span> <span class="s2">"&"</span> <span class="k">zcashparams </span><span class="p">]</span>
|
||||
|
|
@ -60,7 +60,7 @@ License: MIT</pre>
|
|||
<span class="k">otherparam </span><span class="err">=</span> <span class="k">paramname </span><span class="p">[</span> <span class="k">paramindex </span><span class="p">]</span> <span class="p">[</span> <span class="s2">"="</span> <span class="err">*</span><span class="k">qchar </span><span class="p">]</span>
|
||||
<span class="k">qchar </span><span class="err">=</span> <span class="k">unreserved </span><span class="err">/</span> <span class="k">pct-encoded </span><span class="err">/</span> <span class="k">allowed-delims </span><span class="err">/</span> <span class="s2">":"</span> <span class="err">/</span> <span class="s2">"@"</span>
|
||||
<span class="k">allowed-delims </span><span class="err">=</span> <span class="s2">"!"</span> <span class="err">/</span> <span class="s2">"$"</span> <span class="err">/</span> <span class="s2">"'"</span> <span class="err">/</span> <span class="s2">"("</span> <span class="err">/</span> <span class="s2">")"</span> <span class="err">/</span> <span class="s2">"*"</span> <span class="err">/</span> <span class="s2">"+"</span> <span class="err">/</span> <span class="s2">","</span> <span class="err">/</span> <span class="s2">";"</span></pre>
|
||||
<p>Here, <code>ALPHA</code>, <code>unreserved</code> and <code>pct-encoded</code> are as defined in <a id="id6" class="footnote_reference" href="#rfc3986">3</a>. "base64url" is defined as in <a id="id7" class="footnote_reference" href="#base64url">4</a> with padding omitted. (Note that this uses a different alphabet to the usual base64; the values 62 and 63 in the alphabet are encoded as <code>-</code> and <code>_</code> respectively. Implementations MUST NOT accept the characters <code>+</code>, <code>/</code>, and <code>=</code> that occur only in the usual base64.)</p>
|
||||
<p>Here, <code>ALPHA</code>, <code>unreserved</code> and <code>pct-encoded</code> are as defined in <a id="footnote-reference-6" class="footnote_reference" href="#rfc3986">3</a>. "base64url" is defined as in <a id="footnote-reference-7" class="footnote_reference" href="#base64url">4</a> with padding omitted. (Note that this uses a different alphabet to the usual base64; the values 62 and 63 in the alphabet are encoded as <code>-</code> and <code>_</code> respectively. Implementations MUST NOT accept the characters <code>+</code>, <code>/</code>, and <code>=</code> that occur only in the usual base64.)</p>
|
||||
<p>Productions of the form <code>1*x</code> indicate one or more successive instances of the production <code>x</code>. Productions of the form <code><n>*<m>x</code> indicate at least <cite><n></cite> and at most <cite><m></cite> instances of production <code>x</code>.</p>
|
||||
<p>Note that this grammar does not allow percent encoding outside the productions that use <code>qchar</code>, i.e. the values of label, message, <code>reqparam</code>, and <code>otherparam</code> parameters.</p>
|
||||
<p>Purported ZIP 321 URIs that cannot be parsed according to the above grammar MUST NOT be accepted.</p>
|
||||
|
|
@ -68,16 +68,16 @@ License: MIT</pre>
|
|||
<section id="uri-semantics"><h3><span class="section-heading">URI Semantics</span><span class="section-anchor"> <a rel="bookmark" href="#uri-semantics"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A ZIP-321 URI represents a request for the construction of a transaction having one or more <em>payments</em>. In the case that only a single payment is being requested, the recipient address SHOULD be included in the <code>hier-part</code> component of the RFC 3986 URI; otherwise, multiple recipient addresses can be specified using <code>addrparam</code> parameters with different indices.</p>
|
||||
<p>Addresses, amounts, labels, and messages sharing the same <code>paramindex</code> (including the empty <code>paramindex</code>) are interpreted to be associated with the same payment for the purposes of payment construction. A <code>paramindex</code> MUST NOT have leading zero(s). There is no significance to the ordering of parameters, and <code>paramindex</code> values need not be sequential.</p>
|
||||
<p>Due to restrictions on transaction construction described in <a id="id8" class="footnote_reference" href="#protocol-saplingbalance">11</a>, there may be no more than 2109 distinct payments requested by a single ZIP-321 URI.</p>
|
||||
<p>Due to restrictions on transaction construction described in <a id="footnote-reference-8" class="footnote_reference" href="#protocol-saplingbalance">11</a>, there may be no more than 2109 distinct payments requested by a single ZIP-321 URI.</p>
|
||||
<p>A URI of the form <code>zcash:<address>?...</code> MUST be considered equivalent to a URI of the form <code>zcash:?address=<address>&...</code> where <code><address></code> is an instance of <code>zcashaddress</code>.</p>
|
||||
<p>If there are any non-address parameters having a given <code>paramindex</code>, then the URI MUST contain an address parameter having that <code>paramindex</code>. There MUST NOT be more than one occurrence of a given parameter and <code>paramindex</code>.</p>
|
||||
<p>Implementations SHOULD check that each instance of <code>zcashaddress</code> is a valid string encoding of either:</p>
|
||||
<ul>
|
||||
<li>a Zcash transparent address, using Base58Check <a id="id9" class="footnote_reference" href="#base58check">7</a> as defined in <a id="id10" class="footnote_reference" href="#protocol-transparentaddrencoding">12</a>; or</li>
|
||||
<li>a Zcash Sapling address, using Bech32 <a id="id11" class="footnote_reference" href="#zip-0173">8</a> as defined in <a id="id12" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">13</a>.</li>
|
||||
<li>a Zcash transparent address, using Base58Check <a id="footnote-reference-9" class="footnote_reference" href="#base58check">7</a> as defined in <a id="footnote-reference-10" class="footnote_reference" href="#protocol-transparentaddrencoding">12</a>; or</li>
|
||||
<li>a Zcash Sapling address, using Bech32 <a id="footnote-reference-11" class="footnote_reference" href="#zip-0173">8</a> as defined in <a id="footnote-reference-12" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">13</a>.</li>
|
||||
</ul>
|
||||
<p>New address formats may be added in future. If the context of whether the payment URI is intended for Testnet or Mainnet is available, then each address SHOULD be checked to be for the correct network.</p>
|
||||
<p>Sprout addresses MUST NOT be supported in payment requests. The rationale for this is that transfers to Sprout addresses will, at activation of the Canopy network upgrade, be restricted by ZIP 211 <a id="id13" class="footnote_reference" href="#zip-0211">9</a>; it cannot generally be expected that senders will have funds available in the Sprout pool with which to satisfy requests for payment to a Sprout address.</p>
|
||||
<p>Sprout addresses MUST NOT be supported in payment requests. The rationale for this is that transfers to Sprout addresses will, at activation of the Canopy network upgrade, be restricted by ZIP 211 <a id="footnote-reference-13" class="footnote_reference" href="#zip-0211">9</a>; it cannot generally be expected that senders will have funds available in the Sprout pool with which to satisfy requests for payment to a Sprout address.</p>
|
||||
</section>
|
||||
<section id="transfer-amount"><h3><span class="section-heading">Transfer amount</span><span class="section-anchor"> <a rel="bookmark" href="#transfer-amount"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>If an amount is provided, it MUST be specified in decimal ZEC. If a decimal fraction is present then a period (<cite>.</cite>) MUST be used as the separating character to separate the whole number from the decimal fraction, and both the whole number and the decimal fraction MUST be nonempty. No other separators (such as commas for grouping or thousands) are permitted. Leading zeros in the whole number or trailing zeros in the decimal fraction are ignored. There MUST NOT be more than 8 digits in the decimal fraction.</p>
|
||||
|
|
@ -128,7 +128,7 @@ zcash:tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?%61mount=1
|
|||
zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
|
||||
<p>Invalid; percent encoding is only allowed in <code>qchar</code> productions, which do not include addresses, amounts, or parameter names.</p>
|
||||
<pre>zcash://tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
|
||||
<p>Invalid; the grammar does not allow <code>//</code>. ZIP 321 URIs are not "hierarchical URIs" in the sense defined in <a id="id14" class="footnote_reference" href="#rfc3986">3</a> section 1.2.3, and do not have an "authority component".</p>
|
||||
<p>Invalid; the grammar does not allow <code>//</code>. ZIP 321 URIs are not "hierarchical URIs" in the sense defined in <a id="footnote-reference-14" class="footnote_reference" href="#rfc3986">3</a> section 1.2.3, and do not have an "authority component".</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="forward-compatibility"><h3><span class="section-heading">Forward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#forward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Category: Wallet
|
|||
Created: 2020-05-26
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal defines the current format used in zcashd for wallet persistent storage, commonly known as <code>wallet.dat</code>.</p>
|
||||
|
|
@ -23,7 +23,7 @@ License: MIT</pre>
|
|||
<p>The process of saving wallet data into disk is currently unspecified. The key-values used in the current implementation are undocumented, and their structure and functionality are unknown without a deep analysis of the involved source code. This document details the schema and the mechanics of the wallet database. This is an informational document, no changes will be done to the source code.</p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Zcash stores wallet information in a Berkeley database (BDB) <a id="id2" class="footnote_reference" href="#bdb">2</a> commonly known as <code>wallet.dat</code>. The main purpose of this is the persistence of public and private keys the user created and the ability to recover the wallet state after a node restart. This file also allows the migration of user information from one node to another by moving the database to the corresponding new data directory, assuming both zcashd instances are running the same or similar version. A re-index may be necessary after this operation.</p>
|
||||
<p>Zcash stores wallet information in a Berkeley database (BDB) <a id="footnote-reference-2" class="footnote_reference" href="#bdb">2</a> commonly known as <code>wallet.dat</code>. The main purpose of this is the persistence of public and private keys the user created and the ability to recover the wallet state after a node restart. This file also allows the migration of user information from one node to another by moving the database to the corresponding new data directory, assuming both zcashd instances are running the same or similar version. A re-index may be necessary after this operation.</p>
|
||||
<p>The current database is a key-value store where keys and values can have multiple data types in binary format. The first data found in a database key is always the property name, the rest of the key is generally used to identify a record, for example:</p>
|
||||
<pre><------ KEY ----+- VALUE ->
|
||||
---------------------------
|
||||
|
|
@ -190,7 +190,7 @@ License: MIT</pre>
|
|||
</tr>
|
||||
<tr>
|
||||
<td>hdseed*</td>
|
||||
<td>Hierarchical Deterministic seed. <a id="id3" class="footnote_reference" href="#zip-0032">4</a></td>
|
||||
<td>Hierarchical Deterministic seed. <a id="footnote-reference-3" class="footnote_reference" href="#zip-0032">4</a></td>
|
||||
<td>
|
||||
<ol type="1">
|
||||
<li><code>uint256 seedFp</code></li>
|
||||
|
|
@ -463,8 +463,8 @@ License: MIT</pre>
|
|||
<p>The wallet database file may become corrupted. There are utilities in the <cite>zcutil/bin</cite> directory that may help with recovering it if this happens. Please ask for help on the Zcash forum or Community Discord.</p>
|
||||
</section>
|
||||
<section id="wallet-encryption"><h4><span class="section-heading">Wallet Encryption</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-encryption"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>Encryption will not be discussed in this document in detail as it is expected for the algorithm to change in the future according to the Wallet format ZIP issue: <a id="id4" class="footnote_reference" href="#zip400issue">3</a>.</p>
|
||||
<p>For a deeper understanding of the current encryption mechanism please refer to <a id="id5" class="footnote_reference" href="#cryptercode">5</a></p>
|
||||
<p>Encryption will not be discussed in this document in detail as it is expected for the algorithm to change in the future according to the Wallet format ZIP issue: <a id="footnote-reference-4" class="footnote_reference" href="#zip400issue">3</a>.</p>
|
||||
<p>For a deeper understanding of the current encryption mechanism please refer to <a id="footnote-reference-5" class="footnote_reference" href="#cryptercode">5</a></p>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -14,14 +14,14 @@ Category: Network
|
|||
Created: 2019-09-09
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal specifies a change to the behaviour of <code>zcashd</code> nodes intended to mitigate denial-of-service from transaction flooding.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Adoption of this proposal would increase robustness of Zcash nodes against denial-of-service attack, in particular attacks that attempt to exhaust node memory.</p>
|
||||
<p>Bitcoin Core added size limitation for the mempool in version 0.12 <a id="id2" class="footnote_reference" href="#bitcoincore-pr6722">6</a>, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.</p>
|
||||
<p>Bitcoin Core added size limitation for the mempool in version 0.12 <a id="footnote-reference-2" class="footnote_reference" href="#bitcoincore-pr6722">6</a>, defaulting to 300 MB. This was after Zcash forked from Bitcoin Core.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The memory usage of a node’s mempool should be bounded.</p>
|
||||
|
|
@ -29,7 +29,7 @@ License: MIT</pre>
|
|||
<p>Any configuration options should have reasonable defaults, i.e. without changing relevant configuration, a node should be adequately protected from denial-of-service via mempool memory exhaustion.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The current architecture of Zcash imposes fundamental limits on scaling of transaction throughput. This proposal does not increase the aggregate transaction capacity of the network. (The Blossom upgrade does increase transaction capacity, by a factor of two <a id="id3" class="footnote_reference" href="#zip-0208">2</a>.)</p>
|
||||
<p>The current architecture of Zcash imposes fundamental limits on scaling of transaction throughput. This proposal does not increase the aggregate transaction capacity of the network. (The Blossom upgrade does increase transaction capacity, by a factor of two <a id="footnote-reference-3" class="footnote_reference" href="#zip-0208">2</a>.)</p>
|
||||
<p>Denial-of-service issues in the messaging layer of the peer-to-peer protocol are out of scope for this proposal.</p>
|
||||
<p>This proposal is focused primarily on memory exhaustion attacks. It does not attempt to use fees to make denial-of-service economically prohibitive, since that is unlikely to be feasible while maintaining low fees for legitimate users. It does not preclude changes in fee policy.</p>
|
||||
</section>
|
||||
|
|
@ -39,8 +39,8 @@ License: MIT</pre>
|
|||
<blockquote>
|
||||
<p>max(serialized transaction size in bytes, 4000)</p>
|
||||
</blockquote>
|
||||
<p>Each transaction also has an <em>eviction weight</em>, which is <em>cost</em> + <em>low_fee_penalty</em>, where <em>low_fee_penalty</em> is 16000 if the transaction pays a fee less than the conventional fee, otherwise 0. The conventional fee is currently defined as 1000 zatoshis <a id="id4" class="footnote_reference" href="#zip-0313">5</a>.</p>
|
||||
<p>Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where the time indicates when the transaction with the given txid was evicted. The txid (rather than the wtxid as defined in <a id="id5" class="footnote_reference" href="#zip-0239">3</a>) is used even for version 5 transactions after activation of NU5 <a id="id6" class="footnote_reference" href="#zip-0252">4</a>.</p>
|
||||
<p>Each transaction also has an <em>eviction weight</em>, which is <em>cost</em> + <em>low_fee_penalty</em>, where <em>low_fee_penalty</em> is 16000 if the transaction pays a fee less than the conventional fee, otherwise 0. The conventional fee is currently defined as 1000 zatoshis <a id="footnote-reference-4" class="footnote_reference" href="#zip-0313">5</a>.</p>
|
||||
<p>Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where the time indicates when the transaction with the given txid was evicted. The txid (rather than the wtxid as defined in <a id="footnote-reference-5" class="footnote_reference" href="#zip-0239">3</a>) is used even for version 5 transactions after activation of NU5 <a id="footnote-reference-6" class="footnote_reference" href="#zip-0252">4</a>.</p>
|
||||
<p>The RecentlyEvicted queue SHOULD be empty on node startup. The size of RecentlyEvicted SHOULD never exceed <code>eviction_memory_entries</code> entries, which is the constant 40000.</p>
|
||||
<p>There MUST be a configuration option <code>mempooltxcostlimit</code>, which SHOULD default to 80000000.</p>
|
||||
<p>There MUST be a configuration option <code>mempoolevictionmemoryminutes</code>, which SHOULD default to 60.</p>
|
||||
|
|
@ -60,9 +60,9 @@ License: MIT</pre>
|
|||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The accounting for transaction size should include some overhead per transaction, to reflect the cost to the network of processing them (proof and signature verification; networking overheads; size of in-memory data structures). The implication of not including overhead is that a denial-of-service attacker would be likely to use minimum-size transactions so that more of them would fit in a block, increasing the unaccounted-for overhead. A possible counterargument would be that the complexity of accounting for this overhead is unwarranted given that the format of a transaction already imposes a minimum size. However, the proposed cost function is almost as simple as using transaction size directly.</p>
|
||||
<p>The threshold 4000 for the cost function is chosen so that the size in bytes of a typical fully shielded Sapling transaction (with, say, 2 shielded outputs and up to 5 shielded inputs) will fall below the threshold. This has the effect of ensuring that such transactions are not evicted preferentially to typical transparent transactions because of their size.</p>
|
||||
<p>The proposed eviction policy differs significantly from that of Bitcoin Core <a id="id7" class="footnote_reference" href="#bitcoincore-pr6722">6</a>, which is primarily fee-based. This reflects differing philosophies about the motivation for fees and the level of fee that legitimate users can reasonably be expected to pay. The proposed eviction weight function does involve a penalty for transactions with a fee lower than the standard (0.0001 ZEC) value, but since there is no further benefit to increasing the fee above the standard value, it creates no pressure toward escalating fees. For transactions up to 4000 bytes, this penalty makes a transaction that pays less than the standard fee value five times as likely to be chosen for eviction (because 4000 + 16000 = 20000 = 4000 * 5).</p>
|
||||
<p>The proposed eviction policy differs significantly from that of Bitcoin Core <a id="footnote-reference-7" class="footnote_reference" href="#bitcoincore-pr6722">6</a>, which is primarily fee-based. This reflects differing philosophies about the motivation for fees and the level of fee that legitimate users can reasonably be expected to pay. The proposed eviction weight function does involve a penalty for transactions with a fee lower than the standard (0.0001 ZEC) value, but since there is no further benefit to increasing the fee above the standard value, it creates no pressure toward escalating fees. For transactions up to 4000 bytes, this penalty makes a transaction that pays less than the standard fee value five times as likely to be chosen for eviction (because 4000 + 16000 = 20000 = 4000 * 5).</p>
|
||||
<p>The fee penalty is not included in the cost that determines whether the mempool is considered full. This ensures that a DoS attacker does not have an incentive to pay less than the standard fee in order to cause the mempool to be considered full sooner.</p>
|
||||
<p>The default value of 80000000 for <code>mempooltxcostlimit</code> represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade <a id="id8" class="footnote_reference" href="#zip-0208">2</a>. It would serve no purpose to make it larger.</p>
|
||||
<p>The default value of 80000000 for <code>mempooltxcostlimit</code> represents no more than 40 blocks’ worth of transactions in the worst case, which is the default expiration height after the Blossom network upgrade <a id="footnote-reference-8" class="footnote_reference" href="#zip-0208">2</a>. It would serve no purpose to make it larger.</p>
|
||||
<p>The <code>mempooltxcostlimit</code> is a per-node configurable parameter in order to provide flexibility for node operators to change it either in response to attempted denial-of-service attacks, or if needed to handle spikes in transaction demand. It may also be useful for nodes running in memory-constrained environments to reduce this parameter.</p>
|
||||
<p>The limit of <code>eviction_memory_entries</code> = 40000 entries in RecentlyEvicted bounds the memory needed for this data structure. Since a txid is 32 bytes and a timestamp 8 bytes, 40000 entries can be stored in ~1.6 MB, which is small compared to other node memory usage (in particular, small compared to the maximum memory usage of the mempool itself under the default <code>mempooltxcostlimit</code>). <code>eviction_memory_entries</code> entries should be sufficient to mitigate any performance loss caused by re-accepting transactions that were previously evicted. In particular, since a transaction has a minimum cost of 4000, and the default <code>mempooltxcostlimit</code> is 80000000, at most 20000 transactions can be in the mempool of a node using the default parameters. While the number of transactions “in flight” or across the mempools of all nodes in the network could exceed this number, we believe that is unlikely to be a problem in practice.</p>
|
||||
<p>Note that the RecentlyEvicted queue is intended as a performance optimization under certain conditions, rather than as a DoS-mitigation measure in itself.</p>
|
||||
|
|
|
|||
|
|
@ -15,15 +15,15 @@ Created: 2019-08-01
|
|||
License: CC BY-SA 4.0 <<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>>
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843">https://forum.zcashcommunity.com/t/zip-proposal-keep-the-block-distribution-as-initaly-defined-90-to-miners/33843</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>For clarity this ZIP defines these terms:</p>
|
||||
<ul>
|
||||
<li>Mining software in the context of this ZIP refers to pool software, local mining software, or staking software.</li>
|
||||
<li>Mining is defined as the action of processing transactions, so this would include proof of stake, if Zcash would switch to that.</li>
|
||||
<li>Mining coins transferred via fees are considered rewards (infinite), coins generated via block generation are considered distribution (finite).</li>
|
||||
<li>Block distribution is defined as the block reward minus transaction fees. <span class="editor-note">the protocol specification uses "block subsidy".</span></li>
|
||||
<li>Spirit is defined as what is the intended outcome of the ZIP. <a id="id2" class="footnote_reference" href="#spirit">1</a></li>
|
||||
<li>Initial promise is non-neutral language referencing the block distribution rules as initially set out. <a id="id3" class="footnote_reference" href="#funding">3</a></li>
|
||||
<li>Spirit is defined as what is the intended outcome of the ZIP. <a id="footnote-reference-2" class="footnote_reference" href="#spirit">1</a></li>
|
||||
<li>Initial promise is non-neutral language referencing the block distribution rules as initially set out. <a id="footnote-reference-3" class="footnote_reference" href="#funding">3</a></li>
|
||||
</ul>
|
||||
<table id="spirit" class="footnote">
|
||||
<tbody>
|
||||
|
|
@ -60,8 +60,8 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-proposal-kee
|
|||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>The existing Founders’ Reward consensus rules <a id="id4" class="footnote_reference" href="#spec-subsidies">4</a> <a id="id5" class="footnote_reference" href="#spec-foundersreward">5</a> MUST be preserved.</li>
|
||||
<li>Specifically, <code>FoundersReward(height)</code> MUST equal <code>0</code> if <code>Halving(height) >= 1</code>. (For clarity once the halving happens the Founders’ Reward stops, as per the rules outlined in <a id="id6" class="footnote_reference" href="#spec-subsidies">4</a> and <a id="id7" class="footnote_reference" href="#spec-foundersreward">5</a>.)</li>
|
||||
<li>The existing Founders’ Reward consensus rules <a id="footnote-reference-4" class="footnote_reference" href="#spec-subsidies">4</a> <a id="footnote-reference-5" class="footnote_reference" href="#spec-foundersreward">5</a> MUST be preserved.</li>
|
||||
<li>Specifically, <code>FoundersReward(height)</code> MUST equal <code>0</code> if <code>Halving(height) >= 1</code>. (For clarity once the halving happens the Founders’ Reward stops, as per the rules outlined in <a id="footnote-reference-6" class="footnote_reference" href="#spec-subsidies">4</a> and <a id="footnote-reference-7" class="footnote_reference" href="#spec-foundersreward">5</a>.)</li>
|
||||
<li>This specification is only meant to stop the Founders’ Reward, not protocol-based donations.</li>
|
||||
<li>Enforcing some kind of mandatory donation via whatever mechanism would be seen as continuation of the Founders’ Reward.</li>
|
||||
</ul>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Created: 2019-07-17
|
|||
License: CC BY-SA 4.0 <<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>>
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846">https://forum.zcashcommunity.com/t/zip-proposal-a-genuine-opt-in-protocol-level-development-donation-option/33846</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">3</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">3</a></p>
|
||||
<p>This ZIP defines these terms:</p>
|
||||
<ul>
|
||||
<li>Signalling is defined as expressing a voice through whatever mechanism is implemented or sought for that decision. In the context of this ZIP it primarily refers to signalling what to do with funds. This could be done by miners, straw poll, coinbase, proof of value, some internet poll thing, etc.</li>
|
||||
|
|
@ -31,7 +31,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
|
|||
<li>Fee is the standard transaction fee that a sender puts on a transaction to get it included into a block and that is collected by the miner of that block.</li>
|
||||
<li>Transaction donation is an optional signalling string that creates a payment to the coins base donations.</li>
|
||||
<li>Block Reward is defined as block distribution plus mining fees.</li>
|
||||
<li>Spirit is defined as what is the intended outcome of the ZIP. <a id="id2" class="footnote_reference" href="#spirit">1</a></li>
|
||||
<li>Spirit is defined as what is the intended outcome of the ZIP. <a id="footnote-reference-2" class="footnote_reference" href="#spirit">1</a></li>
|
||||
</ul>
|
||||
<table id="spirit" class="footnote">
|
||||
<tbody>
|
||||
|
|
@ -60,7 +60,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
|
|||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>An additional opt-in mechanism, baked into the protocol. This is a condition of the Zcash Foundation too. <a id="id3" class="footnote_reference" href="#foundation">2</a></li>
|
||||
<li>An additional opt-in mechanism, baked into the protocol. This is a condition of the Zcash Foundation too. <a id="footnote-reference-3" class="footnote_reference" href="#foundation">2</a></li>
|
||||
<li>Give an alterative to redistribution of either the current block distribution structure or the emission curve.</li>
|
||||
<li>The funding received by the Electric Coin Company and/or Zcash Foundation under this proposal MUST only be used to fund ZEC development for the lifetime of their receipt of it.</li>
|
||||
<li>To give a strong indication to the community and users that they have freedom to decide what they do with their coins and donations.</li>
|
||||
|
|
@ -73,7 +73,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-proposal-a-g
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td>The Zcash Foundation has stated (later clarified in <a id="id4" class="footnote_reference" href="#zfnd-guidance">4</a>) that the Foundation would only support proposals that: a) don’t rely on the Foundation being a single gatekeeper of funds; b) don’t change the upper bound of ZEC supply; and c) have some kind of opt-in mechanism for choosing to disburse funds (from miners and/or users).</td>
|
||||
<td>The Zcash Foundation has stated (later clarified in <a id="footnote-reference-4" class="footnote_reference" href="#zfnd-guidance">4</a>) that the Foundation would only support proposals that: a) don’t rely on the Foundation being a single gatekeeper of funds; b) don’t change the upper bound of ZEC supply; and c) have some kind of opt-in mechanism for choosing to disburse funds (from miners and/or users).</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Created: 2019-06-19
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862">https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>For clarity in this ZIP I define these terms:</p>
|
||||
<dl>
|
||||
<dt>2nd Halvening period</dt>
|
||||
|
|
@ -63,11 +63,11 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
|
|||
<li>Quarterly technology roadmap reports and updates.</li>
|
||||
<li>Quarterly financial reports, detailing spending levels/burn rate and cash/ZEC on hand.</li>
|
||||
<li>A yearly, audited financial report akin to the Form 990 for US-based nonprofits.</li>
|
||||
<li>Yearly reviews of organization performance, along the lines of the State of the Zcash Foundation report <a id="id2" class="footnote_reference" href="#zfnd-state">2</a>.</li>
|
||||
<li>Yearly reviews of organization performance, along the lines of the State of the Zcash Foundation report <a id="footnote-reference-2" class="footnote_reference" href="#zfnd-state">2</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="requirements-specifically-for-the-ecc"><h3><span class="section-heading">Requirements Specifically for the ECC</span><span class="section-anchor"> <a rel="bookmark" href="#requirements-specifically-for-the-ecc"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Motivated by the Zcash Foundation’s proposal that the ECC become a non-profit <a id="id3" class="footnote_reference" href="#zfnd-guidance">3</a>, I am going to list general requirements for the ECC to abide by if they choose to receive funds and work on behalf of ZEC holders.</p>
|
||||
<p>Motivated by the Zcash Foundation’s proposal that the ECC become a non-profit <a id="footnote-reference-3" class="footnote_reference" href="#zfnd-guidance">3</a>, I am going to list general requirements for the ECC to abide by if they choose to receive funds and work on behalf of ZEC holders.</p>
|
||||
<ol type="1">
|
||||
<li>Because I share the Foundation’s concern that the ECC could be “beholden to its shareholders”, I am mandating that the ECC should be working in the service of the Zcash community and <strong>shall serve no other masters</strong>. The original investors/founders who are not still working in the service of the Zcash community SHOULD NOT have control over the use of the new development funds.</li>
|
||||
<li>The revenue received from the Dev Fund SHOULD NOT be used to give further rewards to, even indirectly, the investors, founders, or shareholders of the ECC, who are not working on Zcash after the first halving. <strong>They have already received the Founders’ Reward and this new development fund is not supposed to further benefit them.</strong></li>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Created: 2019-06-19
|
|||
License: public domain
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864">https://forum.zcashcommunity.com/t/dev-fund-proposal-miner-directed-dev-fund-was-20-to-any-combination-of-ecc-zfnd-parity-or-burn/33864</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>For clarity, this ZIP defines these terms:</p>
|
||||
<dl>
|
||||
<dt>2nd Halvening Period</dt>
|
||||
|
|
@ -37,8 +37,8 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
|
|||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Like most development fund proposals, this is motivated by the potential value to the Zcash community of using newly minted coins to hire developers to continue improving Zcash. <a id="id2" class="footnote_reference" href="#amiller-notes">2</a></p>
|
||||
<p>Unlike most other development fund proposals, this proposal is distinct in providing a fine-grained “opt-in” <a id="id3" class="footnote_reference" href="#acityinohio-comment">3</a> feature, since miners have the choice to provide a small amount of development funding or none at all.</p>
|
||||
<p>Like most development fund proposals, this is motivated by the potential value to the Zcash community of using newly minted coins to hire developers to continue improving Zcash. <a id="footnote-reference-2" class="footnote_reference" href="#amiller-notes">2</a></p>
|
||||
<p>Unlike most other development fund proposals, this proposal is distinct in providing a fine-grained “opt-in” <a id="footnote-reference-3" class="footnote_reference" href="#acityinohio-comment">3</a> feature, since miners have the choice to provide a small amount of development funding or none at all.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
|
|
@ -53,7 +53,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
|
|||
<p>Implementations MAY define a default opt-in allocation (e.g., DF%/2 to the Electric Coin Company and DF%/2 to the Zcash Foundation).</p>
|
||||
<p>Implementations SHOULD support changing the allocation (overriding any such default) through a configuration option.</p>
|
||||
<section id="examples"><h3><span class="section-heading">Examples</span><span class="section-anchor"> <a rel="bookmark" href="#examples"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The following examples illustrate how miners can build the outputs of the coinbase transactions to allocate the MDDF to eligible developers. Assume <code>Dev1</code>, <code>Dev2</code> are the hardcoded addresses of eligible developers, and <code>Miner</code> is the address of the mining pool mining this block. Assume that the total newly minted coins are 3.125 ZEC per block during the 2nd Halvening Period (this takes into account the change to a 75-second block target spacing after the Blossom Network Upgrade <a id="id4" class="footnote_reference" href="#zip-0208">5</a>), and that DF% = 20%, MR% = 80%.</p>
|
||||
<p>The following examples illustrate how miners can build the outputs of the coinbase transactions to allocate the MDDF to eligible developers. Assume <code>Dev1</code>, <code>Dev2</code> are the hardcoded addresses of eligible developers, and <code>Miner</code> is the address of the mining pool mining this block. Assume that the total newly minted coins are 3.125 ZEC per block during the 2nd Halvening Period (this takes into account the change to a 75-second block target spacing after the Blossom Network Upgrade <a id="footnote-reference-4" class="footnote_reference" href="#zip-0208">5</a>), and that DF% = 20%, MR% = 80%.</p>
|
||||
<p><strong>Example 1: Split equally between two developers</strong></p>
|
||||
<p>The transaction outputs of the coinbase transaction are as follows:</p>
|
||||
<ul>
|
||||
|
|
@ -79,7 +79,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-proposa
|
|||
</ul>
|
||||
</li>
|
||||
<li>This proposal modifies the terms of what some may consider a social contract: given the original code in Zcash implementations, by the end of the issuance schedule when all 21 million ZEC have been minted, a total of 90% of all minted coins would have originally been awarded to miners. Under this proposal, less reward would be available to miners, than would be available to them according to the original minting schedule.</li>
|
||||
<li>Several others, notably the Blocktown Capital proposal <a id="id5" class="footnote_reference" href="#blocktown-summary">4</a>, have suggested that a 20% development fund would set a precedent for a perpetual 20% development fund. This proposal is explicitly limited in scope to the 2nd Halvening Period. Thus adopting this proposal on its own, if there are no further updates, would result in the the development fund ending in 2024.</li>
|
||||
<li>Several others, notably the Blocktown Capital proposal <a id="footnote-reference-5" class="footnote_reference" href="#blocktown-summary">4</a>, have suggested that a 20% development fund would set a precedent for a perpetual 20% development fund. This proposal is explicitly limited in scope to the 2nd Halvening Period. Thus adopting this proposal on its own, if there are no further updates, would result in the the development fund ending in 2024.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Created: 2019-08-31
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782">https://forum.zcashcommunity.com/t/blocktown-development-fund-proposal-10-to-a-2-of-3-multisig-with-community-involved-third-entity/34782</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The additional terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Mining</dt>
|
||||
|
|
@ -28,7 +28,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/blocktown-develo
|
|||
<dt>Mining rewards / Block rewards</dt>
|
||||
<dd>Network transaction fees and/or coinbase rewards (e.g. newly issued ZEC associated with block generation).</dd>
|
||||
<dt>Network Upgrade</dt>
|
||||
<dd>Any consensus rule change to the Zcash protocol, introduced as part of the standard Zcash Network Upgrade Pipeline <a id="id2" class="footnote_reference" href="#nu-pipeline">9</a> or otherwise.</dd>
|
||||
<dd>Any consensus rule change to the Zcash protocol, introduced as part of the standard Zcash Network Upgrade Pipeline <a id="footnote-reference-2" class="footnote_reference" href="#nu-pipeline">9</a> or otherwise.</dd>
|
||||
<dt>Founder’s Reward</dt>
|
||||
<dd>The 20% ZEC from mined blocks allocated to the Electric Coin Company (ECC), Zcash Foundation (ZF), employees, investors and/or other entities prior to the expected first halving in October 2020.</dd>
|
||||
<dt>Zcash Development Fund</dt>
|
||||
|
|
@ -56,13 +56,13 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/blocktown-develo
|
|||
<ul>
|
||||
<li>Funds allocated to the Zcash Development Fund MUST be used only for their intended purpose as defined in the following Rationale section of this proposal.</li>
|
||||
<li>The transparent address(es) of the Zcash Development Fund MUST be jointly controlled by the ECC, ZF, and Third Entity, and all funds transferred from the Zcash Development Fund MUST be publicly confirmed in an official manner by a majority decision among the ECC, ZF, and Third Entity–commonly referred to as “2-of-3 multisig”. That is, funding decisions MUST be put to an officially documented vote which MUST NOT pass unless at least 2 of the 3 entities above vote approvingly.</li>
|
||||
<li>Prior to any movement of funds from the Zcash Development Fund, the ZF and ECC MUST coordinate with each other and the community to establish the Third Entity that will be involved in governance of the Zcash Development Fund. The process of determining the exact initial composition and rules of governance of the Third Entity MUST involve the Zcash community at large in a process similar to that outlined in the section "How the Foundation will select a particular proposal" in the ZF’s August 6, 2019 statement <a id="id3" class="footnote_reference" href="#zfnd-guidance">2</a>.</li>
|
||||
<li>Prior to any movement of funds from the Zcash Development Fund, the ZF and ECC MUST coordinate with each other and the community to establish the Third Entity that will be involved in governance of the Zcash Development Fund. The process of determining the exact initial composition and rules of governance of the Third Entity MUST involve the Zcash community at large in a process similar to that outlined in the section "How the Foundation will select a particular proposal" in the ZF’s August 6, 2019 statement <a id="footnote-reference-3" class="footnote_reference" href="#zfnd-guidance">2</a>.</li>
|
||||
</ul>
|
||||
<p>The governance rules of the Third Entity MUST include the following:</p>
|
||||
<ul>
|
||||
<li>All decision-making and other governing processes of the Third Entity MUST be independent of the ECC and ZF, and MUST include measures that are necessary to avoid conflicts of interest in relation to the ECC and ZF.</li>
|
||||
<li>At creation, the Third Entity MUST include an uneven number of at least 5 individuals with independent previous affiliations, each having a single vote. All such decisions MUST have majority support within the Third Entity to result in an overall approving vote by the Third Entity.</li>
|
||||
<li>Once the Third Entity is established, it MAY decide to change its rules of governance (e.g. simple majority versus supermajority rules), but any such change MUST be preceded by the involvement of the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement <a id="id4" class="footnote_reference" href="#zfnd-guidance">2</a>.</li>
|
||||
<li>Once the Third Entity is established, it MAY decide to change its rules of governance (e.g. simple majority versus supermajority rules), but any such change MUST be preceded by the involvement of the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement <a id="footnote-reference-4" class="footnote_reference" href="#zfnd-guidance">2</a>.</li>
|
||||
<li>Once the Third Entity is established as a self-governing body, it SHOULD evolve toward a system whereby ZEC holders have a direct role in determining votes and internal governance of the Third Entity.</li>
|
||||
<li>The Third Entity MAY apply for funding from the Zcash Development Fund, if deemed appropriate by its governing body. This would be subject to a majority vote by the ECC, ZF and Third Entity.</li>
|
||||
</ul>
|
||||
|
|
@ -79,23 +79,23 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/blocktown-develo
|
|||
<li>Recipients MUST publicize at minimum quarterly progress updates on their activities funded from the Zcash Development Fund. In the case of short-term assignments (less than 6 months), a single report upon completion of the project is sufficient. Standard reporting requirements MUST be specified by the ECC, ZF, and Third Entity prior to any approved requests from the Zcash Development Fund and additional requirements MAY be introduced as needed.</li>
|
||||
<li>Depending on the nature of each request, funds MAY be disbursed in a single payment or incrementally, subject to objective milestones and/or other performance metrics.</li>
|
||||
</ul>
|
||||
<p>Any decision to alter the governance of the Zcash Development Fund as described in this proposal and in final detail by the ECC, ZF, and Third Entity MUST involve the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement <a id="id5" class="footnote_reference" href="#zfnd-guidance">2</a>. All transfers from the Zcash Development Fund MUST be in full accordance with the requirements described in this proposal.</p>
|
||||
<p>Any decision to alter the governance of the Zcash Development Fund as described in this proposal and in final detail by the ECC, ZF, and Third Entity MUST involve the Zcash community at large, similar to the process outlined in the ZF’s August 6, 2019 statement <a id="footnote-reference-5" class="footnote_reference" href="#zfnd-guidance">2</a>. All transfers from the Zcash Development Fund MUST be in full accordance with the requirements described in this proposal.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="issues-not-addressed-in-this-proposal-out-of-scope"><h2><span class="section-heading">Issues not addressed in this proposal/Out-of-Scope</span><span class="section-anchor"> <a rel="bookmark" href="#issues-not-addressed-in-this-proposal-out-of-scope"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul>
|
||||
<li>Details of the decision-making process for supporting or rejecting this or other relevant proposals by the ECC, ZF, and/or other Zcash stakeholders. We do maintain, however, that any decision by the ECC and/or the ZF on the issue described in the Motivation section below SHOULD be preceded by the procedures for measuring community sentiment as outlined in the ZF’s August 6, 2019 statement <a id="id6" class="footnote_reference" href="#zfnd-guidance">2</a>.</li>
|
||||
<li>Details of the decision-making process for supporting or rejecting this or other relevant proposals by the ECC, ZF, and/or other Zcash stakeholders. We do maintain, however, that any decision by the ECC and/or the ZF on the issue described in the Motivation section below SHOULD be preceded by the procedures for measuring community sentiment as outlined in the ZF’s August 6, 2019 statement <a id="footnote-reference-6" class="footnote_reference" href="#zfnd-guidance">2</a>.</li>
|
||||
<li>Additional methods for measuring community sentiment MAY include a way for ZEC holders to signal their support of specific proposals.</li>
|
||||
<li>The matter of whether the ECC should reorganize itself into a non-profit or remain for-profit, as addressed by the ZF in their August 6, 2019 statement <a id="id7" class="footnote_reference" href="#zfnd-guidance">2</a>. The current proposal is neutral on this matter, and funding from the Development Fund would be available for non-profit and/or for-profit entities. We consider the governance rules of the Development Fund outlined in this Specification section adequate for transparency and accountability.</li>
|
||||
<li>The matter of whether the ECC should reorganize itself into a non-profit or remain for-profit, as addressed by the ZF in their August 6, 2019 statement <a id="footnote-reference-7" class="footnote_reference" href="#zfnd-guidance">2</a>. The current proposal is neutral on this matter, and funding from the Development Fund would be available for non-profit and/or for-profit entities. We consider the governance rules of the Development Fund outlined in this Specification section adequate for transparency and accountability.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The Zcash network is scheduled to undergo its first halving in October 2020, per current protocol specifications. At the time of the first halving, the codebase dictates that the Founder’s Reward, which consists of 20% of the ZEC from every block reward, will be terminated. Without codebase modification, for example in the upcoming NU4 Network Upgrade, 100% of block rewards would be claimed by miners after the first halving.</p>
|
||||
<p>The two organizations presently leading development and maintenance of the Zcash network receive funds from the Founder’s Reward. These organizations, the ECC and ZF, have recently requested a source of funding after the first halving in order to continue operations for the foreseeable future. The source of funds could theoretically be from either a modification to the codebase dictating a Zcash Development Fund from block rewards or, alternatively, from external sources. The ECC has indicated though that it would “wind down or pivot” rather than accept funding from any sources that would give “special interests” control over the ECC <a id="id8" class="footnote_reference" href="#ecc-assessment">3</a>.</p>
|
||||
<p>The two organizations presently leading development and maintenance of the Zcash network receive funds from the Founder’s Reward. These organizations, the ECC and ZF, have recently requested a source of funding after the first halving in order to continue operations for the foreseeable future. The source of funds could theoretically be from either a modification to the codebase dictating a Zcash Development Fund from block rewards or, alternatively, from external sources. The ECC has indicated though that it would “wind down or pivot” rather than accept funding from any sources that would give “special interests” control over the ECC <a id="footnote-reference-8" class="footnote_reference" href="#ecc-assessment">3</a>.</p>
|
||||
<p>Based on the ECC’s demands, the block reward appears to be the most agreeable source of resources for a Zcash Development Fund.</p>
|
||||
<p>This proposal, originally published in the Zcash Community Forum on August 14, 2019 <a id="id9" class="footnote_reference" href="#blocktown-proposal">4</a> and formalized further in a blog post on August 23, 2019 <a id="id10" class="footnote_reference" href="#blocktown-blog">5</a>, outlines the funding mechanism and governance of such a Zcash Development Fund. Herein, we propose a feature of NU4 whereby 10% of the ZEC from every new block reward between the first halving and second halving would be directly deposited in a Zcash Development Fund.</p>
|
||||
<p>This proposal, originally published in the Zcash Community Forum on August 14, 2019 <a id="footnote-reference-9" class="footnote_reference" href="#blocktown-proposal">4</a> and formalized further in a blog post on August 23, 2019 <a id="footnote-reference-10" class="footnote_reference" href="#blocktown-blog">5</a>, outlines the funding mechanism and governance of such a Zcash Development Fund. Herein, we propose a feature of NU4 whereby 10% of the ZEC from every new block reward between the first halving and second halving would be directly deposited in a Zcash Development Fund.</p>
|
||||
<p>For the period between the launch of the Zcash network in 2016 and the first halving, there has been a centralized 20% fee known as the Founder’s Reward taken from the block reward. Other active ZIP drafts advocate a Zcash Development Fund of 20% allocation from the block reward after the first halving. We believe that a cumulative eight years of centralized fees from the block reward at the identical rate of 20% would ultimately result in a narrow community that accepts the likelihood of a perpetual 20% fee on the Zcash network.</p>
|
||||
<p>With a Zcash Development Fund that is only 10% of the block reward, a precedent will be set that a large centralized fund is not indefinite and will decrease faster than simply the rate of block reward halvings. Although this proposal specifically addresses the period between the first and second halving, this proposed feature may set a precedent whereby the percent fee from block rewards allocated to a Zcash Development Fund continually decreases every halving, e.g. 20% (FR) from 2016-2020, 10% from 2020-2024, 5% from 2024-2028, 2.5% from 2028-2032 (effectively quartering the ZEC allocated to a development fund every four years). We believe that this social contract could restore the community’s faith in the decentralization of Zcash as the network incentives align more closely with that of Bitcoin’s over time. Alternatively, it is not unreasonable for the Zcash governance system to elect a 0% allocation for the Zcash Development Fund upon the second halving. For a more detailed exploration regarding the selection of 10%, please review the blog post ‘Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade’ <a id="id11" class="footnote_reference" href="#blocktown-10pc">6</a>.</p>
|
||||
<p>With a Zcash Development Fund that is only 10% of the block reward, a precedent will be set that a large centralized fund is not indefinite and will decrease faster than simply the rate of block reward halvings. Although this proposal specifically addresses the period between the first and second halving, this proposed feature may set a precedent whereby the percent fee from block rewards allocated to a Zcash Development Fund continually decreases every halving, e.g. 20% (FR) from 2016-2020, 10% from 2020-2024, 5% from 2024-2028, 2.5% from 2028-2032 (effectively quartering the ZEC allocated to a development fund every four years). We believe that this social contract could restore the community’s faith in the decentralization of Zcash as the network incentives align more closely with that of Bitcoin’s over time. Alternatively, it is not unreasonable for the Zcash governance system to elect a 0% allocation for the Zcash Development Fund upon the second halving. For a more detailed exploration regarding the selection of 10%, please review the blog post ‘Proposal for 10% Dev Fund in Zcash 2020 Network Upgrade’ <a id="footnote-reference-11" class="footnote_reference" href="#blocktown-10pc">6</a>.</p>
|
||||
<p>Of note, we are not suggesting or implying that the funding from the Founder’s Reward and a Zcash Development Fund would be managed in a similar way or have similar directives. The Zcash Development Fund feature that we propose for NU4 does not allocate any funds to former angel investors, VCs or vested employees. Furthermore, the Zcash Development Fund would be subject to more explicit and transparent rules of governance, as outlined in the Specification section of this proposal.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -112,14 +112,14 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/blocktown-develo
|
|||
<p>Recognized objections to this proposal include:</p>
|
||||
<ul>
|
||||
<li>This proposal is not in accordance with the current Zcash protocol, which is programmed to allocate 100% of the coinbase to miners upon the first halving in 2020. However, at least during the next few years of Zcash’s infancy, we believe it is advantageous to have a funded and dedicated development team.</li>
|
||||
<li>The funding mechanism in this proposal is a Zcash Development Fund consisting of 10% of newly issued ZEC from block rewards after the first halving. This is in contrast to other proposals that allocate 20% of the mining rewards to the Zcash Development Fund – presumably a popular selection because the original Founder’s Reward was also set at 20%. For reasons we have explored in depth <a id="id12" class="footnote_reference" href="#blocktown-10pc">6</a> and summarized in <a id="id13" class="footnote_reference" href="#blocktown-summary">7</a>, we believe 10% instead of 20% is superior for network security, decentralization, uniting the Zcash community and renewing interest in ZEC.</li>
|
||||
<li>The funding mechanism in this proposal is a Zcash Development Fund consisting of 10% of newly issued ZEC from block rewards after the first halving. This is in contrast to other proposals that allocate 20% of the mining rewards to the Zcash Development Fund – presumably a popular selection because the original Founder’s Reward was also set at 20%. For reasons we have explored in depth <a id="footnote-reference-12" class="footnote_reference" href="#blocktown-10pc">6</a> and summarized in <a id="footnote-reference-13" class="footnote_reference" href="#blocktown-summary">7</a>, we believe 10% instead of 20% is superior for network security, decentralization, uniting the Zcash community and renewing interest in ZEC.</li>
|
||||
<li>Various parameters of governance in approving Applicant requests for funding from the Zcash Development Fund.</li>
|
||||
<li>The inclusion of a Third Entity in governance. One notable objection is the possibility of collusion between Third Entity and either the ECC or ZF that would result in a “usurped” Zcash Development Fund. We believe that the process for a community elected Third Entity, however, will mature over time – giving the community and Zcash stakeholders that important third opinion in deciding the proper allocation of funds. As demonstrated by the resilience of the Bitcoin network and community, well-formed communities tend to resist any collusion with corporations and controlling entities that do not promote the direct success of the network. Moreover, the inclusion of a Third Entity has the advantage of offering a “tie-breaker” in the event of a deadlock vote between the ECC and ZF and/or a situation where one entity holds the other hostage, which is a possible scenario in a 2-of-2 multisig agreement.</li>
|
||||
<li>This proposal does not have a clause dictating that a Recipient must abstain from voting. If a Recipient must abstain from voting in a 2-of-3 multisig governance system, then this could –as in the case of 2-of-2 multisig– result in an entity holding another hostage. For example, if the ECC refuses to fund the ZF until the ZF complies with the ECC’s demands, then the ECC has the power to deadlock any vote to fund the ZF, which requires the ECC and Third Entity to both vote approvingly.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Aspects of this proposal, particularly the Terminology and Specification sections, were adapted and expanded definitions and concepts put forth in Placeholder’s dev fund proposal from August 22, 2019 <a id="id14" class="footnote_reference" href="#placeholder-proposal">8</a>.</p>
|
||||
<p>Aspects of this proposal, particularly the Terminology and Specification sections, were adapted and expanded definitions and concepts put forth in Placeholder’s dev fund proposal from August 22, 2019 <a id="footnote-reference-14" class="footnote_reference" href="#placeholder-proposal">8</a>.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Created: 2019-08-24
|
|||
License: CC BY-SA 4.0 <<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>>
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709">https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>For clarity this ZIP defines these terms:</p>
|
||||
<ul>
|
||||
<li>Covenant is defined as a legally binding agreement, upon which a specific aspect of development of the Zcash protocol and/or adoption is scheduled and agreed.</li>
|
||||
|
|
@ -34,13 +34,13 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/dev-fund-supplem
|
|||
</section>
|
||||
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#motivation-and-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is supplemental to any Development Funding Proposal that places or purports to place conditions on how the Electric Coin Company (ECC) and the Zcash Foundation (ZF) use development funds, or take other related off-chain actions such as requirements and Covenants.</p>
|
||||
<p>For example, the proposal <a id="id2" class="footnote_reference" href="#zip-1006">2</a> provides that “[f]unds accruing to the Zcash Development Fund MUST be used only for ... technical work directly connected to the various software implementations of the Zcash protocol.” However, once development funding is approved and implemented via a Network Upgrade, there will be no enforcement mechanism to ensure that the ZF and ECC abide by this requirement.</p>
|
||||
<p>For example, the proposal <a id="footnote-reference-2" class="footnote_reference" href="#zip-1006">2</a> provides that “[f]unds accruing to the Zcash Development Fund MUST be used only for ... technical work directly connected to the various software implementations of the Zcash protocol.” However, once development funding is approved and implemented via a Network Upgrade, there will be no enforcement mechanism to ensure that the ZF and ECC abide by this requirement.</p>
|
||||
<p>This proposal aims to provide such an enforcement mechanism. If this proposal is adopted, then the ECC and/or ZF, as applicable MUST enter into a legal agreement that would entitle ZEC holders to enforce ECC’s/ZF’s performance of any Covenants. For the purposes of this proposal we will refer to the legal agreement as the “DevFund Charter” or “Charter” for short, but it MAY also be styled in other ways – e.g. as a Constitution, Bylaws, Fund Governance Agreement, etc.</p>
|
||||
<p>The DevFund Charter SHOULD be used to the benefit of all ZEC users, but the DevFund Charter MAY provide that an enforcement action requires the support of the holders of a plurality, majority or supermajority of ZEC. ZEC held by the ZF, ECC and their officers, directors, employees and/or affiliates SHOULD be excluded from the denominator in calculating the requisite plurality, majority or supermajority of ZEC.</p>
|
||||
<p><span class="editor-note">a "plurality" in a vote means the option that received more votes than any other single option, but it is unclear how this applies to "a plurality of ZEC". Taking into account experience from stake-weighted voting in other cryptocurrencies, the threshold of a simple majority (50%), or more, of all *issued* ZEC voting for any enforcement action would seem to be an extremely high bar.</span></p>
|
||||
<p>A quorum of yet-to-be-decided number of representatives from a number of groups specified by the DevFund Charter MAY provide that an enforcement action requires the support of the assigned representatives of each. One such mechanism SHOULD be ZEC balance, however this would require a 66% majority or a 85% supermajority. (These numbers are not binding and are up for discussion)</p>
|
||||
<p>It is assumed that the Electric Coin Company, Zcash Foundation, or party with a direct conflict of interest SHOULD identify their vote/signal - which MAY be rejected from the vote.</p>
|
||||
<p>Legal enforcement MAY occur in a court of law, non-binding mediation or binding arbitration. The DevFund Charter MAY also provide rights to other Zcash community constituencies, such as specified miners or the “Third Entity” contemplated by <a id="id3" class="footnote_reference" href="#zip-1006">2</a>.</p>
|
||||
<p>Legal enforcement MAY occur in a court of law, non-binding mediation or binding arbitration. The DevFund Charter MAY also provide rights to other Zcash community constituencies, such as specified miners or the “Third Entity” contemplated by <a id="footnote-reference-3" class="footnote_reference" href="#zip-1006">2</a>.</p>
|
||||
</section>
|
||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Because ZEC holders do not have specific legal rights against the ECC or ZF, but MAY wish to condition renewed on-chain development funding on the ECC’s or ZF’s agreement to use the development funds in certain ways, ZEC holders should have the legal right to enforce ECC’s/ZF’s compliance with those agreements.</p>
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ Created: 2019-09-02
|
|||
License: CC BY-SA 4.0 <<a href="https://creativecommons.org/licenses/by-sa/4.0/">https://creativecommons.org/licenses/by-sa/4.0/</a>>
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778">https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">2</a></p>
|
||||
<p>For clarity this ZIP defines these terms:</p>
|
||||
<ul>
|
||||
<li>Spirit is defined as what is the intended outcome of the ZIP. <a id="id2" class="footnote_reference" href="#spirit">1</a></li>
|
||||
<li>Spirit is defined as what is the intended outcome of the ZIP. <a id="footnote-reference-2" class="footnote_reference" href="#spirit">1</a></li>
|
||||
</ul>
|
||||
<table id="spirit" class="footnote">
|
||||
<tbody>
|
||||
|
|
@ -50,7 +50,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/kek-s-proposal-f
|
|||
</ul>
|
||||
<p><span class="editor-note">A previous version of this ZIP stated the following requirements: "The ECC's portion of block subsidy MUST be capped at their projected 1.1m USD costs a month." and "The ECC's portion of block subsidy MUST NOT be greater than 10% of total block subsidy of any one block." These requirements were mistakenly introduced in the process of ZIP editing; they do not reflect the intent of the original author @kek. They are also inconsistent with the summary that was posted in the Community Sentiment Collection Poll blog post at <<a href="https://www.zfnd.org/blog/community-sentiment-collection-poll/">https://www.zfnd.org/blog/community-sentiment-collection-poll/</a>>, which stated an ECC percentage of 20%. Votes on the Community Sentiment Collection Poll, the Community Advisory Panel Helios poll, and/or the stake-weighted petition reported at <<a href="https://forum.zcashcommunity.com/t/staked-poll-on-zcash-dev-fund-debate/34846/71">https://forum.zcashcommunity.com/t/staked-poll-on-zcash-dev-fund-debate/34846/71</a>>, should be interpreted with care in light of this ambiguity. Also note that the 1.1m USD cap could not in any case be specified as a consensus rule since there is no on-chain oracle for the USD price.</span></p>
|
||||
<section id="rationale"><h3><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Provisions that referred to specific block heights have been revised since they were inconsistent with the change in block target spacing <a id="id3" class="footnote_reference" href="#zip-0208">4</a> that will occur with the Blossom Network Upgrade <a id="id4" class="footnote_reference" href="#zip-0206">3</a>; and even if recalculated, fixed block heights would potentially be inconsistent with future changes in target block spacing.</p>
|
||||
<p>Provisions that referred to specific block heights have been revised since they were inconsistent with the change in block target spacing <a id="footnote-reference-3" class="footnote_reference" href="#zip-0208">4</a> that will occur with the Blossom Network Upgrade <a id="footnote-reference-4" class="footnote_reference" href="#zip-0206">3</a>; and even if recalculated, fixed block heights would potentially be inconsistent with future changes in target block spacing.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="raised-objections-and-issues-so-far"><h2><span class="section-heading">Raised objections and issues so far</span><span class="section-anchor"> <a rel="bookmark" href="#raised-objections-and-issues-so-far"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ Created: 2019-08-31
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812">https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">2</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">2</a></p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>I try to put the best pieces of various proposals together. A 20% of the block reward for a 4-year development fund that disburses to a trust controlled by both the Electric Coin Company (ECC) and Zcash Foundation (ZF), but with stringent controls on how funds may be allocated. It sidesteps code complexity in implementation by off-loading disbursements to a legal trust; funds the ECC/ZF; ECC stays a for-profit with restrictions; funds external parties through ZF Grants; all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.</p>
|
||||
|
|
@ -31,21 +31,21 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
|
|||
<p>Zcash won't thrive without a dev fund. I wish this wasn't true (I really do), and for the longest time I was against the idea. But I've come to fear the alternative without one; I fear the privacy technology pioneered by Zcash may never reach its true potential — not just for our community, but for others interested in novel approaches to private money.</p>
|
||||
<p>The Foundation, ECC, and broader community has offered many suggestions and guidelines for a potential dev fund, below is my attempt at synthesizing them into a compromise that's greater than the sum of its parts:</p>
|
||||
<ul>
|
||||
<li>The ECC and Zcash Foundation shouldn't get a blank check; accountability is a prerequisite for any disbursement, based on the Foundation's statement <a id="id3" class="footnote_reference" href="#zfnd-guidance">3</a> and other proposals being suggested.</li>
|
||||
<li>The ECC and Zcash Foundation shouldn't get a blank check; accountability is a prerequisite for any disbursement, based on the Foundation's statement <a id="footnote-reference-3" class="footnote_reference" href="#zfnd-guidance">3</a> and other proposals being suggested.</li>
|
||||
<li>It's possible for the ECC to remain a for-profit, but with (legally enforced) restrictions that ensure accountability and add teeth to their claim that no early investors are enriched by a new dev fund / no new investors are beneficiaries.</li>
|
||||
<li>A nontrivial portion of the funds should be directed to users/organisations outside of the ECC/Zcash Foundation, and the ECC/Zcash Foundation should be in the minority in deciding how these funds are disbursed (e.g. through some process with broader input beyond ECC/Zcash Foundation employees, like a more constrained version of Placeholder or Blocktower's "third party" proposals).</li>
|
||||
<li>The actual code changes for the NU4 network upgrade should be minimal and the "governance complexity" should be offloaded to legal agreements, not engineering hours. The dev fund would be deposited into a single address for the fund (ideally shielded with a viewing key) controlled through a trust (originally Andrew Miller’s idea), disbursed quarterly based on the accountability requirements and shielded adoption metrics described below. Trustees will be mutually agreed upon by the ECC and Zcash Foundation, and the Zcash Foundation will bear the cost of operating the trust.</li>
|
||||
<li>The gross amount of the dev fund should still be 20% of the block reward, and it should end in 4 years. (Unless we go through another process like this one to extend it, though I personally hope we don’t.)</li>
|
||||
</ul>
|
||||
<p><span class="editor-note">for security reasons, it may be useful to refine the "single address" to a list of rolling addresses as described in section 7.8 of the current protocol specification. Other references to a "single address" in this document have not been changed.</span></p>
|
||||
<p><em>Please note: a previous version of this proposal included a portion of the funds being tied to shielded adoption, based on ideas brought forward by Eran Tromer in</em> <a id="id4" class="footnote_reference" href="#tromer-comment">4</a>. <em>After many discussions I came to worry about the gameability of the metric and decided to drop it entirely.</em></p>
|
||||
<p><em>Please note: a previous version of this proposal included a portion of the funds being tied to shielded adoption, based on ideas brought forward by Eran Tromer in</em> <a id="footnote-reference-4" class="footnote_reference" href="#tromer-comment">4</a>. <em>After many discussions I came to worry about the gameability of the metric and decided to drop it entirely.</em></p>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Upon the NU4 network activation, 20% of the mining reward (post-Blossom / post-halvening = 0.625 ZEC per block) MUST go to a single shielded address with a viewing key widely distributed and known to the community and controlled by a trust established by the ECC and Zcash Foundation. If the trust and associated address aren't established by the NU4 activation deadline, then there MUST NOT be any change to the mining reward. Every quarter-year (105,000 blocks at the post-Blossom rate), until 4 years after NU4 activation (1,680,000 blocks at the post-Blossom rate), the trust SHOULD disburse funds the following way, requiring a public report with every disbursement:</p>
|
||||
<ul>
|
||||
<li>30% of the fund to the ECC, if they meet the accountability requirements set by the trust/described below;</li>
|
||||
<li>30% of the fund to the Zcash Foundation, if they meet the accountability requirements set by the trust/described below;</li>
|
||||
<li>40% of the fund to the Zcash Foundation as a RESTRICTED donation <a id="id5" class="footnote_reference" href="#restricted-funds">5</a> purely for disbursement through ZF Grants <a id="id6" class="footnote_reference" href="#zfnd-grants">6</a>, with additional restrictions and stipulations described below.</li>
|
||||
<li>40% of the fund to the Zcash Foundation as a RESTRICTED donation <a id="footnote-reference-5" class="footnote_reference" href="#restricted-funds">5</a> purely for disbursement through ZF Grants <a id="footnote-reference-6" class="footnote_reference" href="#zfnd-grants">6</a>, with additional restrictions and stipulations described below.</li>
|
||||
</ul>
|
||||
<p><span class="editor-note">When this proposal was written it was expected that NU4 activation would correspond exactly to the first (October 2020) halvening. Since that may not be the case, I have resolved a potential ambiguity in the original wording by specifying that the trust disburses funds for 4 years, rather than that it disburses funds until the second (October 2024) halvening.</span></p>
|
||||
<section id="example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><h3><span class="section-heading">Example disbursements by the trust for a hypothetical 105000-block period</span><span class="section-anchor"> <a rel="bookmark" href="#example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -58,10 +58,10 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
|
|||
<p>This example assumes no change to target block spacing.</p>
|
||||
</section>
|
||||
<section id="the-trust-s-accountability-requirements"><h3><span class="section-heading">The trust's accountability requirements</span><span class="section-anchor"> <a rel="bookmark" href="#the-trust-s-accountability-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Here I'm borrowing from the Foundation's guidance <a id="id7" class="footnote_reference" href="#zfnd-guidance">3</a> but adding some stipulations to cement the Foundation's independence, prevent the Foundation from hoarding its endowment, and handle the ECC as a for-profit. Before disbursing funds each quarter, the trust MUST validate that both the ECC and Zcash Foundation:</p>
|
||||
<p>Here I'm borrowing from the Foundation's guidance <a id="footnote-reference-7" class="footnote_reference" href="#zfnd-guidance">3</a> but adding some stipulations to cement the Foundation's independence, prevent the Foundation from hoarding its endowment, and handle the ECC as a for-profit. Before disbursing funds each quarter, the trust MUST validate that both the ECC and Zcash Foundation:</p>
|
||||
<ul>
|
||||
<li>Published quarterly technical roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand;</li>
|
||||
<li>(if the first disbursement in a calendar year) Published a yearly review of organization performance, along the lines of the Zcash Foundation's "State of the Foundation" report <a id="id8" class="footnote_reference" href="#zfnd-state">7</a>.</li>
|
||||
<li>(if the first disbursement in a calendar year) Published a yearly review of organization performance, along the lines of the Zcash Foundation's "State of the Foundation" report <a id="footnote-reference-8" class="footnote_reference" href="#zfnd-state">7</a>.</li>
|
||||
</ul>
|
||||
<p>For the Zcash Foundation, the trust MUST further require:</p>
|
||||
<ul>
|
||||
|
|
@ -83,7 +83,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
|
|||
</section>
|
||||
<section id="the-zf-grants-portion"><h3><span class="section-heading">The ZF Grants portion</span><span class="section-anchor"> <a rel="bookmark" href="#the-zf-grants-portion"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A portion of the dev fund goes to the Foundation but with the express (and restricted) purpose of being distributed via ZF Grants (a restriction that MUST be legally enforced by the trust). The Foundation would continue to administer ZF Grants and distribute funds, but it SHOULD NOT decide where those funds go and would not allowed to be recipients of these funds; instead, the trust MUST demand that the ZF Grants process include broader input in the manner described below. In the discussions around the various "third party" proposals, some have suggested a 3-of-5 approach where the ECC and Zcash Foundation are in the minority; I think that structure would work well for these funds. It's not the full dev fund so we are limiting the downside risk of selecting the "wrong" third parties, which also means we can give those third parties more voice (by making them outnumber the ECC/Zcash Foundation). The Foundation MAY also chose to fund ZF Grants <em>beyond</em> the restricted donations from the trust, but doing so would be at their discretion.</p>
|
||||
<p>Thanks to the discussion on Matt Luongo's proposal there's a good blueprint for how this group would work. I'm borrowing some comments I made on Matt's proposal thread <a id="id9" class="footnote_reference" href="#acityinohio-comment">8</a> and modifying them to apply to a ZF Grants-specific Grant Review Committee, rather than the Foundation's board.</p>
|
||||
<p>Thanks to the discussion on Matt Luongo's proposal there's a good blueprint for how this group would work. I'm borrowing some comments I made on Matt's proposal thread <a id="footnote-reference-9" class="footnote_reference" href="#acityinohio-comment">8</a> and modifying them to apply to a ZF Grants-specific Grant Review Committee, rather than the Foundation's board.</p>
|
||||
<p>The ZF Grant Review Committee would be compromised of five members, voted on in the following manner:</p>
|
||||
<ul>
|
||||
<li>1 seat for the ECC. Though the appointed member may change, they retain power to choose the seat for 4 years.</li>
|
||||
|
|
@ -106,7 +106,7 @@ Discussions-To: <<a href="https://forum.zcashcommunity.com/t/a-grand-compromi
|
|||
<p>The crux of this proposal still centers around the idea that the Zcash Foundation and ECC share responsibility for protocol development, which is now bolstered by the 2-of-2 agreement on the trademark. It assumes and expects that both continue developing consensus-compatible node software that interacts with the Zcash network. But it mandates accountability for disbursement of funds to the ECC/Zcash Foundation, and expands outside stakeholder input on funds that <em>wouldn't</em> be earmarked for the ECC/Zcash Foundation (similar to Placeholder's earlier version of their proposal and Matt Luongo's current proposal), while it doesn’t preclude the possibility of migrating to broader "2-of-3" later on future governance decisions.</p>
|
||||
</section>
|
||||
<section id="why-a-trust"><h3><span class="section-heading">Why a trust?</span><span class="section-anchor"> <a rel="bookmark" href="#why-a-trust"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The main reason: reducing complexity creep in consensus code. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 with the simplest possible code-change and spend more time ironing out the details of the trust "off-chain." Since both the ECC and the Zcash Foundation are based in the US, using a trust with well-specified criteria for disbursements is a reasonable path. This also fits in nicely with lex-node's proposal <a id="id10" class="footnote_reference" href="#zip-1007">9</a> for legal covenants on funding.</p>
|
||||
<p>The main reason: reducing complexity creep in consensus code. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 with the simplest possible code-change and spend more time ironing out the details of the trust "off-chain." Since both the ECC and the Zcash Foundation are based in the US, using a trust with well-specified criteria for disbursements is a reasonable path. This also fits in nicely with lex-node's proposal <a id="footnote-reference-10" class="footnote_reference" href="#zip-1007">9</a> for legal covenants on funding.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ License: Public Domain
|
|||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425">https://forum.zcashcommunity.com/t/zip-keep-it-simple-zcashers-kisz-10-to-ecc-10-to-zfnd/35425</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/293">https://github.com/zcash/zips/pull/293</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>ECC</dt>
|
||||
|
|
|
|||
|
|
@ -25,15 +25,15 @@ License: MIT
|
|||
Discussions-To: <<a href="https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560">https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/308">https://github.com/zcash/zips/pull/308</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">6</a> and the Zcash Trademark Donation and License Agreement (<a id="id3" class="footnote_reference" href="#trademark">4</a> or successor agreement).</p>
|
||||
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. <a id="id4" class="footnote_reference" href="#protocol">2</a></p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">6</a> and the Zcash Trademark Donation and License Agreement (<a id="footnote-reference-3" class="footnote_reference" href="#trademark">4</a> or successor agreement).</p>
|
||||
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. <a id="footnote-reference-4" class="footnote_reference" href="#protocol">2</a></p>
|
||||
<p>"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric Coin Company, LLC.</p>
|
||||
<p>"Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit corporation of that name.</p>
|
||||
<p>"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit corporation of that name.</p>
|
||||
<p>"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). <a id="id5" class="footnote_reference" href="#section501c3">12</a></p>
|
||||
<p>"Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at <a id="id6" class="footnote_reference" href="#zf-community">11</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
<p>"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). <a id="footnote-reference-5" class="footnote_reference" href="#section501c3">12</a></p>
|
||||
<p>"Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at <a id="footnote-reference-6" class="footnote_reference" href="#zf-community">11</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-7" class="footnote_reference" href="#protocol-networks">3</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist of 20% of the block subsidies, split into 3 slices:</p>
|
||||
|
|
@ -119,7 +119,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/308">https://githu
|
|||
</ul>
|
||||
<p>BP, ECC, ZF, and grant recipients MUST promptly disclose any security or privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).</p>
|
||||
<p>BP's reports, ECC's reports, and ZF's annual report on its non-grant operations, SHOULD be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.</p>
|
||||
<p>All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative <a id="id8" class="footnote_reference" href="#osd">5</a>), preferably the MIT license.</p>
|
||||
<p>All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative <a id="footnote-reference-8" class="footnote_reference" href="#osd">5</a>), preferably the MIT license.</p>
|
||||
</section>
|
||||
<section id="enforcement"><h4><span class="section-heading">Enforcement</span><span class="section-anchor"> <a rel="bookmark" href="#enforcement"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>For grant recipients, these conditions SHOULD be included in their contract with ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.</p>
|
||||
|
|
@ -137,8 +137,8 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/308">https://githu
|
|||
</section>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal is a limited modification of Eran Tromer's ZIP 1012 <a id="id9" class="footnote_reference" href="#zip-1012">10</a> by the Zcash Foundation, the ECC, further modified by feedback from the community and the results of the <a href="https://vote.heliosvoting.org/helios/elections/43b9bec8-39a1-11ea-914c-b6e34ffa859a/view">latest Helios poll</a>.</p>
|
||||
<p>Eran's proposal is most closely based on the Matt Luongo 'Decentralize the Dev Fee' proposal (ZIP 1011) <a id="id10" class="footnote_reference" href="#zip-1011">9</a>. Relative to ZIP 1011 there are substantial changes and mixing in of elements from <em>@aristarchus</em>'s '20% Split Evenly Between the ECC and the Zcash Foundation' (ZIP 1003) <a id="id11" class="footnote_reference" href="#zip-1003">7</a>, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) <a id="id12" class="footnote_reference" href="#zip-1010">8</a>, and extensive discussions in the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>.</p>
|
||||
<p>This proposal is a limited modification of Eran Tromer's ZIP 1012 <a id="footnote-reference-9" class="footnote_reference" href="#zip-1012">10</a> by the Zcash Foundation, the ECC, further modified by feedback from the community and the results of the <a href="https://vote.heliosvoting.org/helios/elections/43b9bec8-39a1-11ea-914c-b6e34ffa859a/view">latest Helios poll</a>.</p>
|
||||
<p>Eran's proposal is most closely based on the Matt Luongo 'Decentralize the Dev Fee' proposal (ZIP 1011) <a id="footnote-reference-10" class="footnote_reference" href="#zip-1011">9</a>. Relative to ZIP 1011 there are substantial changes and mixing in of elements from <em>@aristarchus</em>'s '20% Split Evenly Between the ECC and the Zcash Foundation' (ZIP 1003) <a id="footnote-reference-11" class="footnote_reference" href="#zip-1003">7</a>, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) <a id="footnote-reference-12" class="footnote_reference" href="#zip-1010">8</a>, and extensive discussions in the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>.</p>
|
||||
<p>The authors are grateful to all of the above for their excellent ideas and any insightful discussions, and to forum users <em>@aristarchus</em> and <em>@dontbeevil</em> for valuable initial comments on ZIP 1012.</p>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/253">https://githu
|
|||
<p>{Delete this section.}</p>
|
||||
</section>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{Edit this to reflect the key words that are actually used.} The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>{Edit this to reflect the key words that are actually used.} The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="footnote-reference-1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>{Term to be defined}</dt>
|
||||
|
|
@ -34,7 +34,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/253">https://githu
|
|||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{Describe what this proposal does, typically in a few paragraphs.</p>
|
||||
<p>The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.</p>
|
||||
<p>Use links where applicable, e.g. <a id="id2" class="footnote_reference" href="#protocol">2</a> <a id="id3" class="footnote_reference" href="#protocol-introduction">3</a>.}</p>
|
||||
<p>Use links where applicable, e.g. <a id="footnote-reference-2" class="footnote_reference" href="#protocol">2</a> <a id="footnote-reference-3" class="footnote_reference" href="#protocol-introduction">3</a>.}</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>{Why is this proposal needed?</p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue