Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Wallets: Key Encodings and Deterministic Sequences

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/

Ferdinando M. Ametrano

March 15, 2019
Tweet

More Decks by Ferdinando M. Ametrano

Other Decks in Technology

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  26. Once initialized, they can sign transactions, but will never reveal
    private keys
    Hardware Wallets
    © 2019 Digital Gold Institute 26/88

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  30. Choose Your Wallet (2/3)
    © 2019 Digital Gold Institute
    https://bitcoin.org/en/choose-your-wallet
    30/88

    View Slide

  31. Choose Your Wallet (3/3)
    © 2019 Digital Gold Institute
    https://bitcoin.org/en/choose-your-wallet
    31/88

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  57. © 2019 Digital Gold Institute 57/88

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  68. BIP39 + BIP32: Mnemonic HD Wallets
    © 2019 Digital Gold Institute 68/88

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  74. © 2019 Digital Gold Institute
    BOB STORE
    250
    350
    200
    BTC accepted at the store
    1 0
    0
    74/88

    View Slide

  75. © 2019 Digital Gold Institute
    250
    350
    200
    BTC accepted at the store
    0 1
    0
    BLOCKCHAIN
    TRANSACTION
    BOB STORE
    75/88

    View Slide

  76. © 2019 Digital Gold Institute
    250
    350
    200


    BTC not accepted at the store
    1
    0
    BLOCKCHAIN
    TRANSACTION
    BOB STORE
    76/88

    View Slide

  77. 250
    350
    200
    BLOCKCHAIN
    TRANSACTION
    © 2019 Digital Gold Institute
    Payment Processor
    200
    200
    1 1
    SEPA
    BOB STORE
    PAYMENT PROCESSOR
    77/88

    View Slide

  78. EXCHANGE EUR/BTC
    © 2019 Digital Gold Institute
    Buying and Selling BTC: the Exchange
    200
    0
    BOB ALICE
    0
    1
    78/88

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  82. 200
    ACCOUNT
    0 1
    ACCOUNT
    0
    Exchange Trading
    © 2019 Digital Gold Institute
    0
    0
    BOB ALICE
    0
    0
    EXCHANGE EUR/BTC
    82/88

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  89. 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"

    View Slide