Wallets: Key Encodings and Deterministic Sequences

Fourth lesson for the Bitcoin and Blockchain Technology course of Milano-Bicocca and Politecnico di Milano

www.ametrano.net/bbt/

Transcript

1. Bitcoin and Blockchain Technology Wallets: Key Encodings and Deterministic Sequences v2019.04.03 Comments, corrections, and questions: https://drive.google.com/open?id=1zWuYqRip3TfgjjV2a0YL_C_KlJGc0o57 © 2019 Digital Gold Institute
2. Table of Contents 1. Addresses and Wallet Import Formats 2. Wallets 3. Deterministic Wallets 4. Hierarchical Deterministic Wallets: BIP32, 43, 44 5. Mnemonic Phrase: BIP39 and Electrum 6. Payment Processors and Exchanges © 2019 Digital Gold Institute 2/88
3. Different Encoding Types ▪ Binary digits: 01 ▪ Decimal digits: 0123456789 ▪ Hexadecimal digits: 0123456789ABCDEF ▪ Base58 digits: all alphanumeric characters (numbers, uppercase, and lowercase) omitting 0 (zero), O (capital o), I (capital i) and l (lower case L) 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxy © 2019 Digital Gold Institute 3/88
4. Parsimonious Large Number Representation Larger digit set available ↓↓ less digits required to represent large numbers e.g. 16^5-2: © 2019 Digital Gold Institute Binary: 11111111111111111110 Decimal: 1048574 Hexadecimal: FFFFE Base58: 6Nhs 4/88
5. Base58Check Encoding 1. Payload 2. Prefix||Payload||Suffix=ExtPayload a. ExtPayload b. SHA256(ExtPayload) c. SHA256(SHA256(ExtPayload)) d. Checksum = first 4 bytes of the previous step Double SHA256 Checksum Calculation The Base58Check decoding stage will first use the checksum to detect possible errors in ExtPayload before actual decoding © 2019 Digital Gold Institute 3. ExtPayload||Checksum 4. Base58Check encoding = Base58(ExtPayload||Checksum) 5/88
6. Public/private Keys: Base58 Representation Base58 is used for the compact representation of Bitcoin Public/private keys: ▪ Address: Public Key in Base58 representation ▪ Wallet Import Format: private key in Base58 representation © 2019 Digital Gold Institute 6/88
7. From Uncompressed Public Key to Address (1/4) Given the private key 0x18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725 1. Start from the associated Public Key point in uncompressed representation (65 bytes: 1 byte for the x04 prefix, 32 bytes for the X coordinate, 32 bytes for the Y coordinate) 04 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 2CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6 © 2019 Digital Gold Institute 7/88
8. From Uncompressed Public Key to Address (2/4) © 2019 Digital Gold Institute 2. Perform SHA256 hashing on the Public Key 600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408 3. Perform RIPEMD160 hashing on the result of SHA256 010966776006953D5567439E5E39F86A0D273BEE Note: step 2-3 are often defined as HASH160 HASH160(PubKey) := SHA256(RIPEMD160(PubKey)) 4. Add version byte in front of HASH160 (0x00 for Main Network) to obtain the extended HASH160 00010966776006953D5567439E5E39F86A0D273BEE The leading zeros, while irrelevant digits for a number, are retained through the following conversions and will lead to a leading 1 in the resulting address 8/88
9. From Uncompressed Public Key to Address (3/4) © 2019 Digital Gold Institute Base58Check encoding steps: 5. SHA256 hash on the extended HASH160 445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094 6. SHA256 hash on the result of the previous step D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30 7. Take the first 4 bytes of the second SHA256 hash as address checksum D61967F6 9/88
10. From Uncompressed Public Key to Address (4/4) © 2019 Digital Gold Institute 8. Add the 4 checksum bytes from stage 7 at the end of extended HASH160 00010966776006953D5567439E5E39F86A0D273BEED61967F6 9. Convert into a base58 string using Base58 encoding 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM The bitcoin address is the Base58 encoding of the HASH160 of a Public key; it starts with 1 because of the 0x00 prefix. https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses 10/88
11. From Compressed Public Key to Address © 2019 Digital Gold Institute Using the same private key as in the previous slide 0x18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725 ▪ Start from the associated Public Key in compressed representation (33 bytes: 1 byte x02 or x03, 32 bytes corresponding to the X coordinate) 02 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 ▪ Arrive to a Base58 encoded address 1PMycacnJaSqwwJqjawXBErnLsZ7RkXUAs Again: the address is the Base58 encoding of the HASH160 of a Public Key; it starts with 1 because of the 0x00 prefix. 11/88
12. Private Key (Uncompressed) WIF Given a private key 0x0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D 1. Add to the private key a 80 prefix (no suffix) 80 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D 2. 4 bytes checksum added 80 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D 3. Base58 encode is 51 characters; it always starts with 5, because of the 0x80 prefix 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ The uncompressed property does not refer to the private key: it is the Public Key derived from WIF that must be uncompressed © 2019 Digital Gold Institute 12/88
13. Private Key (Compressed) WIF Using the same private key as in the previous slide 0x0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D 1. Add to the private key a 80 prefix and a 01 compression marker suffix 80 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D01 2. 4 bytes checksum added 80 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D01A62019D2 3. Base58 encode is 52 characters (longer than uncompressed WIF because of the 0x01 suffix); it always starts with K or L, because of the 0x80 prefix KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYvP98617 The compressed property does not refer to the private key: it is the Public Key derived from WIF that must be compressed © 2019 Digital Gold Institute 13/88
14. Addresses/Keys Version Types Network Usage Version type Leading symbol(s) Mainnet Pubkey hash (address) 00 1 Mainnet prvkey (uncompressed WIF) 80 5 Mainnet prvkey (compressed WIF) 80 K or L Testnet Pubkey hash (address) 6F m or n Testnet prvkey (uncompressed WIF) EF 9 Testnet prvkey (compressed WIF) EF c © 2019 Digital Gold Institute 14/88
15. Relation Between Keys, Addresses, and WIF prvkey → PubKey → address 1. prvkey  Base58Encoding → WIF 2. prvkey -- EC Multiplication → PubKey 3. PubKey -- HASH160 → PubKeyHash 4. PubKeyHash  Base58Encoding → address ▪ EC multiplication and hash functions are one-way ▪ Quantum computers will be able to factor private keys from Public keys, but not to invert hash functions © 2019 Digital Gold Institute 15/88
16. Homework With the private key obtained with the previous homework: 1. Calculate the uncompressed WIF 2. Calculate the compressed WIF 3. Calculate the address from uncompressed Public Key 4. Calculate the address from compressed Public Key Check prvkey2wif_compressed.py, prvkey2wif_uncompressed.py, and pubkey2address.py in the py-scripts folder at https://github.com/dginst/bbt/ Alternatively check wifaddress.py in https://github.com/dginst/btclib Verify your results at www.bitaddress.org (Wallet Details) © 2019 Digital Gold Institute 16/88
17. Table of Contents 1. Addresses and Wallet Import Formats 2. Wallets 3. Deterministic Wallets 4. Hierarchical Deterministic Wallets: BIP32, BIP43, BIP44 5. Mnemonic Phrase: BIP39 and Electrum 6. Payment Processors and Exchanges © 2019 Digital Gold Institute 17/88
18. Private/Public Keys and Addresses ▪ Not created, used without any prior authorization ▪ Not registered anywhere (until used for the first time) © 2019 Digital Gold Institute 18/88
19. Wallet as Collection of (Numbers, i.e.) Private Keys ▪ prvkey → PubKey → address ▪ An address is 160 bits, i.e. 160 coin flips: 2^160=10^48 (quindecillion): no significant odds of selecting an already used address ▪ Chance of winning Powerball lottery jackpot is one-in-175- million: easier to win Powerball for 10^40 consecutive weeks, i.e. 10^39 years, i.e. 10^29 times the universe age 154tRyjBg4Xd6nqAuNciAtX18GgM1QnXLn © 2019 Digital Gold Institute 19/88
20. Security by big numbers ▪ Humanity 6*10^9 - > 100*10^9 ▪ Average life 70y -> 100y ▪ Minute per year 0.5*10^6 -> 10^6 ▪ Max VISA transactions per minute 5000->10^4 10^11 * 10^2 * 10^6 * 10^4 = 10^23 ▪ If every transaction were to use a different address, there would be 10^25 addresses available per transaction!! ▪ Number of grain of sand on the earth: 10^24 © 2019 Digital Gold Institute https://www.youtube.com/watch?v=ZloHVKk7DHk 20/88
21. Bitcoin Secure Spending: Goals & Trade-offs Private keys allow bitcoin spending, their safe storage is crucial ▪ Availability: you can spend your coins ▪ Security: nobody else can spend your coins ▪ Convenience: easy to spend your coins © 2019 Digital Gold Institute 21/88
22. Private Key In a File, On a Device ▪ As available as your device: device lost/wiped ⇒ key lost ⇒ coins lost ▪ As secure as your device: device compromised ⇒ key leaked ⇒ coins stolen ▪ Not really convenient: to really do a transaction some software is needed © 2019 Digital Gold Institute 22/88
23. Wallet Private keys (and derived Public Keys and addresses) can be managed with a wallet: ▪ Software (desktop PC, mobile device, and/or web) ▪ Hardware (+ software) ▪ Paper (+ software, at least eventually…) © 2019 Digital Gold Institute 23/88
24. Decouple Cold and Hot Sides If private keys have been generated offline and are stored and accessed (for signing) offline ▪ then the wallet is a cold wallet (safer, inconvenient) ▪ else it is a hot wallet (risky, convenient) Addresses can be managed with a hot wallet: there is no risk (but privacy) in having them online and/or public © 2019 Digital Gold Institute 24/88
25. How to Store Cold Info 1. Info stored in a device, device locked in a safe 2. “Brain wallet”: encrypt info under passphrase that user remembers (very unsafe!) 3. Paper wallet: print info on paper, lock up the paper 4. Multi-sig (multiple signature needed, e.g. 2-out-of-3) 5. Hardware wallet: “tamperproof” device will sign but will not divulge keys © 2019 Digital Gold Institute 25/88
26. Once initialized, they can sign transactions, but will never reveal private keys Hardware Wallets © 2019 Digital Gold Institute 26/88
27. Bitcoin Secure Spending To spend bitcoins securely, a wallet needs: 1. the private key those bitcoins are associated to: key management must be secure 2. info from the public blockchain (UTxOs): a connection to the bitcoin network is required, directly (full node) or through a trusted server (light client) © 2019 Digital Gold Institute 27/88
28. Node Clients Fully-validating clients ▪ Permanently connected ▪ Store the entire blockchain (about 170GB as of Jun 2018) ▪ Hear and forward every transaction/block ▪ Trust no one Thin/SPV clients ▪ Occasionally connected ▪ Store block headers only (80 bytes * 527000 blocks = about 42MB as of Jun 2018) ▪ Request transactions as needed, to verify incoming payments ▪ Trust fully-validating nodes © 2019 Digital Gold Institute 28/88
29. Choose Your Wallet (1/3) ▪ Select a wallet to store bitcoin and transact on the network ▪ Take time to educate yourself! ▪ Before any serious transaction, be sure to read what you need to know and take appropriate steps to secure your wallet ▪ Always remember that it is your responsibility to choose your wallet carefully and adopt good practices in order to protect your money and privacy © 2019 Digital Gold Institute https://bitcoin.org/en/choose-your-wallet 29/88
30. Choose Your Wallet (2/3) © 2019 Digital Gold Institute https://bitcoin.org/en/choose-your-wallet 30/88
31. Choose Your Wallet (3/3) © 2019 Digital Gold Institute https://bitcoin.org/en/choose-your-wallet 31/88
32. Wallet: Bookkeeping on User’s Behalf ▪ Keeps track of key pairs and associated addresses ▪ Provides nice user interface ▪ Encodes QR codes 154tRyjBg4Xd6nqAuNciAtX18GgM1QnXLn ⇒ ▪ Helps avoid address reuse, using a separate address/key for each transaction © 2019 Digital Gold Institute 32/88
33. Do Not Reuse Addresses ▪ Bitcoin transactions being public, blockchain analysis reveals a lot of information, especially if addresses are reused ▪ Digital signature algorithms require a secret ephemeral key: if reused with the same private key, the private key is revealed. If a key pair (and its associated address) is not reused, then this risk is avoided © 2019 Digital Gold Institute 33/88
34. Table of Contents 1. Addresses and Wallet Import Formats 2. Wallets 3. Deterministic Wallets 4. Hierarchical Deterministic Wallets: BIP32, 43, 44 5. Mnemonic Phrase: BIP39 and Electrum 6. Payment Processors and Exchanges © 2019 Digital Gold Institute 34/88
35. A Different Address For Each Transaction ▪ Wallets used to precompute many random unlinked private keys, incrementing them as needed − required periodic backup − derived addresses were difficult to share: reusing them was temptingly ▪ Deterministic wallets derives multiple keys/addresses from a single root/seed, which is the only information to back up © 2019 Digital Gold Institute 35/88
36. Hash Chain: Deterministic Wallet (Type-1) ▪ = (||) ▪ = store once forever ▪ generate addresses ahead of the furthest observed on the network, keys can be regenerated as needed ▪ A deterministic wallet requires just one backup because all future addresses are determined in advance If you only know you have no clue about +1 See py-scripts/det_wallet_type1.py at https://github.com/dginst/bbt © 2019 Digital Gold Institute 36/88
37. Decouple Cold and Hot Sides Problem: how can an ecommerce site receive payments using always different addresses if the cold wallet is offline? ▪ awkward solution: generate a big batch of private/public keys offline, transfer the addresses online beforehand ▪ better solution: use a type-2 deterministic wallet © 2019 Digital Gold Institute 37/88
38. Hash Chain: Deterministic Wallet (Type-2) ▪ master private ▪ master public = ▪ public Store and once forever ▪ = + (||) ▪ = + (||) = + || = + || ▪ All private keys are + , Public keys are + ▪ All Public keys are generated by and , without any secret If you know one and you can figure out , therefore all © 2019 Digital Gold Institute 38/88
39. Deterministic Wallet Type-2 ▪ Type-2 works like Type-1, with the advantage that public key generation does not require private keys at all !! ▪ An e-commerce site could use , to generate public keys; if hacked the public key sequence would be revealed but no private keys would be leaked See py-scripts/det_wallet_type2.py at https://github.com/dginst/bbt © 2019 Digital Gold Institute 39/88
40. Multiple Key-pair Chains ▪ Deterministic wallets consist of a single “hash-chain" of key- pairs: sharing a wallet happens on an all-or-nothing basis ▪ A tree structure would allow: − sub-branches to be selectively shared − To differentiate key branches, e.g. receiving (incoming payment) addresses from change (pay-to-self) addresses © 2019 Digital Gold Institute 40/88
41. Hierarchical Deterministic Wallets Hierarchical deterministic wallets allow selective sharing by supporting multiple key-pair hash-chains, one per = + | | = + (||||) = + | | e.g. could be 0 for receiving addresses (external branch), 1 for change addresses (internal branch) Derivation policy can be specified by a standard © 2019 Digital Gold Institute 41/88
42. Table of Contents 1. Addresses and Wallet Import Formats 2. Wallets 3. Deterministic Wallets 4. Hierarchical Deterministic Wallets: BIP32, 43, 44 5. Mnemonic Phrase: BIP39 and Electrum 6. Payment Processors and Exchanges © 2019 Digital Gold Institute 42/88
43. Seed, Master Key, and Chain Code (1/2) 1. Generate a random seed S(128, 256, or 512 bits) 2. Use HMAC-SHA512 (Hash Message Authentication Codes with SHA512 as hash function) to produces 512 bits HMAC-SHA512(“Bitcoin seed”, S) − the left 256 bits are the master private key − the right 256 bits are deterministic entropy: the master chain code ▪ the extended master private key is xmprv = mprv + c © 2019 Digital Gold Institute 43/88
44. Seed, Master Key, and Chain Code (2/2) See xmprv_from_seed.py in bip32.py at https://github.com/dginst/btclib © 2019 Digital Gold Institute 44/88
45. Child Key From Extended Parent Key The i-th child key is derived from his extended parent key, i.e. parent key + chain code, using HMAC-SHA512 again HMAC-SHA512(parent chain code, parent key || i) ▪ the left 256 bits are the child key ▪ the right 256 bits are the child chain code, that will be used as deterministic entropy to derive grand-children ▪ the extended child key is xkey = key + c ▪ normal children have i < 2^31 = 0x80000000 ▪ hardened children have i >= 2^31 = 0x80000000 ▪ to ease notation i' = iH = i+2^31 © 2019 Digital Gold Institute 45/88
46. Extended Keys Serialization Format 78 byte serialization format, encoded with check-summed Base58 [version prefix (xprv) | generation data | c | prvkey] [version prefix (xpub) | generation data | c | Pubkey] [ 0: 4] version mainnet: 0x0488B21E -> xpub, 0x0488ADE4 -> xprv testnet: 0x043587CF -> tpub, 0x04358394 -> tprv [ 4: 5] depth: 0x00 for master key, 0x01 for level-1 keys, etc. [ 5: 9] fingerprint of the parent’s address (0x00000000 if master) h160(Parentkey)[:4] [ 9:13] child index, aka child number (0x00000000 if master) [13:45] 32 bytes chain code c [45:78] 33 bytes compressed (02, 03) Pubkey or (00) prvkey © 2019 Digital Gold Institute 46/88
47. Neutered Derivation Neutered Derivation (ND) is the computation of the extended public key corresponding to an extended private key (“neutered” as it removes the ability to sign transactions) xprv → xpub xpub = xpub_from_xprv(xprv) See bip32.py in https://github.com/dginst/btclib and/or bip32-testvector1.py, bip32-testvector3.py at https://github.com/dginst/bbt/py-scripts/ © 2019 Digital Gold Institute 47/88
48. Extended Master Pubkey Neutered Derivation [13:45] master chain code [46:78] master prvkey [ 9:13] index = 0x00000000 [ 5: 9] fingerprint = 0x00000000 [ 4: 5] depth = 0x00 [ 0: 4] xprv (version) [45:46] 00 [13:45] master chain code [46:78] Master Pubkey [ 9:13] index = 0x00000000 [ 5: 9] fingerprint = 0x00000000 [ 4: 5] depth = 0x00 [ 0: 4] xpub (version) [45:46] 02 or 03 xmpub = xpub_from_xprv(xmprv) xmprv key xmpub key © 2019 Digital Gold Institute 48/88
49. Extended Pubkey Neutered Derivation [13:45] chain code [46:78] prvkey [ 9:13] index [ 5: 9] fingerprint [ 4: 5] depth [ 0: 4] xprv (version) [45:46] 00 [13:45] chain code [46:78] Pubkey [ 9:13] index [ 5: 9] fingerprint [ 4: 5] depth [ 0: 4] xpub (version) [45:46] 02 or 03 xpub = xpub_from_xprv(xprv) xprv key xpub key © 2019 Digital Gold Institute 49/88
50. ▪ parent xpub → child xprv ▪ parent xpub → child xpub (ckd, normal) ▪ parent xprv → child xprv (ckd, normal and hardened) See bip32.py in https://github.com/dginst/btclib and/or bip32-testvector1.py, bip32-testvector3.py at https://github.com/dginst/bbt/py-scripts/ Child Key Derivation (CKD) combines: 1. parent chain code: deterministic random data (256 bits, 32 bytes) 2. parent key: (00) xprv or compressed (02, 03) xpub (33 bytes) concatenated with index: the child number (32 bits, 4 bytes) © 2019 Digital Gold Institute Child Key Derivation 50/88
51. Child Key Derivation Normal © 2019 Digital Gold Institute ckd(parent extended key, child index) 4 bytes child index < 0x800000 HMAC SHA512 offset = [0:32] Offset = mult(offset) Childkey = add(Parentkey, Offset) Warning: offset derives from public stuff [13:45] parent chain code [46:78] Parentkey [ 9:13] index (not used) [ 5: 9] fingerprint (not used) [ 4: 5] depth [ 0: 4] xpub (version) [45:46] 02 or 03 [13:45] child chain code [46:78] Childkey [ 9:13] child index < 0x800000 [ 5: 9] Parentkey fingerprint [ 4: 5] depth + 1 [ 0: 4] xpub (version) [45:46] 02 or 03 parent xpub key child xpub key 51/88
52. Child Key Derivation Normal © 2019 Digital Gold Institute ckd(parent extended key, child index) 4 bytes child index < 0x800000 HMAC SHA512 [13:45] parent chain code [46:78] parentkey [ 9:13] index (not used) [ 5: 9] fingerprint (not used) [ 4: 5] depth [ 0: 4] xprv (version) [45:46] 00 parent xprv key [13:45] child chain code [46:78] childkey [ 9:13] child index < 0x800000 [ 5: 9] Parentkey fingerprint [ 4: 5] depth + 1 [ 0: 4] xprv (version) [45:46] 00 child xprv key 33 bytes compressed Parentkey offset = [0:32] childkey = parentkey + offset Warning: offset derives from public stuff 52/88
53. Child Key Derivation Hardened © 2019 Digital Gold Institute ckd(parent extended key, child index) 4 bytes child index >=0x800000 HMAC SHA512 [13:45] parent chain code [46:78] parentkey [ 9:13] index (not used) [ 5: 9] fingerprint (not used) [ 4: 5] depth [ 0: 4] xprv (version) [45:46] 00 [13:45] child chain code [46:78] childkey [ 9:13] child index >=0x800000 [ 5: 9] Parentkey fingerprint [ 4: 5] depth + 1 [ 0: 4] xprv (version) [45:46] 00 33 bytes compressed Parentkey parent xprv key child xprv key offset = [0:32] childkey = parentkey + offset Hardened offset derives from private stuff 53/88
54. ▪ Start with the master extended private key (xmprv) as root, then construct a key tree by recursively applying CKD. ▪ Notation is: index of each child key, separated by slashes CKD(xmprv, i ) := m/i CKD(CKD(CKD(xmprv,3),2'),5) := m/3/2'/5 CKD(CKD(CKD(xmpub,2),4 ),5) := M/2/4 /5 ND(m/a /b/c)= ND(m/a /b)/c = ND(m/a )/b/c = ND(m)/a /b /c = M/a/b/c ND(m/a’/b/c)= ND(m/a'/b)/c = ND(m/a’)/b/c but ND(m)/a’ is impossible ▪ xprv allows reconstruction of descendant prv and pub keys ▪ xpub allows reconstruction of descendant non-hardened pub keys © 2019 Digital Gold Institute The Key Tree 54/88
55. Risk Assessment (1/2) ▪ If not for the generation data, it would impossible to determine if extended keys are from a common parent ▪ The master xmpub key has no risk for the master xmprv key ▪ Derivation cannot be inverted: from a child xprv key the parent private key cannot be derived ▪ Child xpub keys have no risk for funds of the parent public key, only for grand-child privacy © 2019 Digital Gold Institute 55/88
56. Risk Assessment (2/2) Problem: non-hardened (child) xprv + parent xpub reveal the parent xprv, and thus ▪ every prv and pub keys descending from it ▪ all prv keys up to the first hardened parent xpub keys must be treated more carefully than regular pub keys: this is the reason for the existence of hardened key derivation © 2019 Digital Gold Institute 56/88
57. © 2019 Digital Gold Institute 57/88
58. Default Account Structure m/0' is BIP32 default first account Accounts are indexed by i, each account has two key chains: ▪ the external is used for change addresses: m/i'/0/k ▪ the internal is used for receiving payments: m/i'/1/k Two different chains allows revenues to be revealed (e.g. to an auditors) without revealing expenses or how much is left BIP32 derivation recipe can be retained and extended by alternative non-BIP32 key tree structures © 2019 Digital Gold Institute 58/88
59. BIP43: Purpose Field for HD Wallets BIP43 imposes further structure on the BIP32 HD key tree, intended for portability between wallet implementations ▪ First hardened child index is the “purpose” identifier m/purpose'/* ▪ Note that m/0'/* is already taken by BIP32 default account structure ▪ It could be used to generate keys for more cryptocurrencies, so it is suggested not to use version prefixes alternative to BIP32 0488B21E (xpub) and 0488ADE4 (xprv) ▪ Bitcoin Core does not implement BIP43 ▪ BIP44 extends BIP43 with further tree structure, using m/44'/* hierarchy © 2019 Digital Gold Institute https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki 59/88
60. BIP44 tree structure: m/purpose'/coin_type'/account'/change/address_index 1. BIP43 purpose, always set to 44’ 2. “coin_type” allows for multicurrency HD wallets, defined in Satoshi Labs SLIP-0044: Bitcoin mainnet is 0', all coin testnet 1’, Litecoin 2', etc. 3. “account” defines logical subaccounts. Each account is the root of its own subtree. Creation of account n is disallowed if n-1 has no transaction history © 2019 Digital Gold Institute https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP44: Multi-Account Hierarchy (1/2) 60/88
61. 4. “change” defines two subtrees, for receiving (external) and change addresses. Normal derivation allows xpub key export for use in a non-secured environments 5. “address_index”: usable addresses ▪ e.g. bitcoin, third account, external chain, second address: m/44'/0'/2'/0/1 ▪ Bitcoin Core does not implement BIP44 © 2019 Digital Gold Institute https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP44: Multi-Account Hierarchy (2/2) 61/88
62. BIP 44: Account Discovery Account discovery is used to restore wallet from seed backup: 1. start from account i=0 2. Scan external chain until there’s a gap of 20 unused addresses: after 20 unused addresses in a row, it is assumed there are no used addresses beyond. Only external chains are considered, as internal chains receive coins from associated external chains’ transactions 3. If account i has transactions, then i=i+1 and go back to step 2 © 2019 Digital Gold Institute 62/88
63. Homework 1. Reproduce the “test vector 2” at https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki 2. Calculate parent xprv from: Extended parent key (parent xpub): xpub6BabMgRo8rKHfpAb8waRM5vj2AneD4kDMsJhm7jpBDHSJvrFAjHJHU5hM43YgsuJVUVH WacAcTsgnyRptfMdMP8b28LYfqGocGdKCFjhQMV Extended child key (child xprv): xprv9xkG88dGyiurKbVbPH1kjdYrA8poBBBXa53RKuRGJXyruuoJUDd8e4m6poiz7rV8Z4No M5AJNcPHN6aj8wRFt5CWvF8VPfQCrDUcLU5tcTm Hint: pay attention to the warning in xprv->xprv normal derivation © 2019 Digital Gold Institute 63/88
64. Table of Contents 1. Addresses and Wallet Import Formats 2. Wallets 3. Deterministic Wallets 4. Hierarchical Deterministic Wallets: BIP32, 43, 44 5. Mnemonic Phrase: BIP39 and Electrum 6. Payment Processors and Exchanges © 2019 Digital Gold Institute 64/88
65. Mnemonic Code for Generating Deterministic Keys ▪ BIP39 mnemonic code words (aka mnemonic phrase or sentence) represent (encode) a random number (entropy) used as a seed for a BIP32 HD wallet. It is the effective HD wallet backup ▪ Mnemonic code words are a sequence of 12 to 24 words; e.g. “army van defense carry jealous true garbage claim echo media make crunch” ▪ A mnemonic phrase is superior for human interaction compared to raw binary or hexadecimal representations of a wallet seed ▪ Bitcoin Core does not implement BIP39 See mnemonic.py and bip39.py at https://github.com/dginst/btclib © 2019 Digital Gold Institute https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki 65/88
66. Generate 128, 160, 192, 224, or 256 bits of (raw) entropy ENT: more entropy increases security but also sentence length ▪ Entropy checksum CS: the first ENT/32 bits of SHA256(entropy) ▪ ENT||CS is split into groups of 11 bits, each one being a number in [0-2047] ▪ Numbers are indexes into a 2048 word list: the corresponding words form the mnemonic phrase CS = ENT / 32 MS = (ENT + CS) / 11 | ENT | CS | ENT+CS | MS | +-----+----+--------+----+ | 128 | 4 | 132 | 12 | | 160 | 5 | 165 | 15 | | 192 | 6 | 198 | 18 | | 224 | 7 | 231 | 21 | | 256 | 8 | 264 | 24 | © 2019 Digital Gold Institute BIP39: Mnemonic From Entropy 66/88
67. BIP39: BIP32 Seed From Mnemonic mnemonic phrase to seed conversion is independent from sentence generation: anyway, mnemonic phrase with fixed wordlist must exhibit a valid checksum ▪ mnemonic can be protected with a passphrase ▪ PBKDF2 (Password-based Key Derivation Function 2) is used for 2048 rounds of HMAC-SHA512 as pseudo-random function, with the mnemonic as password, and “mnemonic” + optional passphrase as salt seed = PBKDF2(mnemonic, “mnemonic” + passphrase, 2048, sha512) ▪ seed is used to generate BIP32 keys and addresses ▪ passphrase provides plausible deniability: every passphrase generates a valid BIP32 seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available © 2019 Digital Gold Institute 67/88
68. BIP39 + BIP32: Mnemonic HD Wallets © 2019 Digital Gold Institute 68/88
69. BIP39: Criticism ▪ Entropy generation relies on the security of a cryptographically secure pseudo-random number generator (CSPRNG). It is not clear whether using a random (entropy-derived) input to PBKDF2 is better than using a user-supplied password ▪ A fixed wordlist is required for checksum ▪ The seed does not indicate how the BIP32 key tree should be derived (standard BIP32 accounts, BIP44, etc.?) © 2019 Digital Gold Institute 69/88
70. Electrum Standard for Deterministic Keys ▪ Entropy is not check-summed as in BIP39, but the mnemonic phrase encoding it includes a version number to indicate which derivation should be followed for keys ▪ Version is also an integrity check: to be correct, a mnemonic phrase must produce a valid version number ▪ Version number is the first bits of: HMAC-SHA512("Seed version", mnemonic_phrase) 0x01 Standard P2PKH and Multisig P2SH wallets 0x100 SegWit P2WPKH and P2WSH wallets 0x101 2FA Two-factor authenticated wallets Unfortunately Electrum refers to the mnemonic phrase as seed, but this is not to be confused with the BIP32 seed See mnemonic.py and electrum_seed.py at https://github.com/dginst/btclib © 2019 Digital Gold Institute http://docs.electrum.org/en/latest/seedphrase.html 70/88
71. Electrum Standard: Mnemonic From Entropy Entropy search loop until a valid mnemonic phrase is found: 1. Candidate entropy is split into groups of 11 bits, each one being a number in [0-2047] 2. Numbers are used as indexes into a wordlist: the corresponding words form the candidate mnemonic phrase 3. if the candidate mnemonic is not valid, candidate entropy input is altered, back to step 1 This mnemonic recipe can be replaced by alternative algorithms and/or arbitrary wordlists: the only requirement is that the resulting mnemonic must produce a valid version number © 2019 Digital Gold Institute 71/88
72. Electrum Standard: BIP32 Seed From Mnemonic mnemonic phrase to seed conversion is independent from sentence generation: anyway, mnemonic phrase must produce a valid version number ▪ mnemonic can be protected with a passphrase (default is empty string) ▪ PBKDF2 (Password-based Key Derivation Function 2) is used for 2048 rounds of HMAC-SHA512 as pseudo-random function, with the mnemonic as password, and “electrum” + optional passphrase as salt seed = PBKDF2(mnemonic, “electrum” + passphrase, 2048, sha512) ▪ seed is used to generate BIP32 keys and addresses, with the structure specified by the mnemonic version ▪ passphrase provides plausible deniability: every passphrase generates a valid BIP32 seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available © 2019 Digital Gold Institute 72/88
73. Table of Contents 1. Addresses and Wallet Import Formats 2. Wallets 3. Deterministic Wallets 4. Hierarchical Deterministic Wallets: BIP32, 43, 44 5. Mnemonic Phrase: BIP39 and Electrum 6. Payment Processors and Exchanges © 2019 Digital Gold Institute 73/88
74. © 2019 Digital Gold Institute BOB STORE 250 350 200 BTC accepted at the store 1 0 0 74/88
75. © 2019 Digital Gold Institute 250 350 200 BTC accepted at the store 0 1 0 BLOCKCHAIN TRANSACTION BOB STORE 75/88
76. © 2019 Digital Gold Institute 250 350 200   BTC not accepted at the store 1 0 BLOCKCHAIN TRANSACTION BOB STORE 76/88
77. 250 350 200 BLOCKCHAIN TRANSACTION © 2019 Digital Gold Institute Payment Processor 200 200 1 1 SEPA BOB STORE PAYMENT PROCESSOR 77/88
78. EXCHANGE EUR/BTC © 2019 Digital Gold Institute Buying and Selling BTC: the Exchange 200 0 BOB ALICE 0 1 78/88
79. 200 0 0 BOB ALICE ACCOUNT 0 0 ACCOUNT 0 Exchange Account Creation © 2019 Digital Gold Institute 0 1 EXCHANGE EUR/BTC 79/88
80. 0 0 0 ACCOUNT 200 0 ACCOUNT 1 Exchange Account Deposit © 2019 Digital Gold Institute BOB ALICE 0 0 EXCHANGE EUR/BTC BLOCKCHAIN TRANSACTION SEPA 80/88
81. Warning!! ▪ At this stage bitcoins are associated to an address effectively controlled by the exchange using the corresponding private key ▪ Usually, the Euro amount does not enjoy any kind of deposit insurance © 2019 Digital Gold Institute 81/88
82. 200 ACCOUNT 0 1 ACCOUNT 0 Exchange Trading © 2019 Digital Gold Institute 0 0 BOB ALICE 0 0 EXCHANGE EUR/BTC 82/88
83. ▪ At this stage bitcoins are associated to an address effectively controlled by the exchange using the corresponding private key ▪ Usually, the Euro amount does not enjoy any kind of deposit insurance © 2019 Digital Gold Institute Warning!! 83/88
84. 0 EXCHANGE EUR/BTC ACCOUNT 0 0 ACCOUNT 0 Exchange Account Withdrawal SEPA BLOCKCHAIN TRANSACTION © 2019 Digital Gold Institute 0 1 BOB ALICE 200 0 84/88
85. Bitcoin Investing ▪ Bitcoins are easy to buy on exchanges, but to leave them there has proved to be unsafe (multiple hacks and incidents) ▪ If you do not own the private keys, then those bitcoins are not yours: they are owned by whoever can effectively spend them ▪ Bitcoin is about financial sovereignty: be your own bank! Unfortunately… ▪ Bitcoin safe storage is quite technical, for the time being mostly a geeky thing © 2019 Digital Gold Institute 85/88
86. Bitcoin for Institutional Investors and HNWI ▪ Institutional investors: safe custody of digital assets is not their business and/or core competence ▪ High net worth individuals: their threat model (coercion, violence, ramson, etc.) suggests shielded possession ▪ The need for digital gold intermediaries and vaults is exploding: funds and custodians ▪ Reputable professional intermediaries should be better equipped at efficient custodian selection © 2019 Digital Gold Institute 86/88
87. Bibliography ▪ A. Narayanan, et al., “Bitcoin and Cryptocurrency Technologies” − chapter 4 «How to Store and Use Bitcoins» ▪ Pedro Franco, “Understanding Bitcoin”, Wiley − chapter 8 «Wallets» ▪ Andreas Antonopoulos, “Mastering Bitcoin”, Second Edition, O'Reilly https://github.com/bitcoinbook/bitcoinbook − chapter 4 «Keys, Addresses» − chapter 5 «Wallets» ▪ G. Maxwell, “Deterministic Wallets” https://bitcointalk.org/index.php?topic=19137.msg239768#ms g239768 © 2019 Digital Gold Institute 87/88
88. Takeaways ▪ Do not reuse addresses, use secure (no web or brain) BIP32 HD wallets, possible backed by your own full node ▪ Do not share a non-hardened child private key plus its parent extended public key ▪ Consider storing a mnemonic sentence (BIP39 or Electrum) instead of an extended master private key ▪ Do not leave your bitcoins (and fiat money) in exchanges ▪ Be your own bank, if you can; else resort to reputed professionals for intermediation and custody © 2019 Digital Gold Institute 88/88
89. Ferdinando M. Ametrano Executive Director ferdinando@dgi.io Paolo Mazzocchi Chief Operating Officer paolo@dgi.io www.github.com/dginst www.facebook.com/DigitalGoldInstitute www.twitter.com/DigitalGoldInst www.dgi.org/feed.xml info@dgi.io www.dgi.io www.linkedin.com/company/digital-gold-institute "Scarcity in the Digital Domain"