TRC102: Hierarchical Deterministic Wallets

[Federico2014]

TIP: 102
Title: Hierarchical Deterministic Wallets
Author: federico<federico.zhen@tron.network>
discussions-to: https://github.com/tronprotocol/tips/issues/102
status: draft
type: Standards Track
category: TRC
Created: 2019-10-22

Simple Summary

This proposal defines a mechanism for extending hierarchical deterministic wallets, as described in BIP32
and BIP44, to support both Tron's transparent and shielded addresses.

Abstract

BIP32 and BIP44 are the standard mechanism by which wallets for Bitcoin and its derivatives generate keys and addresses deterministically.
However, they only support the transparent address generation. This specification will provide support for the hierarchically shielded addresses derivation in a similar way as BIP32, which can offer users better privacy protection.

Motivation

At present, Tron network has scheduled to support the shielded addresses by ZK-SNARKs, so it is necessary to provide the standard compatibility for shielded hierarchical deterministic wallets.

Specification

In this specification, transparent address indicates the address which is public in the transaction, while the shielded address stands for the address which
is not available from the transaction.

Wallet Key Path

Existing HD wallets all use BIP44 to organize their derived keys. In order to
improve existing user experiences, we broadly follow BIP 44's design here. However, we have
altered the design where it makes sense to leverage features of shielded addresses.

m / purpose' / coin_type' / account' / transparent' / change / address_index

Apostrophe in the path indicates that BIP32 hardened derivation is used.

• m: a seed generated by the mnemonic codes to generate the master key.

• purpose: a constant set to 102' (or 0x80000066) following the BIP43 recommendation. It indicates that
  the subtree of this node is used according to this specification.

• coin_type: a constant identifying the cybercoin that this subtree's keys are used with. For Tron, coin_type is 195 as assigned in SLIP44.

• account: numbered from index 0 in sequentially increasing manner. Defined as in BIP44.

• transparent: for transparent addresses, transparent is set 1; for the shielded addresses, transparent is set 0;

• change: for transparent addresses, constant 0 is used for external chain and constant 1 for internal chain (also known as change addresses) as in BIP44;
  for shielded addresses, change field is omitted, because shielded addresses are never publicly visible in transactions.

• address_index: numbered from index 0 in sequentially increasing manner. Defined as in BIP44.

Mnemonic Codes

BIP39 should be used to derive binary seed from a mnemonic code.

We strongly recommend using 24 word mnemonic (256 bits of entropy).

Transparent Multi-Account Hierarchy for Deterministic Wallets

We adapt BIP44 for generating transparent address, except an extra transparent field is added. This is an upgrade of TIP001. We will focus on the shielded addresses derivation in the following section.

Hierarchical Derivation for Shielded Addresses

The shielded addresses derivation process described here are mainly based on the ZIP32 standard proposed by Zcash team.

Conventions

Most of the notation and functions used in this TIP are defined here for convenience:

• truncate_k(S) means the sequence formed from the first k elements of S.

• a || b means the concatenation of sequences a then b.

• [k] P means scalar multiplication of the elliptic curve point P by the scalar k.

• LEOS2IP_l (S) is the integer in range {0..2^l -1} represented in little-endian order
  by the byte sequence S of length l/8.

• I2LEBSP_l (k) is the sequence of l bits representing k in little-endian order.

• LEBS2OSP_l (B) is defined as follows when l is a multiple of 8: convert each group of 8 bits
  in B to a byte value with the least significant bit first, and concatenate the resulting bytes in the
  same order as the groups.

• repr_J (P) is the representation of the Jubjub elliptic curve point P as a bit sequence.

• BLAKE2b-256(p, x) refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of
  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.

• PRF^expand (sk, t) := BLAKE2b-512("Tron_ExpandSeed", sk || t )

• ToScalar(x) := LEOS2IP₅₁₂ (x) (mod r_J ), where r_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
  diversifier is invalid.

The following FPE algorithm standardized is used:

• FF1-AES256.Encrypt(key, tweak, x) refers to the FF1 encryption algorithm using AES with a
  256-bit key, and parameters radix = 2, minlen = 88, maxlen = 88. It will be used only with
  the empty string "" as the tweak. x is a sequence of 88 bits, as is the output.

We also define the following conversion function:

• I2LEOSP_l (k) is the byte sequence S of length l/8 representing in little-endian order the
  integer k in range {0..2^l -1}. It is the reverse operation of LEOS2IP_l (S).

