[ZIP 32] Shielded Hierarchical Deterministic Wallets #157

str4d · 2018-05-30T08:10:28Z

No description provided.

daira · 2018-05-30T10:25:37Z

zip-0032.rst

+
+- *a* || *b* means the concatenation of sequences *a* then *b*.
+
+- [*k*] *P* means scalar multiplication in the group *P*.


scalar multiplication of the (elliptic curve) group element P by the scalar k.

daira · 2018-05-30T10:27:45Z

zip-0032.rst

+- BLAKE2b-512(*p*, *x*) refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64
+  bytes, 16-byte personalization string *p*, and input *x*.
+
+- PRF\ :sup:`expand`\ (*sk, t*) := BLAKE2b-512("Zcash_ExpandSeed", *sk* || *t*)


Nitpick: *sk*, *t* (the comma should not be in italic :-) )

daira · 2018-05-30T10:43:00Z

zip-0032.rst

+- We do not derive Sapling public keys directly, as this would prevent the use of diversified addresses.
+  Instead, we derive Sapling full viewing keys, from which payment addresses can be generated. This maintains
+  the trust semantics of BIP 32: someone with access to a BIP 32 extended public key is able to view all
+  transactions involving that address, which a Sapling full viewing key also enables.


With hindsight, it would have been useful to support an "address derivation key" which allows creating (and linking) diversified addresses but without being able to decrypt notes sent to them. I don't see a way to do this with Sapling's current key derivation structure, though. We should consider this issue for the next circuit upgrade — at which time we'll have more experience with diversified addresses.

