Corrections for Orchard Viewing Keys.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-10-25 20:12:23 +01:00
parent 880bf02301
commit 5c402793c3
1 changed files with 35 additions and 20 deletions

View File

@ -388,12 +388,22 @@ corresponding Unified Address.
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},`
is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming
Viewing Key respectively. The UFVK uses the key at the Account level
of the ZIP 32 hierarchy, i.e. at path
:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account'`,
while the UIVK uses its non-change child key at path
* An Orchard FVK Encoding, with Typecode :math:`\mathtt{0x03},` is
a concatenation of:
* the raw encoding [#protocol-orchardfullviewingkeyencoding]_ of the
Orchard Full Viewing Key at the non-change child of the Account
level, i.e. at path
:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`;
* the raw encoding [#protocol-orchardfullviewingkeyencoding]_ of the
Orchard Full Viewing Key at the change child of the Account level,
i.e. at path
:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 1'`.
* An Orchard IVK Encoding, also with Typecode :math:`\mathtt{0x03},`
is the raw encoding [#protocol-orchardinviewingkeyencoding]_ of the
Orchard Incoming Viewing Key corresponding to the non-change child
(only) of the Account level, i.e. at path
:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`.
* A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is
@ -512,20 +522,23 @@ to give access only to view incoming payments (as opposed to change).
Deriving a UIVK from a UFVK
---------------------------
For a Sapling UFVK, the corresponding Sapling UIVK is obtained as
specified in [#protocol-saplingkeycomponents]_.
The following derivations are applied to each component FVK:
For an Orchard UFVK, the corresponding Orchard UIVK is obtained by
deriving the child UFVK with non-hardened index :math:`0`, as specified
in [#zip-0032-orchard-child-key-derivation]_, and then the UIVK as
specified in [#protocol-orchardkeycomponents]_.
* For a Sapling FVK, the corresponding Sapling IVK is obtained as
specified in [#protocol-saplingkeycomponents]_.
For a Transparent P2PKH UFVK Encoding, the UIVK Encoding is obtained
from the extended public key corresponding to the account's non-change
key path, i.e. by deriving the child key with non-hardened index :math:`0`.
It is encoded in the same way as the UFVK Encoding.
* For an Orchard FVK, the corresponding Orchard IVK is obtained by
decoding the first :math:`96` bytes of the FVK Encoding (normally
corresponding to the FVK at the non-change child of the Account level)
as an Orchard Full Viewing Key, then deriving the IVK as specified in
[#protocol-orchardkeycomponents]_.
In each case, the Typecode remains the same as in the UFVK.
* For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK
is obtained from the extended public key corresponding to the account's
non-change key path, i.e. by deriving the child key with non-hardened
index :math:`0`. It is encoded in the same way as the FVK Encoding.
In each case, the Typecode remains the same as in the FVK.
Deriving a Unified Address from a UIVK
@ -543,9 +556,9 @@ UIVK. That is,
There are no additional constraints on an Orchard diversifier index.
Note that Sapling Receiver addresses MUST be derived from the key path
Note that Sapling Receiver addresses are derived from the key path
at the Account level [#zip-0032-sapling-key-path]_, while Orchard Receiver
addresses MUST be derived from the non-change branch of the key path at
addresses are derived from the non-change branch of the key path at
:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`
[#zip-0032-orchard-key-path]_. This is to accommodate the use of a
distinct change spend authority in Orchard.
@ -564,7 +577,7 @@ then the BIP 44 path of the Transparent P2PKH Receiver will be:
Jumbling
---------
--------
Security goal (**near second preimage resistance**):
@ -814,6 +827,8 @@ References
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2020.2.16. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.3.1: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/protocol.pdf#orchardpaymentaddrencoding>`_
.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys <protocol/protocol.pdf#orchardinviewingkeyencoding>`_
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.4: Orchard Raw Full Viewing Keys <protocol/protocol.pdf#orchardfullviewingkeyencoding>`_
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
.. [#zip-0032-sapling-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys <zip-0032#sapling-extended-full-viewing-keys>`_
.. [#zip-0032-sapling-diversifier-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation <zip-0032#sapling-diversifier-derivation>`_