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

Don't use UFVK or UIVK when referring to Viewing Key components. 

(A UFVK or UIVK is properly only the whole thing.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-10-25 20:10:43 +01:00
parent b85a249a59
commit 880bf02301
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
zip-0316.rst
View File

@ -379,13 +379,13 @@ 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,
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 UFVK Types and UIVK Types MAY be defined in
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 UFVK or UIVK Encodings are used in place of the
The following FVK or IVK Encodings are used in place of the
:math:`\mathtt{addr}` field:
* An Orchard UFVK or UIVK Encoding, with Typecode :math:`\mathtt{0x03},`
@ -396,16 +396,16 @@ The following UFVK or UIVK Encodings are used in place of the
while the UIVK uses its non-change child key at path
:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`.
* A Sapling UFVK Encoding, with Typecode :math:`\mathtt{0x02},` is
* A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is
the encoding of a Sapling Extended Full Viewing Key defined in
[#zip-0032-sapling-extfvk]_. This SHOULD be an Extended Full Viewing
Key at the Account level of the ZIP 32 hierarchy.
* A Sapling UIVK Encoding, also with Typecode :math:`\mathtt{0x02},`
* A Sapling IVK Encoding, also with Typecode :math:`\mathtt{0x02},`
is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by
:math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).`
Unlike Orchard, a Sapling UIVK is associated with the same spending
authority as the corresponding UFVK, i.e. also at the Account level.
Unlike Orchard, a Sapling IVK is associated with the same spending
authority as the corresponding FVK, i.e. also at the Account level.
* There is no defined way to represent a Viewing Key for a Transparent
P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be
@ -414,12 +414,12 @@ The following UFVK or UIVK Encodings are used in place of the
treated as unrecognized by Consumers.
* For Transparent P2PKH Addresses that are derived according to BIP 32
[#bip-0032]_ and BIP 44 [#bip-0044]_, the UFVK and UIVK Encodings
[#bip-0032]_ and BIP 44 [#bip-0044]_, the FVK and IVK Encodings
have Typecode :math:`\mathtt{0x00}.` Both of these encodings are the
serialization of an extended public key, defined in the section
“Serialization format” of BIP 32 [#bip-0032-serialization-format]_.
However, the UFVK uses the key at the Account level, i.e. at path
:math:`m / 44' / coin\_type' / account'`, while the UIVK uses its
However, the FVK uses the key at the Account level, i.e. at path
:math:`m / 44' / coin\_type' / account'`, while the IVK uses its
non-change child key at path :math:`m / 44' / coin\_type' / account' / 0`.
(In accordance with BIP 44 and differently to Orchard, the Change level
uses non-hardened derivation.)
@ -449,10 +449,10 @@ Requirements for both Unified Addresses and Unified Viewing Keys
all less than 256 bytes and so could use a one-byte length field,
encodings for experimental types may be longer.)
* Each Receiver and UFVK SHOULD represent an Address or Full Viewing
* Each Receiver and FVK SHOULD represent an Address or Full Viewing
Key at the ZIP 32 or BIP 44 Account level.
* Each UIVK SHOULD represent an Incoming Viewing Key at the Account
* Each IVK SHOULD represent an Incoming Viewing Key at the Account
level for Sapling, or its non-change child Incoming Viewing Key for
Orchard, or its non-change child extended public key for Transparent
P2PKH.
@ -503,9 +503,9 @@ 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 UFVK and UIVK
authority as for Orchard, i.e. a UFVK is intended to give access to
view all transactions to and from the address, while an UIVK is intended
New types SHOULD maintain the same distinction between FVK and IVK
authority as for Orchard, 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).
@ -551,10 +551,10 @@ addresses MUST be derived from the non-change branch of the key path at
distinct change spend authority in Orchard.
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
P2PKH IVK, 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
[#bip-0032-public-to-public]_ MUST be used. The UIVK is assumed to
[#bip-0032-public-to-public]_ MUST be used. The IVK is assumed to
be the extended public key for the non-change element of the path, and
then the Index element of the path MUST be the diversifier index
[#bip-0044-path-index]_. That is, if the UIVK was constructed correctly