(Aside: Sapling payment addresses were intentionally made not to be "rediversifiable" –i.e. it is not possible to create one diversified address directly from another– as part of preventing Brian Warner's attack in which a note for one address is encrypted to a different address in order to attempt to link them. But that attack does not preclude support for an address derivation key, because we would not be trying to prevent linking of addresses given this key.)

daira · 2018-05-30T10:45:48Z

zip-0032.rst

+Specification: Sprout key derivation
+====================================
+
+For completeness, we define a system for deriving a tree of Sprout keys components. It is unlikely that this


s/key/keys/

daira · 2018-05-30T10:50:39Z

zip-0032.rst

+
+- ``coin_type``: a constant identifying the cybercoin that this subtree's keys are used with. For
+  compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44
+  [#slip-0044]_.


Add a note that all testnets share coin_type index 1.

daira · 2018-05-30T12:48:00Z

zip-0032.rst

+
+Unlike BIP 44, neither Sprout nor Sapling have a `change` path level. This is because 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.


This only makes sense if you already know that the motivation for using separate change addresses in Bitcoin was to attempt to improve privacy.

daira · 2018-05-30T12:53:38Z

zip-0032.rst

+Wallets MUST support generating the default payment address (corresponding to the default diversifier). They
+MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the
+user experience of giving a unique address to each recipient. Note that a given account can have a maximum of
+2\ :sup:`88` payment addresses.


We need some discussion of diversifier collisions here. If wallet implementors attempt to do this in the most obvious way, they will start to hit collisions after ~2⁴⁴ (or fewer, with lower probability) addresses. Should we define a PRP-based derivation method?

Correction: ~2^43.5 (because half of diversifiers are invalid). And the maximum number is 2⁸⁷.

str4d · 2018-06-20T11:09:33Z

@daira and I had a pairing to figure out how to derive pseudo-random diversifiers without hitting the 2⁴⁴ birthday bound on collisions, by using a PRP. We've decided to use FFX-A2 ~~(as being considered by NIST)~~, with 88-bit messages and the zero-length byte string as tweak. The one additional change we are making is to use 256-bit AES keys (matching the rest of the key material); ~~as the key size is not technically a tunable parameter within the A2 parameter set, we will refer to this as FFX-AES256-A2.~~ EDIT: NIST standardised this in SP 800-38G as FF1-AES256.

str4d · 2018-07-05T16:17:44Z

zip-0032.rst

@@ -199,7 +199,7 @@ The 88-bit diversifiers for a Sapling extended key are derived from its diversif
 In order to reach the maximum possible diversifier range without running into the birthday bound, we use
 FF1-AES256 as a Pseudo-Random Permutation as follows:

- Let *j* be the index of the desired diversifier.
+- Let *j* be the index of the desired diversifier, in the range 0 .. 2\ :sup:`88`\ -1.
 - *d*\ :sub:`i,j` = FF1-AES256.Encrypt(*dk*\ :sub:`i`\ , "", I2LEBSP\ :sub:`88`\ (*j*))

 The default diversifier for a Sapling extended key is defined to be *d*\ :sub:`i,0`\ .


Hmm, we need to be clearer here: it's not simply j = 0, but the first j that results in a valid diversifier.

str4d · 2018-07-05T16:20:16Z

zip-0032.rst

+  32 bytes, 16-byte personalization string *p*, and input *x*.
+
+- BLAKE2b-512(*p*, *x*) refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of
+  64 bytes, 16-byte personalization string *p*, and input *x*.


Hmm, does unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64 bytes (and likewise for BLAKE2b-256) convey the correct meaning? We want to indicate that the only difference between the two is the digest length (so maybe unkeyed BLAKE2b in [...], but that it is not the same thing as truncating (so maybe we need more than output digest length).

This is the same wording as in the protocol spec, and I believe it's unambiguous.

zip-0032.rst

str4d · 2018-07-05T16:26:41Z

zip-0032.rst

+parent address tag *parent_addr_tag* and child number *i*, is represented as a
+byte sequence::
+
+    I2LEOSP\ :sub:`8`\ (*depth*) || *parent_addr_tag* || I2LEOSP\ :sub:`32`\ (*i*) || *ASK* || *c*


Put ASK after c to match the Sapling encodings.

Note that this means they are encoded in little-endian order, which is the opposite of BIP 32.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Hardened derivation is undefined for an extended FVK

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

…rent addresses. Signed-off-by: Daira Hopwood <daira@jacaranda.org>

arielgabizon · 2018-08-14T16:46:58Z

zip-0032.rst

+.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
+.. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
+.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
+.. [#sapling-spec] `Zcash Protocol Specification, Version 2018.0-beta-21 or later [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/sapling.pdf>`_


update these links to protocol.pdf

The filename changes weren't made until 2018.0-beta-25. But it's correct to update it to protocol.pdf if the version is changed to be later than that.

arielgabizon · 2018-08-14T16:48:31Z

zip-0032.rst

+  - *dk*\ :sub:`i` = truncate\ :sub:`32`\ (PRF\ :sup:`expand`\ (*I*\ :sub:`L`\ , [0x16] || *dk*\ :sub:`par`\ ))
+  - *c*\ :sub:`i` = *I*\ :sub:`R`
+
+Deriving a child extended full viewing key


Change to "Deriving a normal child extended full viewing key from a parent extended full viewing key"?

Isn't this implied? The subheading above it doesn't say "Deriving a child extended spending key from a parent extended spending key".

arielgabizon · 2018-08-14T16:49:10Z

zip-0032.rst

+  - *dk*\ :sub:`i` = truncate\ :sub:`32`\ (PRF\ :sup:`expand`\ (*I*\ :sub:`L`\ , [0x16] || *dk*\ :sub:`par`\ ))
+  - *c*\ :sub:`i` = *I*\ :sub:`R`
+
+Diversifier derivation


dk seems better than dk_i in this section

Only if d_i,j is also changed to d_j.

zip-0032.rst

arielgabizon · 2018-08-14T16:52:25Z

zip-0032.rst

+
+    m_Sapling / purpose' / coin_type' / account'
+
+Wallets MUST support generating the default payment address (corresponding to the default diversifier). They


perhaps add 'as defined above' after 'default diversifier'

In summary to discussions, would change sentence to
"Furthermore, Wallets MUST support generating the default payment address (corresponding to the default diversifier as defined above) for any account they support".

arielgabizon · 2018-08-14T16:59:32Z

zip-0032.rst

+- ToScalar(*x*) := LEOS2IP\ :sub:`512`\ (*x*) (mod *r*\ :sub:`J`\ ), where *r*\ :sub:`J` \ is the order
+  of the Jubjub large prime subgroup.
+
+- DiversifyHash(*d*) maps a diversifier *d* to a base point on the Jubjub elliptic curve, or to ⊥ if the


perhaps add 'prime order subgroup' after 'elliptic curve'

arielgabizon · 2018-08-14T17:00:35Z

zip-0032.rst

+
+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 Sapling
+ZIP 32 derivation MUST support the following path::


add 'for any account' in {0,..,2^31-1}' ?

arielgabizon · 2018-08-14T17:11:47Z

zip-0032.rst

+- Use *I*\ :sub:`L` as the master spending key *sk*\ :sub:`m`\ , and *I*\ :sub:`R` as the master chain code
+  *c*\ :sub:`m`\ .
+- Calculate the master extended spending key *m*\ :sub:`Sapling` = (*ask*\ :sub:`m`\ , *nsk*\ :sub:`m`\ ,
+  *ovk*\ :sub:`m`\ , *dk*\ :sub:`m`\ , *c*\ :sub:`m`\ ) via the standard Sapling derivation


via -> similarly - cause dk isn't in the Sapling derivation

arielgabizon · 2018-08-23T14:59:33Z

zip-0032.rst

+----------------------
+
+The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key *dk*\ :sub:`i`\ .
+In order to reach the maximum possible diversifier range without running into the birthday bound, we use


Could you elaborate about what you mean 'running into the birthday problem'? I think you mean also you want to get some independence of diversifier sequences of different base keys. If I just want no collisions, I could define d_{i,j} = j.

Yes, diversifiers should follow an independent random sequence for each ivk. Otherwise, the diversifier leaks information about how many previous diversifiers were obtained from that ivk.

That makes sense, this should be explained though.. added two new comments with suggested phrasings.

…xpanded'.

ebfull · 2018-09-10T18:59:33Z

My ACK is to indicate that I approve of the design -- though I would personally have advocated against specifying a Sprout key derivation model. Also, I think it may be worth mentioning the security properties like BIP32 does. (We should indicate that using the same seed byte sequence for master key derivation in BIP32 and ZIP32 is fine, even though it may be obvious to some.)

I'm confused about how this document progresses through the ZIP process, and whether we're supposed to label this as a draft or not. Do we not merge until we have test vectors and the spec is complete?

arielgabizon · 2018-09-18T14:25:58Z

zip-0032.rst

@@ -329,7 +329,7 @@ relevant transactions.

 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 Sapling
-ZIP 32 derivation MUST support the following path::
+ZIP 32 derivation MUST support the following path for any account in range {0..2\ :sup:`31`\ -1}::


account -> account'

Account is already defined earlier up as hardened, so the meaning here is clear enough.

(and account is in range 0..2^31-1, while account' is technically in range 2^31..2^32-1 which doesn't read as easily)

arielgabizon · 2018-09-18T19:19:45Z

zip-0032.rst

+----------------------
+
+The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key *dk*.
+In order to reach the maximum possible diversifier range without running into the birthday bound, we use


"without running into the birthday bound," --> "without running into repetitions due to the birthday bound,".

arielgabizon · 2018-09-18T19:30:15Z

zip-0032.rst

+Diversifier derivation
+----------------------
+
+The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key *dk*.


Add after sentence "To prevent the diversifier leaking how many diversified addresses have already been generated for an account; we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account."

daira reviewed May 30, 2018

View reviewed changes

str4d force-pushed the zip-0032 branch 4 times, most recently from 18b1bc6 to 96a829b Compare June 8, 2018 02:53

daira changed the title ~~ZIP 32: Shielded Hierarchical Deterministic Wallets~~ [ZIP 32] Shielded Hierarchical Deterministic Wallets Jun 10, 2018

daira force-pushed the zip-0032 branch 2 times, most recently from a69ef8c to 30493b3 Compare July 5, 2018 16:11

str4d commented Jul 5, 2018

View reviewed changes

daira force-pushed the zip-0032 branch 2 times, most recently from f78fa32 to 1824b3d Compare July 6, 2018 12:50

daira mentioned this pull request Jul 10, 2018

[ZIP 32] Specify BIP32 for Zcash zcash/zcash#2320

Closed

str4d and others added 17 commits July 25, 2018 00:32

ZIP 32: Shielded Hierarchical Deterministic Wallets

9a87098

Address Daira's comments

a5309ed

Use byte sequences for constant single-byte inputs to PRF_expand

4ed0316

Define a diversifier key dk

c73733a

Fix usage of LEOS2IP in definition of ToScalar

aa36706

Define I2LEOSP_l(k) and use it to encode the child key indices

efd68a4

Note that this means they are encoded in little-endian order, which is the opposite of BIP 32.

Define how to derive diversifiers from Sapling extended keys

f07b6d2

Note that ZIP 32 is consistently little-endian

a01dbbb

ZIP 32: use FF1-AES256 as the PRP.

9596aed

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Remove hardening from example public-key HD path

da683d3

Hardened derivation is undefined for an extended FVK

Cosmetic improvements.

3f28158

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Reference version 2018.0-beta-21 or later of the Sapling protocol spec.

1b3ea42

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Define r_J.

f94b9a4

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Cosmetics.

ff5affb

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Update another reference to the Sapling spec version.

de065cf

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Cosmetics.

8a49de8

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

Say that ZIP 32 does not supplant the use of BIPs 32 & 44 for transpa…

b3c051e

…rent addresses. Signed-off-by: Daira Hopwood <daira@jacaranda.org>

daira force-pushed the zip-0032 branch from 7f959cd to 813a889 Compare July 25, 2018 13:53

arielgabizon reviewed Aug 14, 2018

View reviewed changes

zip-0032.rst Show resolved Hide resolved

arielgabizon reviewed Aug 14, 2018

View reviewed changes

arielgabizon reviewed Aug 23, 2018

View reviewed changes

daira added 3 commits September 1, 2018 18:36

Use the same notation for r_J as the spec.

2aee30c

Don't use 'X' to abbreviate 'extended', since it is ambiguous with 'e…

08b8427

…xpanded'.

Add specification for seed fingerprints.

2eec56d

ebfull approved these changes Sep 10, 2018

View reviewed changes

str4d added 6 commits September 18, 2018 11:25

Clarify wording about default payment addresses

55e3cd1

Pull in definition of hardened notation

a414e4e

Clarify that dk is not part of the standard Sapling derivation

1f7b512

dk_i -> dk in "Diversifier derivation" section

44e9c03

Be explicit about supported range for the Sapling key path

606abd1

Update references to Sapling protocol spec

888681c

arielgabizon reviewed Sep 18, 2018

View reviewed changes

arielgabizon and others added 2 commits September 20, 2018 12:11

Improve explanation of diversifier sequence choice

cb1e663

Formatting

975a2aa

str4d force-pushed the zip-0032 branch from d1db943 to 975a2aa Compare September 20, 2018 10:05

arielgabizon approved these changes Sep 20, 2018

View reviewed changes

daira merged commit f6f47a0 into zcash:master Oct 5, 2018

str4d deleted the zip-0032 branch November 3, 2022 09:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ZIP 32] Shielded Hierarchical Deterministic Wallets #157

[ZIP 32] Shielded Hierarchical Deterministic Wallets #157

str4d commented May 30, 2018

daira May 30, 2018

daira May 30, 2018

daira May 30, 2018

daira May 30, 2018

daira May 30, 2018

daira May 30, 2018

daira May 30, 2018

daira Jun 1, 2018

str4d commented Jun 20, 2018 •

edited

str4d Jul 5, 2018

str4d Jul 5, 2018

daira Jul 6, 2018

str4d Jul 5, 2018

arielgabizon Aug 14, 2018

daira Aug 30, 2018

arielgabizon Aug 14, 2018

daira Aug 30, 2018

arielgabizon Aug 14, 2018 •

edited

daira Aug 30, 2018

arielgabizon Aug 14, 2018

arielgabizon Sep 18, 2018

arielgabizon Aug 14, 2018

arielgabizon Aug 14, 2018

arielgabizon Aug 14, 2018 •

edited

arielgabizon Aug 23, 2018

daira Sep 18, 2018

arielgabizon Sep 18, 2018

ebfull commented Sep 10, 2018

arielgabizon Sep 18, 2018

str4d Sep 18, 2018

str4d Sep 18, 2018

arielgabizon Sep 18, 2018

arielgabizon Sep 18, 2018

arielgabizon Sep 18, 2018


		- a \|\| b means the concatenation of sequences a then b.

		- [k] P means scalar multiplication in the group P.


		m_Sapling / purpose' / coin_type' / account'

		Wallets MUST support generating the default payment address (corresponding to the default diversifier). They

[ZIP 32] Shielded Hierarchical Deterministic Wallets #157

[ZIP 32] Shielded Hierarchical Deterministic Wallets #157

Conversation

str4d commented May 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

str4d commented Jun 20, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielgabizon Aug 14, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arielgabizon Aug 14, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebfull commented Sep 10, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

str4d commented Jun 20, 2018 •

edited

arielgabizon Aug 14, 2018 •

edited

arielgabizon Aug 14, 2018 •

edited