Wallets: Key Encodings and Deterministic Sequences

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

▪ 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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

▪ 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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

Slide 83

Slide 83 text

▪ 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

Slide 84

Slide 84 text

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

Ferdinando M. Ametrano Executive Director [email protected] Paolo Mazzocchi Chief Operating Officer [email protected] www.github.com/dginst www.facebook.com/DigitalGoldInstitute www.twitter.com/DigitalGoldInst www.dgi.org/feed.xml [email protected] www.dgi.io www.linkedin.com/company/digital-gold-institute "Scarcity in the Digital Domain"