DIP: 0013 Title: Identities in Hierarchical Deterministic Wallets Author(s): Samuel Westrich Special-Thanks: Eric Britten, Thephez Comments-Summary: No comments yet. Status: Proposed Type: Informational Created: 2020-11-25 License: MIT License
- Abstract
- Motivation
- Prior Work
- Identities
- Identity Feature Path with Sub Features
- Identity Authentication keys
- Identity Registration Funding keys
- Identity Top Up Funding keys
- Copyright
This document details the recommended approach of implementing Dash identities in Hierarchical Deterministic wallets. If this approach is followed it will lead to interoperability between wallets.
Dash identities use keys. From a consensus level, the sole requirement on keys when registering a Dash identity is that they are valid. Hierarchical Deterministic (HD) wallets allow for keys to be deterministically derived from a seed. This proposal seeks to use the keys derived from a wallet seed for identities and hence allow identities to be recoverable from a user's mnemonic. Users then won't need to secure the individual keys of their identity, instead all they will need to do is to keep access to their mnemonic.
- BIP-0032: Hierarchical Deterministic Wallets
- DIP-0009: Coin Specific Feature Derivation Paths
- DIP-0011: Identities
Dash Improvement Proposal 11 details the requirements for the creation and uptake of identities, as well as their usage. For example, that when a Dash identity is created keys should be provided. While these keys can be non-derived and included in a sort of wallet file, this does not offer the same ease of use as providing the user with a recovery phrase from which all wallet info can be retrieved.
Identities should represent a persona. While wallets can support multiple identities, this should only be done when an individual wishes to separate their various personas. For example a work persona, a personal persona and a gamer persona.
BIP32 introduced derivation paths for keys. BIP43 introduced a purpose field and DIP9 introduced a feature field that was coin specific.
We can therefore define the following root levels for identity features.
m / purpose' / coin_type' / feature' / sub feature' /
The apostrophe signifies hardened paths as defined in BIP32.
Feature will be set to 5' for all Dash identity related keys.
Identity Authentication keys are the first sub-feature for identities.
We define the following levels for authentication keys:
m / purpose' / coin_type' / feature' / sub feature' / key type' / identity index' / key index'
Sub feature is set to 0'.
The following key types are valid:
0' - ECDSA keys based on the secp256k1 curve as defined here:
http://www.secg.org/sec2-v2.pdf
1' - BLS keys based on the bls12381 curve as defined here:
https://github.com/dashpay/bls-signatures/blob/dash/SPEC.md
Each wallet can have multiple identities defined by their respective index number. Let's assume that
all identities are being registered with ECDSA keys in the following sentences. The derivation path
of the first identity would therefore be m/9'/5'/5'/0'/0'/0'/0'. If that identity would want to
change to or add another key they would use m/9'/5'/5'/0'/0'/0'/1'. The second identity in the
wallet would use m/9'/5'/5'/0'/0'/1'/0' and their second ECDSA key would be
m/9'/5'/5'/0'/0'/1'/1'. Identity authentication keys should always be used sequentially.
Hardened keys are used since keys used for authentication might be used at varying security levels. If one key is compromised it is essential that not all keys are compromised as could potentially be the case with non-hardened keys.
Identity Funding keys can either be for a registration or for a topup. We will create for each wallet two sets of secp256k1 keys. Funding transactions using these keys will be perceived as identical on the network. However by separating these keys based on two derivation paths, wallets can keep track of the motivation behind each credit funding transaction.
Identity Funding keys used for registration are the second sub-feature for identities. They are always derived as ECDSA keys.
We define the following levels for them:
m / purpose' / coin_type' / feature' / sub feature' / identity index
Sub feature is set to 1'.
As there can only be one registration funding per identity, there is no point to derive a level deeper.
The index of the identity for funding need not be the same as the index used in authentication keys. The relationship between the two can be retrieved in information from Dash Platform upon successful identity registration.
If a wallet recovers a registration funding transaction without an associated identity using this funding, the wallet can safely assume that the identity was either in the process of being registered when an error occurred or the process was terminated by the user. The wallet should offer the user the ability to resume the process.
It is recommended that five address hashes of these keys be added to the bloom filter sent to peers. If four identities have been found, the filter should be regenerated with five more. Address hashes must use HASH160 of the public key which is one round of SHA256 followed by one round of RIPEMD160.
Identity Funding keys used for topup are the third sub-feature for identities. They are always derived as ECDSA keys.
We define the following levels for them:
m / purpose' / coin_type' / feature' / sub feature' / funding index
Sub feature is set to 2'.
We should note that unlike Identity Registration keys, Top Up Funding keys do not reference an identity and can be used to top up any identity. It is useful to point out that a registration funding key is a source of entropy in the unique identifier of the identity it will fund, and this is obviously not the case for top up funding keys.
If a wallet recovers an unused top up funding transaction, the wallet should attempt to reuse it. This is done in a few steps. First, the wallet must recognise the key used in a returned identity funding transaction as a top up funding key. Then the wallet must query Dash Platform to check if the top up transaction has already been used and the balance transferred into credits. If this is not the case, the wallet can then perform an identity top up transition as defined in DIP11 using the top up funding key.
It is recommended that 30 address hashes of these keys be added to the bloom filter sent to peers. If transactions containing 25 address hashes or more have been found, the filter should be regenerated with 30 more.
Copyright (c) 2020 Dash Core Group, Inc. Licensed under the MIT License