From af1bee056fb2a230c9d5f10144f52947506a1561 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 12 Jul 2021 13:18:31 +0100 Subject: [PATCH 1/2] ZIP 316: clarify requirements, especially for Unified Viewing Keys. This required introducing the Consumer definition, since a Consumer of a UVK is not necessarily a Sender. Signed-off-by: Daira Hopwood --- zip-0316.html | 56 ++++++++++++----------- zip-0316.rst | 120 ++++++++++++++++++++++++++++---------------------- 2 files changed, 98 insertions(+), 78 deletions(-) diff --git a/zip-0316.html b/zip-0316.html index 451fc5916..d11d82b7a 100644 --- a/zip-0316.html +++ b/zip-0316.html @@ -29,8 +29,10 @@
A wallet or other software that can receive transfers of assets (such as ZEC) or in the future potentially other transaction-based state changes.
Producer
A wallet or other software that can create an Address (normally also a Recipient).
+
Consumer
+
A wallet or other software that can make use of an Address that it is given.
Sender
-
A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future.
+
A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future. Senders are a subset of Consumers.
Receiver
The necessary information to transfer an asset to a Recipient that generated that Receiver using a specific Transfer Protocol. Each Receiver is associated unambiguously with a specific Receiver Type, identified by an integer Typecode.
Receiver Encoding
@@ -63,10 +65,10 @@

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, for many purposes it suffices to consider the string encoding.)

The Orchard proposal 6 adds a new Address type, Orchard Addresses.

-

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 Sender 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.

+

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.

The goals for a Unified Address standard are as follows:

Note that the size of each piece is at least 24 bytes.

-

It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Sender.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.

+

It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.

Efficiency

The cost is dominated by 4 BLAKE2b compressions for diff --git a/zip-0316.rst b/zip-0316.rst index b0a383d2b..4af881f0a 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -383,15 +383,15 @@ Requirements for both Unified Addresses and Unified Viewing Keys upgrade [#zip-0211]_) to send funds into the Sprout chain value pool, this would not be generally useful. -* Senders MUST ignore constituent Addresses/Viewing Keys with +* Consumers MUST ignore constituent Addresses/Viewing Keys with Typecodes they do not recognize. -* Senders MUST reject Unified Addresses/Viewing Keys in which the +* 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. -* Senders MUST reject Unified Addresses/Viewing Keys in which *any* +* Consumers MUST reject Unified Addresses/Viewing Keys in which *any* constituent address does not meet the validation requirements of its Receiver Encoding, as specified in the Zcash Protocol Specification [#protocol-nu5]_. @@ -509,7 +509,7 @@ a Unified Address, UFVK, or UIVK appends 16 zero bytes to the raw encoding, then applies :math:`\mathsf{F4Jumble}` before encoding the result with Bech32m. -The Sender rejects any Bech32m-decoded byte sequence that is less than +The Consumer rejects any Bech32m-decoded byte sequence that is less than 48 bytes or greater than 16448 bytes; otherwise it applies :math:`\mathsf{F4Jumble}^{-1}`. It rejects any result that does not end in 16 zero bytes, before stripping these 16 bytes and parsing the result. @@ -562,7 +562,7 @@ Note that the size of each piece is at least 24 bytes. It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to -increase the work done by the Sender.) However, given that Unified Addresses +increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.