Motivations for Alternative 2 
- Traceable Unified Addresses fit into the existing Zcash Unified Address ecosystem. As such, wallets that support Unified Addresses will be able to parse (but not necessarily send to) a Traceable Unified Address. Even in the case that Traceable Receivers are not understood by the sending wallet, a Unified Address-supporting wallet will be able to automatically provide good error messages for their users to indicate that the wallet needs to be updated to understand these addresses.
- In addition, by integrating with the Unified Address framework, it becomes possible for the addresses being generated to include extra metadata, in particular, metadata items such as an Address Expiry Height or Address Expiry Date may be included. For exchange use cases such as Binance's, it is useful to ensure that an address provided to a user has a limited utility life, such that after expiration the user must obtain a new address in order to be able to continue to send funds.
+ Traceable Unified Addresses fit into the existing Zcash Unified Address ecosystem. Existing Consumers that support Unified Addresses will automatically be able to recognize a Traceable Unified Address as a valid Zcash address, but will not be able to send to that address unless they update their code to understand the new Receiver Typecode defined in this ZIP. Even in the case that Traceable Receivers are not understood by the sending wallet, a Unified Address-supporting wallet will be able to automatically provide good error messages for their users to indicate that the wallet needs to be updated to understand and send to these addresses.
+ In addition, by integrating with the Unified Address framework, it becomes possible for the addresses being generated to include extra metadata, in particular, metadata items such as an Address Expiry Height or Address Expiry Date may be included. For exchange use cases such as Binance's, it is useful to ensure that an address provided to a user has a limited utility life, such that after expiration the user must obtain a new address in order to be able to continue to send funds .
- Detailed Specification (Alternative 2)
- Upon activation of this ZIP, the section Encoding of Unified Addresses of ZIP 316 will be modified to define a new Traceable Receiver Type having typecode
+ Specification (Alternative 2)
+ Upon activation of this ZIP, the section Encoding of Unified Addresses of ZIP 316 will be modified to define a new Traceable Receiver Type having typecode
\(\mathtt{0x04}\)
- , the value of which must be the 20-byte validating key hash of a Zcash P2PKH Address as defined in .
- The "Requirements for both Unified Addresses and Unified Viewing Keys" section of ZIP 316 will be modified as follows:
+ , the value of which MUST be the 20-byte validating key hash of a Zcash P2PKH Address as defined in .
+ The "Requirements for both Unified Addresses and Unified Viewing Keys" section of ZIP 316 will be modified as follows — the text:
A Unified Address or Unified Viewing Key MUST contain at least one
shielded Item (Typecodes :math:`\mathtt{0x02}` and :math:`\mathtt{0x03}`).
The rationale is that the existing P2SH and P2PKH transparent-only
@@ -91,7 +112,7 @@ address formats, and the existing P2PKH extended public key format,
suffice for representing transparent Items and are already supported
by the existing ecosystem.
will be replaced by:
- A Unified Address MUST contain at least one Receiver, plus any number
+ A Unified Address MUST contain at least one Receiver and any number
of Metadata Items. The selection of Receivers is further restricted
such that a Unified Address MUST **either** contain at least one shielded
Receiver (Typecodes :math:`\mathtt{0x02}` and :math:`\mathtt{0x03}`), OR
@@ -102,20 +123,24 @@ A Unified Viewing Key MUST contain at least one shielded Item (Typecodes
:math:`\mathtt{0x02}` and :math:`\mathtt{0x03}`).
A Traceable Unified Address is produced from a mainnet Zcash P2PKH address by executing the following steps:
- - Decode the address to a byte array using the
base58check decoding algorithm.
- - Remove the two-byte address prefix from the resulting byte array. These bytes should be equal to
+
- Decode the address to a byte array using the Base58Check decoding algorithm .
+ - If the length of the resulting byte sequence is not 22 bytes or if its two-byte address prefix is not
\(\mathtt{[0x1C, 0xB8]}\)
- . The remainder of the byte array (the validating key hash) should have a length of 20 bytes.
+ , return an error. Otherwise, let the validating key hash be the remaining 20 bytes of the array after removing the two-byte address prefix.
- Construct a new Unified Address using a single Traceable Receiver
\(\mathtt{0x04}\)
- with the 20-byte validating_key_hash as its value. In addition, metadata items such as an Address Expiry Height or Address Expiry Date may be included.
+ with the 20-byte validating_key_hash as its value. In addition, metadata items such as an Address Expiry Height or Address Expiry Date MAY be included.
+ Wallets and other Senders sending to a Traceable Unified Address MUST ensure that only transparent UTXOs are spent in the creation of a transaction.