We adapt the path notation of BIP32 to describe shielded HD paths, using apostrophes to
indicate hardened derivation (i' = i + 2³¹ ) as in BIP44:

• CDKsk(CDKsk(CDKsk(m, a'), b), c) is written as m / a' / b / c
• CDKfvk(CDKfvk(CDKfvk(M, a), b), c) is written as M / a / b / c

Specification: Key Derivation

Extended Keys

BIP 32 defines a method to derive a number of child keys from a parent key. In order to prevent these from
depending solely on the parent key itself, both the private and public keys are extended with a 32-byte chain
code. We similarly extend Sapling keys with a chain code here. However, the concepts of "private" and "public"
keys in BIP 32 do not map cleanly to shielded key components. We take the following approach:

• We derive child expanded spending keys, rather than spending keys. This enables us to
  implement both hardened and non-hardened derivation modes.

• We do not derive public keys directly, as this would prevent the use of diversified addresses.
  Instead, we derive 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 full viewing key also enables.

We represent a extended spending key as (ask, nsk, ovk, dk, c), where (ask, nsk, ovk)
is the normal expanded spending key, dk is a diversifier key, and c is the chain code.

We represent a extended full viewing key as (ak, nk, ovk, dk, c), where (ak, nk, ovk)
is the normal full viewing key, dk is the same diversifier key as above, and c is the chain code.

The helper functions

Define EncodeExtSKParts(ask, nsk, ovk, dk) := I2LEOSP₂₅₆ (ask) || I2LEOSP₂₅₆ (nsk) || ovk || dk.

Define EncodeExtFVKParts(ak, nk, ovk, dk) := LEBS2OSP₂₅₆ (repr_J (ak)) || LEBS2OSP₂₅₆ (repr_J (nk)) || ovk || dk.

Master Key Generation

Let path_i= m / xx' / 195' / i' / 0', i denotes the i-th account. Let sk_pathi, pk_pathi, c_pathi
denotes the private key, public key and chain code at path_i derived by BIP32.

• Calculate I = BLAKE2b-512 ("TronIP102", sk_pathi || pk_pathi || c_pathi ).

• Split I into two 32-byte sequences, I_L and I_R .

• Use I_L as the master spending key sk_m , and I_R as the master chain code
  c_m.

• Calculate ask_m , nsk_m , and ovk_m via the standard derivation function:

  • ask_m = ToScalar(PRF^expand (sk_m , [0x00]))
  • nsk_m = ToScalar(PRF^expand (sk_m , [0x01]))
  • ovk_m = truncate₃₂ (PRF^expand (sk_m , [0x02]))

• Calculate dk_m similarly:

  • dk_m = truncate₃₂ (PRF^expand (sk_m , [0x10]))

• Return (ask_m , nsk_m , ovk_m , dk_m , c_m ) as the
  master extended spending key m.

Child Key Derivation

As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index i,
depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.

Deriving a child extended spending key

CDKsk((ask_par , nsk_par , ovk_par , dk_par , c_par ), i) →
(ask_i , nsk_i , ovk_i , dk_i , c_i )

• Check whether i ≥ 2³¹ (whether the child is a hardened key).

  • If so (hardened child): let I = PRF^expand (c_par , [0x11] || EncodeExtSKParts(ask_par , nsk_par , ovk_par , dk_par ) || I2LEOSP₃₂ (i))
  • If not (normal child): let I = PRF^expand (c_par , [0x12] || EncodeExtFVKParts(ak_par , nk_par , ovk_par , dk_par ) || I2LEOSP₃₂ (i))
    where (nk_par , ak_par , ovk_par ) is the full viewing key derived from
    (ask_par , nsk_par , ovk_par ).

• Split I into two 32-byte sequences, I_L and I_R .

• Let I_ask = ToScalar(PRF^expand (I_L , [0x13]))

• Let I_nsk = ToScalar(PRF^expand (I_L , [0x14]))

• Return:

  • ask_i = I_ask + ask_par
  • nsk_i = I_nsk + nsk_par
  • ovk_i = truncate₃₂ (PRF^expand (I_L , [0x15] || ovk_par ))
  • dk_i = truncate₃₂ (PRF^expand (I_L , [0x16] || dk_par ))
  • c_i = I_R

Deriving a child extended full viewing key

Let G and H be the base point in elliptic curve.

CDKfvk((ak_par , nk_par , ovk_par , dk_par , c_par ), i) →
(ak_i , nk_i , ovk_i , dk_i , c_i )

• Check whether i ≥ 2³¹ (whether the child is a hardened key).

  • If so (hardened child): return failure
  • If not (normal child): let I = PRF^expand (c_par , [0x12] || EncodeExtFVKParts(ak_par , nk_par , ovk_par , dk_par ) || I2LEOSP₃₂ (i))

• Split I into two 32-byte sequences, I_L and I_R .

• Let I_ask = ToScalar(PRF^expand (I_L , [0x13]))

• Let I_nsk = ToScalar(PRF^expand (I_L , [0x14]))

• Return:

  • ak_i = [I_ask] G + ak_par
  • nk_i = [I_nsk] H + nk_par
  • ovk_i = truncate₃₂ (PRF^expand (I_L , [0x15] || ovk_par ))
  • dk_i = truncate₃₂ (PRF^expand (I_L , [0x16] || dk_par ))
  • c_i = I_R

Diversifier derivation

The 88-bit diversifiers for a extended key are derived from its diversifier key dk. 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. In order to reach the
maximum possible diversifier range without running into repetitions due to the birthday bound, we use
FF1-AES256 as a Pseudo-Random Permutation as follows:

• Let j be the index of the desired diversifier, in the range 0 .. 2⁸⁸ -1.
• d_j = FF1-AES256.Encrypt(dk, "", I2LEBSP₈₈ (j)).

A valid diversifier d_j is one for which DiversifyHash(d_j) ≠ ⊥.
For a given dk, approximately half of the possible values of j yield valid diversifiers.

The default diversifier for an extended key is defined to be d_j , where j is the
least nonnegative integer yielding a valid diversifier.

Fingerprints and Tags

Full Viewing Key Fingerprints and Tags

A full viewing key fingerprint with raw encoding FVK is given by:

BLAKE2b-256("TronFVFP", FVK)

It MAY be used to uniquely identify a particular full viewing key.

A "full viewing key tag" is the first 4 bytes of the corresponding full viewing key
fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to
uniquely identify a particular key.

Key Encodings

The following encodings are analogous to the xprv and xpub encodings defined
in BIP 32 for transparent keys and addresses. Each key type has a raw representation
and a Bech32 encoding.

Extended Spending Keys

An extended spending key (ask, nsk, ovk, dk, c), at some path,
with parent full viewing key tag parent_fvk_tag and child number i, is
represented as a byte sequence:

I2LEOSP₈ (depth) || parent_fvk_tag || I2LEOSP₃₂ (i) || c || EncodeExtSKParts(ask, nsk, ovk, dk)

For the master extended spending key, depth is 0, parent_fvk_tag is 4 zero bytes,
and i is 0.

When encoded as Bech32, the Human-Readable Part is secret-extended-key-main
for the production network, or secret-extended-key-test for the test network.

Extended full viewing keys

A extended full viewing key (ak, nk, ovk, dk, c), at depth depth,
with parent full viewing key tag parent_fvk_tag and child number i, is
represented as a byte sequence:

I2LEOSP₈ (depth) || parent_fvk_tag || I2LEOSP₃₂ (i) || c || EncodeExtFVKParts(ak, nk, ovk, dk)

For the master extended full viewing key, depth is 0, parent_fvk_tag is 4 zero bytes,
and i is 0.

When encoded as Bech32, the Human-Readable Part is txviews for the production
network, or txviewtest for the test network.

Rationale

Based on BIP32, BIP44 and ZIP32, We provide a standard mechanism for both transparent and shielded hierarchical deterministic wallets for Tron.

Implementation

None

Reference

• https://pypi.org/project/bip32utils/
• https://github.com/NovaCrypto/BIP44
• https://github.com/zcash/zips/blob/master/zip-0032.rst
• https://github.com/zcash-hackworks/zip32
• ZIP 32 APIs zcash/librustzcash#29

[Rovak]

Add https://github.com/zcash/zips/blob/master/zip-0032.rst as a reference because that is where most of the text is copied from

[Federico2014]

Add https://github.com/zcash/zips/blob/master/zip-0032.rst as a reference because that is where most of the text is copied from

We have provided the reference zip32 in the text. The main difference lies in the the wallet key path and master key generation.

[ha1i1uya]

Will this HD wallet initially be used on wallet-cli ？and when will it be realized?

[Federico2014]

Will this HD wallet initially be used on wallet-cli ？and when will it be realized?
This TIP is currently still a draft and will be realized after comprehensive discussion.