From 12a16786815e3be292c24350d944ad21c026174c Mon Sep 17 00:00:00 2001
From: Daira Hopwood 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. zcashd version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account
+ \(\mathtt{0x7FFFFFFF}\)
+ , using hardened derivation for
+ \(address\_index\)
+ . Wallets implementing Sprout ZIP 32 derivation MUST support the following path: 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 10 adds a new Address type, Orchard Addresses. The Orchard proposal 18 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 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: 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. Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending. Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs 11 and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type. Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs 19 and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type. Wallets follow a model Interaction Flow as follows: The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards. 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. There is a well-defined transformation between the QR Code and string encodings in either direction. The string encoding fits into ZIP-321 Payment URIs 11 and general URIs without introducing parse ambiguities. The string encoding fits into ZIP-321 Payment URIs 19 and general URIs without introducing parse ambiguities. The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion. The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them. 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 2. For a Transparent P2PKH Address that is derived according to BIP 32 12 and BIP 44 15, 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. For a Transparent P2PKH Address that is derived according to BIP 32 20 and BIP 44 23, 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. A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.Sprout key path
@@ -90,7 +90,7 @@ Discussions-To: <https://g
Overview
Concepts
Viewing Keys
Open Issues and Known Concerns
@@ -150,10 +150,10 @@ Discussions-To: <https://g
A Receiver Encoding is the raw encoding of a Shielded Payment Address, or the \(160\!\) - -bit script hash of a P2SH address 19, or the + -bit script hash of a P2SH address 27, or the \(160\!\) - -bit validating key hash of a P2PKH address 18.
+ -bit validating key hash of a P2PKH address 26.Let padding
be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append padding
to the concatenated encodings, and then apply the
\(\mathsf{F4Jumble}\)
- algorithm as described in Jumbling. The output is then encoded with Bech32m 17, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.
To decode a Unified Address Encoding, a Consumer MUST use the following procedure:
padding
be the Human-Readable Part, padded to 16 bytes as for encoding. If the result ends in padding
, remove these 16 bytes; otherwise reject.For Unified Addresses on Mainnet, the Human-Readable Part (as defined in 17) is “u
”. For Unified Addresses on Testnet, the Human-Readable Part is “utest
”.
For Unified Addresses on Mainnet, the Human-Readable Part (as defined in 25) is “u
”. For Unified Addresses on Testnet, the Human-Readable Part is “utest
”.
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.
Unified Full or Incoming Viewing Keys are encoded and decoded analogously to Unified Addresses. A Consumer MUST use the decoding procedure from the previous section. For Viewing Keys, a Consumer will normally take the union of information provided by all contained Receivers, and therefore the Priority List defined in the previous section is not used.
-For each UFVK Type or UIVK Type currently defined in this specification, the same Typecode is used as for the corresponding Receiver Type in a Unified Address. Additional UFVK Types and UIVK Types MAY be defined in future, and these will not necessarily use the same Typecode as the corresponding Unified Address.
-The following UFVK or UIVK Encodings are used in place of the +
For each FVK Type or IVK Type currently defined in this specification, the same Typecode is used as for the corresponding Receiver Type in a Unified Address. Additional FVK Types and IVK Types MAY be defined in future, and these will not necessarily use the same Typecode as the corresponding Unified Address.
+The following FVK or IVK Encodings are used in place of the \(\mathtt{addr}\) field:
The Human-Readable Parts (as defined in 17) of Unified Viewing Keys are defined as follows:
+The Human-Readable Parts (as defined in 25) of Unified Viewing Keys are defined as follows:
uivk
” for Unified Incoming Viewing Keys on Mainnet;uivktest
” for Unified Incoming Viewing Keys on Testnet;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 6.
+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 10.
For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes \(\mathtt{0xFFFA}\) to \(\mathtt{0xFFFF}\) inclusive. This provides for six simultaneous experiments, which can be referred to as experiments A to F. This should be sufficient because experiments are expected to be reasonably short-term, and should otherwise be either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued.
+New types SHOULD maintain the same distinction between FVK and IVK authority as existing types, i.e. an FVK is intended to give access to view all transactions to and from the address, while an IVK is intended to give access only to view incoming payments (as opposed to change).
Each UIVK Encoding can straightforwardly be derived from the corresponding UFVK Encoding, without changing the Typecode. In the case of a Transparent P2PKH UFVK Encoding, the UIVK Encoding is the same.
+The following derivations are applied to each component FVK:
+In each case, the Typecode remains the same as in the FVK.
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,
There are no additional constraints on an Orchard diversifier index.
-In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH UIVK, the diversifier index is used as a BIP 44 child key index at the Index level to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation 14 MUST be used, with the Change element of the path being 0, and the Index element of the path being the diversifier index 16. That is, the BIP 44 path of the Transparent P2PKH Receiver MUST be:
-In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level 24 to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation 22 MUST be used. The IVK is assumed to correspond to the extended public key for the 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 + \(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\) +
Security goal (near second preimage resistance):
@@ -605,7 +625,7 @@ c^{n+m}}{q}.\)4 | +Zcash Protocol Specification, Version 2020.2.16. Section 4.2.2: Sapling Key Components | +
---|
5 | +Zcash Protocol Specification, Version 2020.2.16. Section 4.2.3: Orchard Key Components |
---|
8 | +Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys | +
---|
9 | +Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.4: Orchard Raw Full Viewing Keys |
---|
6 | +10 | ZIP 0: ZIP Process |
---|
11 | +ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions | +
---|