Wallets: Key Encodings and Deterministic Sequences

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

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

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

View Slide

Parsimonious Large Number Representation
Larger digit set available
↓↓
less digits required to represent large numbers
e.g. 16^5-2:
Binary: 11111111111111111110
Decimal: 1048574
Hexadecimal: FFFFE
Base58: 6Nhs
4/88

View Slide

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
3. ExtPayload||Checksum
4. Base58Check encoding =
Base58(ExtPayload||Checksum)
5/88

View Slide

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

View Slide

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

View Slide

(2/4)
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

(3/4)
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

(4/4)
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

From Compressed Public Key to Address
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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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)

View Slide

Table of Contents
2. Wallets
4. Hierarchical Deterministic Wallets: BIP32, BIP43, BIP44

View Slide

Private/Public Keys and Addresses
▪ Not created, used without any prior authorization
▪ Not registered anywhere (until used for the first time)

View Slide

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

View Slide

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
https://www.youtube.com/watch?v=ZloHVKk7DHk
20/88

View Slide

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

View Slide

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

View Slide

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…)

View Slide

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

View Slide

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

View Slide

Once initialized, they can sign transactions, but will never reveal
private keys
Hardware Wallets

View Slide

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)

View Slide

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

View Slide

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
https://bitcoin.org/en/choose-your-wallet
29/88

View Slide

30/88

View Slide

31/88

View Slide

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

View Slide

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

View Slide

Table of Contents
2. Wallets

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Table of Contents
2. Wallets

View Slide

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

View Slide

Seed, Master Key, and Chain Code (2/2)
See xmprv_from_seed.py in bip32.py at https://github.com/dginst/btclib

View Slide

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

View Slide

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

View Slide

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/

View Slide

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

View Slide

Extended Pubkey Neutered Derivation
[13:45] chain code
[46:78] prvkey
[ 9:13] index
[ 5: 9] fingerprint
[ 4: 5] depth
[45:46] 00
[13:45] chain code
[46:78] Pubkey
[ 9:13] index
[ 5: 9] fingerprint
[ 4: 5] depth
[45:46] 02 or 03
xpub = xpub_from_xprv(xprv)
xprv key xpub key

View Slide

▪ 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)
Child Key Derivation
50/88

View Slide

Child Key Derivation Normal
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
[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
[45:46] 02 or 03
parent xpub key child xpub key
51/88

View Slide

Child Key Derivation Normal
4 bytes child index < 0x800000
HMAC
SHA512
[46:78] parentkey
[ 4: 5] depth
[45:46] 00
parent xprv key
[46:78] childkey
[ 9:13] child index < 0x800000
[ 4: 5] depth + 1
[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

Child Key Derivation Hardened
4 bytes child index >=0x800000
HMAC
SHA512
[46:78] parentkey
[ 4: 5] depth
[45:46] 00
[46:78] childkey
[ 9:13] child index >=0x800000
[ 4: 5] depth + 1
[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

▪ 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
The Key Tree
54/88

View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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
https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
59/88

View Slide

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
BIP44: Multi-Account Hierarchy (1/2)
60/88

View Slide

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
BIP44: Multi-Account Hierarchy (2/2)
61/88

View Slide

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

View Slide

Homework
1. Reproduce the “test vector 2” at
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

View Slide

Table of Contents
2. Wallets

View Slide

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
See mnemonic.py and bip39.py at https://github.com/dginst/btclib
65/88

View Slide

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 |
BIP39: Mnemonic From Entropy
66/88

View Slide

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

View Slide

BIP39 + BIP32: Mnemonic HD Wallets

View Slide

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.?)

View Slide

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
http://docs.electrum.org/en/latest/seedphrase.html
70/88

View Slide

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

View Slide

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

View Slide

Table of Contents
2. Wallets

View Slide

BOB STORE
250
350
200
BTC accepted at the store
1 0
0
74/88

View Slide

250
350
200
BTC accepted at the store
0 1
0
BLOCKCHAIN
TRANSACTION
BOB STORE
75/88

View Slide

250
350
200


BTC not accepted at the store
1
0
BLOCKCHAIN
TRANSACTION
BOB STORE
76/88

View Slide

250
350
200
BLOCKCHAIN
TRANSACTION
Payment Processor
200
200
1 1
SEPA
BOB STORE
PAYMENT PROCESSOR
77/88

View Slide

EXCHANGE EUR/BTC
Buying and Selling BTC: the Exchange
200
0
BOB ALICE
0
1
78/88

View Slide

200
0
0
BOB ALICE
ACCOUNT
0 0
ACCOUNT
0
Exchange Account Creation
0
1
EXCHANGE EUR/BTC
79/88

View Slide

0
0
0
ACCOUNT
200 0
ACCOUNT
1
Exchange Account Deposit
BOB ALICE
0
0
EXCHANGE EUR/BTC
BLOCKCHAIN
TRANSACTION
SEPA
80/88

View Slide

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

View Slide

200
ACCOUNT
0 1
ACCOUNT
0
Exchange Trading
0
0
BOB ALICE
0
0
EXCHANGE EUR/BTC
82/88

View Slide

▪ 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
Warning!!
83/88

View Slide

0
EXCHANGE EUR/BTC
ACCOUNT
0 0
ACCOUNT
0
Exchange Account Withdrawal
SEPA
BLOCKCHAIN
TRANSACTION
0
1
BOB ALICE
200
0
84/88

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

Wallets: Key Encodings and Deterministic Sequences

Wallets: Key Encodings and Deterministic Sequences

Ferdinando M. Ametrano

More Decks by Ferdinando M. Ametrano

Other Decks in Technology

Featured

Transcript