zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 224: Minor fixes

This commit is contained in:
Jack Grigg 2021-02-28 02:19:37 +00:00 committed by Daira Hopwood
parent 6fa961877c
commit 2ae31ccdb7
2 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
zip-0224.html
View File

@ -146,17 +146,17 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<p>The remainder of the changes we make relative to Sapling are motivated by simplifying the Sapling protocol (and fixing deficiencies), and using protocol primitives that are more efficient in the UltraPLONK arithmetization.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via an Orchard-specific
<span class="math">\(\mathsf{valueBalance}\)</span>
<p>This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via the
<span class="math">\(\mathsf{valueBalanceOrchard}\)</span>
transaction field. This has the following considerations:</p>
<ul>
<li>The Orchard pool forms a separate anonymity set from the Sprout and Sapling pools. The new pool will start with zero notes (as Sapling did at its deployment), but transactions within Orchard will increase the size of the anonymity set more rapidly than Sapling, due to the arity-hiding nature of Orchard actions.</li>
<li>The "transparent turnstile" created by the
<span class="math">\(\mathsf{valueBalance}\)</span>
<span class="math">\(\mathsf{valueBalanceOrchard}\)</span>
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 userbases 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="id28" class="footnote_reference" href="#zip-0315">26</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="id28" class="footnote_reference" href="#zip-0315">26</a></li>
</ul>
</li>
</ul>

16
zip-0224.rst
View File

@ -194,26 +194,26 @@ Security and Privacy Considerations
===================================
This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports
spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via an
Orchard-specific :math:`\mathsf{valueBalance}` transaction field. This has the following
spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via the
:math:`\mathsf{valueBalanceOrchard}` transaction field. This has the following
considerations:
- The Orchard pool forms a separate anonymity set from the Sprout and Sapling pools. The
new pool will start with zero notes (as Sapling did at its deployment), but transactions
within Orchard will increase the size of the anonymity set more rapidly than Sapling,
due to the arity-hiding nature of Orchard actions.
- The "transparent turnstile" created by the :math:`\mathsf{valueBalance}` 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.
- The "transparent turnstile" created by the :math:`\mathsf{valueBalanceOrchard}` 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.
- 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.
- Wallets should take steps to migrate their userbases to store funds uniformly within
- 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. [#zip-0315]_