Mnemonic Key Words (BIP39)
- Mnemonics are a user-friendly way to encode
a secret root seed for a wallet. - Generate SHA256 checksum
- Secret lengths: 128, 160, 192, 224, 256 bits
- Checksum lengths: 4, 5, 6, 7, 8 bits
- Checksum length = secret length / 32
- Split into 11-bit chunks
- Sequence of 11-bit chunks needs to be maintained.
- 11-bit to word mapping
- There are multiple languages mappings available to translate 11-bit chunks into words (BIP39).
Mnemonics-to-Seed (BIP39)
- Password-Based Key Derivation Function 2
- 2048 rounds of HMAC-SHA512
- Password: mnemonic sentence
- Salt: "mnemonic" + passphrase
- (Password & salt encoded in UTF-8 NFKD)
- 512-bit hash digest
- Seed for the creation of a wallet
Hierarchical Deterministic Wallets (BIP32)
- HD wallets (BIP32) can deterministically derive an indefinite number of fresh addresses from a single wallet secret.
- HD Tree
- Fresh addresses to improve privacy.
- HD Tree is derived from Master Keys.
- HD Tree can be reconstructed from master Keys (given tree structure).
- Master keys
- Derived from HD root secret.
- Subtrees
- Allow separation of keys for accounts/usages.
- Selective key sharing.
Master Key Pair Derivation
- The master key pair is dervied from the HD root secret, and together with the chaincode, provides the basis for deriving subsequent child key generations.
- HMAC-SHA512
- 512 bit hash digest is split into
left and right 256 bits. - Right 256 bits are chaincode, used in
child key derivation.
Child Key Pair Derivation
- Hierarchical deterministic (child) private keys are derived from parent private keys.
- HMAC SHA512
- Key: Parent chaincode
- Data: Parent public Key || Index
- Addition of two 256bit scalars
- Private key + L256
- Result: Child private key
- Parent public key to child public key
- HD child public key derivation
without parent private key.
HD Derivation Paths
- Parent-to-child derivation
- Parent private to child private key
- Parent public to child public key
- Firewall between private and public
key derivation paths - Creation of new addresses can be delegated safely.
- Example: Creation of new receiving addresses by frontend.
- XPRV & XPUB keys
- Chaincode
- + Private or public key
Extended Key Format
Upstream Private Key Exposure
- 1) Parent XPUB + private child exposure.
- Public keys are potentially public.
- Child private key is exposed.
- 2) Child XPUB is exposed.
- L256 is derived.
- Both child XPRV and XPUB
are now exposed. - 3) Parent private key is exposed.
- Complete HD subtree is exposed.
Upstream Private Key Exposure 2
- 1) Parent XPUB + private child exposure.
- Chaincode is identical for all keys of the same generation.
- 2) All child public keys are exposed.
- All child chain codes are exposed.
- 3) Parent Private Key is exposed.
- Complete HD subtree is exposed.
Hardened HD Children
- Child private key hardening
- Parent public key replaces private key.
- HMAC512:
- Key: parent chaincode
- Data: 0x00 || private key || index
- Hardened Index Notation:
- i' = i + 2^31
- Hardened public keys.
- Cannot derive any children.
- Derived only from hardened
parent child key.
Hardened HD Key Path
- Hardened Child Keys break XPUB derivation paths
- Hardened keys denoted with prime′
- Although the parent keys are hardened, note that children keys mustn't necessarily be hardened, as shown here.
- This means the child XPUB keys in this example can derive grandchildren XPUB keys.
- Note: In the case of key exposure in any of the subsequent child generations, the upstream key exposure cannot propgate up to the hardened parent key.
HD Wallet Tree Structure (BIP44/43)
- ➊ Purpose
- Always set to a hardened 44′ (BIP44/43).
- ➋ Network
- Mainnet: 0′
- Testnet: 1′
- ➌ Account
- Individual Wallet Accounts.
- ➍ Receiving/Change Addresses
- Keys of receiving address: 0 (unhardened)
- Keys of change address: 1 (unhardened)
- ➎ Address Index
HD Wallet Restoration
