We use (version 10 of) the IETF hash-to-curve Internet Draft 25 to implement +
We use (version 10 of) the IETF hash-to-curve Internet Draft 26 to implement
\(\mathsf{GroupHash}\)
, instead of the BLAKE2s-based mechanism used for Sapling. We specifically use the "simplified SWU" algorithm, which provides an infallible
\(\mathsf{GroupHash}\)
@@ -40,7 +40,7 @@ Discussions-To: <https://g
TBD TBD 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
+ \(\mathsf{valueBalance}\)
+ transaction field. This has the following considerations:Proving system
@@ -140,7 +140,20 @@ Discussions-To: <https://g
Security and Privacy Considerations
-
+
+
+ Test Vectors
@@ -349,10 +362,18 @@ Discussions-To: <https://g
-
+
+
+
+ 25
+ ZIP 315: Best Practices for Wallet Handling of Multiple Pools
+
+
+
+
@@ -360,7 +381,7 @@ Discussions-To: <https://g
26
draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves
-
diff --git a/zip-0224.rst b/zip-0224.rst
index ac7c2ee7..b39b6d08 100644
--- a/zip-0224.rst
+++ b/zip-0224.rst
@@ -171,7 +171,29 @@ TBD
Security and Privacy Considerations
===================================
-TBD
+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
+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.
+- 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
+ the Orchard pool. Best practices for wallet handling of multiple pools will be covered
+ in a subsequent ZIP. [#zip-0315]_
Test Vectors
@@ -220,5 +242,6 @@ References
.. [#design-nullifiers] `The Orchard Book: 3.5. Nullifiers 26
+ 27
Pallas/Vesta supporting evidence