mirror of https://github.com/zcash/zips.git
ZIPs 32 and 316: refine how UIVK components are derived for Orchard and Transparent P2PKH.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
4d536ff421
commit
4d0477ce5f
50
zip-0032.rst
50
zip-0032.rst
|
|
@ -384,6 +384,10 @@ valid diversifiers.
|
|||
|
||||
The default diversifier for :math:`(\mathsf{sk}_i, \mathsf{c}_i)` is defined to be :math:`d_{i,0}.`
|
||||
|
||||
Although the diversifier *key* is derived from the full viewing key which is at the Account level, the
|
||||
resulting diversified addresses are derived from the key at the non-change child of that level, as described
|
||||
in `Orchard key path`_ below.
|
||||
|
||||
|
||||
Specification: Wallet usage
|
||||
===========================
|
||||
|
|
@ -409,11 +413,18 @@ hardened derivation:
|
|||
- :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in
|
||||
BIP 44 [#bip-0044]_.
|
||||
|
||||
Unlike BIP 44, none of the shielded key paths have a :math:`change` path level. The use of change addresses
|
||||
in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by
|
||||
segregating external and internal address usage. Shielded addresses are never publicly visible in
|
||||
transactions, which means that sending change back to the originating address is indistinguishable from
|
||||
using a change address.
|
||||
In BIP 44, there is also a :math:`change` unhardened path level as a child of :math:`account`. This
|
||||
level is not present in the Sprout and Sapling key paths. It *is* present in Orchard, but as a hardened
|
||||
path level.
|
||||
|
||||
The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users
|
||||
on the transaction graph, by segregating external and internal address usage. For Sprout and Sapling, it
|
||||
was reasoned that shielded addresses are never publicly visible in transactions, and so sending change
|
||||
back to the originating address would be indistinguishable from using a change address. However, this
|
||||
reasoning does not apply if we give out incoming viewing keys, and so for Orchard the :math:`change`
|
||||
level has been reintroduced. This ensures that an Orchard incoming viewing key will only be able to view
|
||||
incoming payments, not incoming change, which was deemed to be more useful for anticipated applications
|
||||
of incoming viewing keys (such as a merchant terminal or a charity donation address).
|
||||
|
||||
Sapling key path
|
||||
----------------
|
||||
|
|
@ -455,20 +466,27 @@ Wallets implementing Sprout ZIP 32 derivation MUST support the following path:
|
|||
Orchard key path
|
||||
----------------
|
||||
|
||||
Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such
|
||||
addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable
|
||||
addresses as needed does not increase the cost of scanning the block chain for relevant transactions.
|
||||
Orchard supports diversified addresses with the same spending authority (like Sapling). Unlike Sapling and
|
||||
Sprout, we reintroduce the :math:`change'` level of the key path, so that the spending authorities generated
|
||||
for incoming payments and for change are distinct. The motivation for this distinction is to allow giving
|
||||
out an incoming viewing key that is only able to see incoming payments, and not incoming change.
|
||||
|
||||
The above key path levels include an account identifier, which in all user interfaces is represented as a
|
||||
"bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard
|
||||
ZIP 32 derivation MUST support the following path for any account in range :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
|
||||
A group of diversified addresses with the same spending authority shares the same full viewing key and incoming
|
||||
viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning
|
||||
the block chain for relevant transactions.
|
||||
|
||||
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`.
|
||||
The key path levels include an account identifier, which in all user interfaces should be represented as
|
||||
a "bucket of funds" under the control of a single spending authority. Wallets implementing Orchard ZIP 32
|
||||
derivation MUST support the following two paths for any account in range :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
|
||||
|
||||
Furthermore, wallets MUST support generating the default payment address (corresponding to the default
|
||||
diversifier for Orchard) for any account they support. They MAY also support generating a stream of
|
||||
diversified payment addresses for a given account, if they wish to enable users to give a unique address to
|
||||
each recipient.
|
||||
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 0'` (for incoming payments);
|
||||
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 1'` (for change).
|
||||
|
||||
Furthermore, wallets MUST support generating a default payment address and a default change address (each
|
||||
corresponding to the default diversifier for Orchard) for any account they support. They MAY also support
|
||||
generating a stream of diversified payment addresses (based on the non-change key path) for a given account,
|
||||
if they wish to enable users to give a unique address to each recipient. A single address using the default
|
||||
diversifier SHOULD be used for change.
|
||||
|
||||
Note that a given account can have a maximum of :math:`2^{88}` payment addresses (unlike Sapling, all Orchard
|
||||
diversifiers are valid).
|
||||
|
|
|
|||
74
zip-0316.rst
74
zip-0316.rst
|
|
@ -390,15 +390,22 @@ The following UFVK or UIVK Encodings are used in place of the
|
|||
|
||||
* 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.
|
||||
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
|
||||
:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`.
|
||||
|
||||
* A Sapling UFVK Encoding, with Typecode :math:`\mathtt{0x02},` is
|
||||
the encoding of a Sapling Extended Full Viewing Key defined in
|
||||
[#zip-0032-sapling-extfvk]_.
|
||||
[#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},`
|
||||
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.
|
||||
|
||||
* 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
|
||||
|
|
@ -408,9 +415,14 @@ The following UFVK or UIVK Encodings are used in place of the
|
|||
|
||||
* For Transparent P2PKH Addresses that are derived according to BIP 32
|
||||
[#bip-0032]_ and BIP 44 [#bip-0044]_, the UFVK and UIVK Encodings
|
||||
have Typecode :math:`\mathtt{0x00}.` These encodings are identical
|
||||
and are the serialization of an extended public key, defined in the
|
||||
section “Serialization format” of BIP 32 [#bip-0032-serialization-format]_.
|
||||
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
|
||||
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.)
|
||||
|
||||
The Human-Readable Parts (as defined in [#bip-0350]_) of Unified Viewing
|
||||
Keys are defined as follows:
|
||||
|
|
@ -437,8 +449,13 @@ 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, UFVK, or UIVK SHOULD represent an Address or
|
||||
Viewing Key at the ZIP 32 or BIP 44 Account level.
|
||||
* Each Receiver and UFVK 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
|
||||
level for Sapling, or its non-change child Incoming Viewing Key for
|
||||
Orchard, or its non-change child extended public key for Transparent
|
||||
P2PKH.
|
||||
|
||||
* For Transparent Addresses, the Receiver Encoding does not include
|
||||
the first two bytes of a raw encoding.
|
||||
|
|
@ -486,14 +503,29 @@ 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
|
||||
to give access only to view incoming payments (as opposed to change).
|
||||
|
||||
|
||||
Deriving a UIVK from a UFVK
|
||||
---------------------------
|
||||
|
||||
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.
|
||||
For a Sapling UFVK, the corresponding Sapling UIVK is obtained as
|
||||
specified in [#protocol-saplingkeycomponents]_.
|
||||
|
||||
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 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.
|
||||
|
||||
In each case, the Typecode remains the same as in the UFVK.
|
||||
|
||||
|
||||
Deriving a Unified Address from a UIVK
|
||||
|
|
@ -511,6 +543,13 @@ 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
|
||||
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
|
||||
: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.
|
||||
|
||||
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
|
||||
|
|
@ -768,13 +807,18 @@ References
|
|||
==========
|
||||
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal] <protocol/protocol.pdf>`_
|
||||
.. [#protocol-notation] `Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal]. Section 2: Notation <protocol/protocol.pdf#notation>`_
|
||||
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
|
||||
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/protocol.pdf#orchardpaymentaddrencoding>`_
|
||||
.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.2.16 or later [NU5 proposal] <protocol/protocol.pdf>`_
|
||||
.. [#protocol-notation] `Zcash Protocol Specification, Version 2020.2.16. Section 2: Notation <protocol/protocol.pdf#notation>`_
|
||||
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.2.16. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
|
||||
.. [#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>`_
|
||||
.. [#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>`_
|
||||
.. [#zip-0032-orchard-child-key-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation <zip-0032#orchard-child-key-derivation>`_
|
||||
.. [#zip-0032-sapling-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path <zip-0032#sapling-key-path>`_
|
||||
.. [#zip-0032-orchard-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path <zip-0032#orchard-key-path>`_
|
||||
.. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool <zip-0211.rst>`_
|
||||
.. [#zip-0224] `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`_
|
||||
.. [#zip-0321] `ZIP 321: Payment Request URIs <zip-0321.rst>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue