#AVAX WALLET / WHAT IS IT ? HOW IT WORKS ? WHAT DOES IT STORE ?
This document explains inner workings of #AVAX wallet, and Hierarchical Deterministic (HD) Wallets in general, including techical details to a certain extend.
Audiance with technical curiosity is targeted.
Although #AVAX wallet is in focus, technical explanations in this document are applicable to all HD wallets supported by different blockchains (BC), BTC, ETH etc…
WALLET (in capitals) refers to “wallet.avax.network” throughout this document.
FIRST THINGS FIRST
First, we need to clarify one point : When we “logout” from WALLET, we see following pop-up:
What are the “private key and assets” that are removed ? Those are the public/private key pairs (master private key, to be exact) stored in WALLET as well as #AVAX we own. So, why are they “removed” ?
Here is the explanation :
-All the keys generated in WALLET for the current session is removed from WALLET in logout. During the next login, we need to enter 24 word mnemonics and all the keys are REgenerated. (Exporting the private key to a file is also supported but from a security perspective, I believe it is not good practice)
-#AVAX we own is NEVER stored in WALLET ! (In fact, none of the Crypto wallets store any type of coins at all). Only public/private key pairs are stored in wallets. #AVAX we own (or any other cryptocoin in that sense) is always stored in mainnet BC. When we login to WALLET, transactions related to our keys are scanned on BC and result is displayed as “owned #AVAX”. When we logout, this information is removed. Naturally, all #AVAX is secured and safe on BC with their respective owner’s keys. This applies to all common wallets like Ledger Nano, MEW, Metamask etc.
In short, job of the WALLET is not storing the assets themselves but storing the keys which proves that those assets are actually owned by the key owner. Assets are stored on BC. This document covers the details.
First, we will revisit PKI briefly, then we will cover HD wallet details like mnemonic creation, master seed and key generation, hierarchical child keys and similar technical details. Finally we revisit the above paragraph and see how assets are stored to close the loop.
PUBLIC KEY CRYPTOGRAPHY (PKI) BASICS
All BC infrastrustures are built on PKI (Public Key Infrastructure) and using asymetric cryptography. A brief introduction to PKI is presented below.
In a very ( I mean very) broad definition, in PKI, there is a Private/Public key pair and any information encrypted with one of the keys can only be decripted with other corresponding key. (From now on, “S/P” will be used for “private/public” -S for “Secret”-).
The relationship between S/P key pair is as follows : First, a random S key is created, then this S key is used as input to a mathematical function to generate related P key. The idea behind this is as follows : S key is random and very hard to guess. P key is derived from it but the function does not work backwards (It is impossible to find S key from P key). Each S/P pair is indivisable and related to each other. The job of the S key is to “sign” our messages to prove that the message is from us, whereas the job of the P key is for others to encrypt messages (with our P key) before sending to us so that only we can decrypt it. Therefore, S key is never shared to anyone, P is shared with others.
Here is an example :
Assume that Alice would like to send a message to Bob where only Bob can read it and also Bob could be sure that the message is from Alice.
To make sure that message is from Alice, Alice would sign(encrypt) the message with her S key (so that only her P key can decript it). Then, Alice would encrypt the message with Bob’s P key (so that only Bob can decryp it with his S key). Then Alice would send the message to Bob.
Now, Bob has message which can only be decrypted with his S key. He decrypts it. Still the message is encrypted with Alice’s S key, so Bob would decrypt second step with Alice’s P key. This two stage encryption assures that the message is surely from Alice and only Bob can read it !
(We assume here that Alice and Bob have each other’s P key, as this is default behaviour in PKI)
So, how are S/K pairs used in BC ?
In summary, #AVAX to be sent would first be signed with S key of the sender, then system approves that this #AVAX is actually owned by the sender (using sender’s P key, open to everyone), Then this #AVAX is signed with P key of the recipient and recorded into Chain (after which, only the new recipient can use with his/her S key). P keys mentioned here are just the #AVAX addresses (X-avax1…) shown in WALLET. (to be exact, there are a couple of steps more to create a real #AVAX address from an actual P key, but principle does not change. Later in the document…)
Summary of the summary : we prove the ownership of the #AVAX on BC with our S key, #AVAX sent to us is signed with our P key so that only we can use it. As a side information, to support anonymity, different S/P keys can be used for each transaction. We can own as many key paris as we like.
Remember : S/P key pairs are related to each other and S key is NEVER shared !
BACK TO MAIN TOPIC, #AVAX HD WALLET DETAILS
First, some information about wallets in general :
As stated above, BC working details aside, our only interface with BC is our S/P key pair. So the secuirty and safety, as well as backup, of these pairs are extremely important.
There are multiple categories of wallets :
· Software wallets (#AVAX WEBwallet)
· Hardware wallets (ledger)
· Printed (S/P keys printed on paper)
· Hot (web)
· Cold (Ledger)
· Web (#AVAX WEBwallet, MEW)
· Desktop (Metamask)
· Mobile (MEW)
· Non-custodial, (You own S/P keys)
· Custodial, your wallets in Binance, Kraken and similar exchanges, which you dont own S/P pairs. (remember : not your keys, not your coins !)
And multiple technical classes :
· Non-deterministic (Multiple S/P key pairs unrelated to one another)
· Sequential Deterministic (Multiple S/P pairs from a single seed, stored in sequential format)
· Hierarchical Deterministic (Multiple S/P pairs from a single seed, stored in hierarchical format)
#AVAX WALLET can be considered as a web based, non-custodial and hierarchical deterministic (HD) wallet.
Non-deterministic ve sequential deterministic wallets are rarely used today.
HD (HIERARCHICAL DETERMINISTIC) WALLET :
HD wallet details, including #AVAX WALLET, are based on Bitcoin Improvement Proposal (BIP) #0032 and details are specified in BIP44. (BIP32 specifies HD wallets in general and BIP44 is based on BIP32 and specifies details related to Crypto assets) (Links at the end of this document has more details)
HD wallets compliant to these standars can be used to create and store S/P pairs safely and securely.
WHAT IS “HIERARCHICAL” ?
All S/P pairs in all HD wallets are stored at nodes in an hierarchical format starting at root(0) level (master).
An exaple is sketch is added below.
WHAT IS “DETERMINISTIC” ?
“Deterministic” means, in principal, that all S/P pairs in an HD wallet can be (and are) generated from a master S key.
Best use of this feature is to easily backup the master key and to generate all related keys from it if/when necessary. For instance, if you run a webstore and would like to collect your receivables in #AVAX, you’d like to share multiple (millions) of different public keys to share with your customers. With HD wallets, it is very easy to create millions of keys and backup those keys by backing up only one master key. (Actually, you don’t backup master key but 24 words. Much easier ! )
BIP32 includes the details of practically unlimited number of S/P pairs (HD child key derivation). Necessary step for creating seed key is detailed in BIP39. Following is some more details in the process :
WHAT IS MNEMONIC KEY PHRASE (24 MNEMONIC)?
Summary of where we are :
We use our S key to prove the ownership of our assets on BC. We sign with our S key to send #AVAX and encrypt with P key of the recipient (his/her #avax address). Others use our P key (our #avax address) when sending us #avax. We use our S key to claim it. All the necessary keys for these operations are created and stored in BIP32/44 standard HD wallets.
Main differentiator of HD wallets is that, the same seed key is used to create all the keys mentioned.
Below are some more technical details :
For a key pair to be created, first a random function is used to create an S key. Then this S key is used to create the corresponding P key.
In first release of bitcoin, ECC (Ellyptic Curve Cryptography) function is used for creating P key from S key. Most (if not all) crypto world is still using ECC for P key derivation. SHA256 hash function is also used in this derivation process. (Details of mathematical functions like ECC and SHA256 are out of the scope of this document but links can be found at the end of this document for further details)
Now, lets see the necessary steps to create S/P pairs via “create a new wallet” path on wallet.avax.network or “setup a new wallet” path on a Ledger Nano HW wallet.
First of all, all the system is based on a random 128 to 256 bit binary number. Random mathematical functions and/or random number generator chips are used to create this number. This number is called “enthropy”. (In this document we will assume 256 bit random number which yields to 24 mnemonic words but 128 bits is perfectly ok, only yielding to 12 menmonic words. 256 bit is considered to be “harder to guess and more secure for brute force attacks)
This enthropy is SHA256 hashed and first 8 bits of the hash is appended to enthropy, yielding 264 bits.
This 264 bit number is the reference for all the following key creation, recovery, child key derivation, re-generation of keys etc.
It is virtually impossible to guess this number, as it has 2²⁶⁴ combinations (way more than the number of atoms forming the Earth !). Yet, it is not easy to remember it, either. Thanks to BIP39, we have a method to map this 264 bits into 24 words !
Here is how :
264 bits are grouped as 24x11 binary numbers. Each 11 bit number maps to a word in a 2048 (2¹¹) words list of BIP39. All 24 words written in sequence actually forms our 264 bit number, only human readable. It is equally virtually impossible to guess the 24 words in order.
Now that we see how 24 words mnemonics are formed, let’s repeat our sentence above :
These 24 words list is the reference for all the following key creation, recovery, child key derivation, re-generation of keys etc. It should be kept safe, not shared, not saved in digital environments, possibly secured by writing in paper&ink.
Now we can talk about S/P key generation and their use, using these 24 words.
CREATING S/P PAIR USING SEED
Following part includes the concept of Hierarchical S/P key creation. For mathematical details, please refer to links at the end of the document.
Our 24 words at this point is still not the S key. As next step, PBKDF2-HMAC-SHA512 function is iterated 2048 times on this 264 bits (and an optional pass phrase). The output of these iterations is a 512 bit number called as SEED. This is the seed for all the key paris to be created (and hence the keys are called “hierarchical”).
MASTER NODE AND CHILD NODE
First 256 bits of the seed is our MASTER PRIVATE (S) KEY and the second 256 bits is called CHAIN CODE (CC). These numbers will be used to derive the child key pairs in the hierarchical tree, Master Private Key’s level is defined to be MASTER NODE (LEVEL ZERO)
As can be seen, we’ve started with a random number and using multiple mathematical functions, we end up with 24 words and our unique Master Private (S) key which is virtually impossible to guess.
We add another parameter into our equations from this point on : Index (i). This index is used as a paramater in further key derivation algorithms and positions and levels of the key pairs in hierarchical tree can be visualized by index (i) in both dimentions.
(i) is a 32 bit number and any sub-level in hierarchy (other than MASTER NODE — level zero) can contain up to (i) nodes and you can go deep up to (i) levels in hierarchy. As 2³² is quite a large number already, any HD wallet can contain virtually infinite number of pairs.
During the derivation of child nodes, keys with different characteristics can be derived depending on the input to the derivation functions (wheather it is S or P of the parent and the value (i) defines the characteristic of the child)
Parent privatekey+chaincode+index → Child privatekey+chaincode
Parent publickey+chaincode+index → Child publickey+chaincode (NONHARDENED)
Parent privatekey+chaincode+index → Child publickey+chaincode (HARDENED)
Mathematical functions of child key derivation is out of the scope of this document, please refer to BIP32 for further details.
As an important note, during the child P key derivation, if parent S key is used, then the generated child key is called “HARDENED”, whereas if parent P key is used, then the generated child key is called “NON-HARDENED”. There are no means of figuring out parent S keys if the HARDENED P key and any of the parent S keys in hierarchy are exposed, however, if any of the parent S keys is exposed, NON-HARDENED key can be used to find out other parent S keys. Therefore, NON-HARDENED keys are said to be less secure, yet there are anonymity use cases and they are heavily used, provided that S keys are kept secure.
Below is a diagram showing hardened and non-hardened child key derivation :
In BIP44, hierarchical levels for crypto assets are defined as follows :
( use of apostrophe means a hardened key derivation at that level)
m / purpose’ / coin_type’ / account’ / change / address_index
Each part is a sub level down the hierarchy and indexes at that level differentiates the nodes at the level.
m: MASTER NODE (0).
purpose’ : index (44) is used for all Crypto supporting HD wallets.
coin_type’ : bitcoin = index(0) ; Ethereum = index(60) ; AVALANCE = index(9000) (other crypto assets can be found in SLIP-0044 document.) We can store keys for multiple crypto assets in an HD wallet.
account’ : Index for the account. We can store keys for multiple accounts for the each type of crypto in the wallet.
change : index(0) for internal addresses, index(1) for external addresses is used.
address_index : This level is the level for the keys to be used in asset transfers.
Below is a simlified view of an HD wallet for BTC, ETH and AVAX
INSIDE THE #AVAX WALLET (wallet.avax.network)
When we login to wallet.avax.network with our 24 mnemonic words, below can be seen in the main page. Key shown here is the external key (1) stored in index (0) of level address_index in hierarchy.
m / 44 / 9000 / 0 / 1 / 0
When you click “tree-like” button at the right, following pop-up is displayed. Internal addresses in this table are -generally- not shared addresses and they are used as change address in UTXO transactions. It is possible to receive avax to internal addresses, though. This is just a convention.
External addresses are the ones we share to receive #avax. Wallet application can generate as many pairs as needed, hence multiple addresses. Latest address is displayed in top main page for ease of sharing.
Last, but not least, Platform addresses are the ones on P-chain. These are used for staked or delegated #avax, for instance. These addresses are no different than any other key pairs from an HD wallet perspective, just different indexes are used at respective levels.
For any #avax address in any level/index, there is a standart way of address generation from respective public key. Bech32 standard and CB58 coding is used for generating “X-avax1…” or “P-avax1…” addresseses from public keys, as defined in BIP173 standards document.
HOW ARE THE INTERNAL AND EXTERNAL ADRESSES USED ? (UTXO)
Principally, one pair of S/P key is all we need in any transaction. Nevertheless, HD wallets provide infinite number of addresses for the sake of security, ease of use and anonimity.
On the other hand, UTXO transactions, by definition, make a special use of Internal and External adresses found in hierarchical “change” level.
Whenever we want to send some amount of #avax, if the exact amount is not available in the wallet address, whole amount is sent and remaining is taken back as change. This is the working model of UTXO blockchains. Basically, an UTXO transaction is a transaction with an input with whole amount and two outputs with transfer amount and change amount, first to the #avax address of the recipient and the second to the internal change address of the sender. (Similar to you give 10 USD banknote for a good of 8 USD and you receive 2 USD change in return.)
Main page of the wallet shows the total amount of #avax owned, however it is possible that the amount may be split among multiple addresses (internal and external).
WHERE ARE AVAXES STORED, IF NOT IN THE WALLET ?
During the genesis, #avax we own is sent to one of our external addresses. Rephrasing correctly, the #avax we purchase during ICO are recorded in genesis blockchain, encrypted with our P key (#avax address) so that only we can claim the ownership with our S key.
From that point on (genesis point), all the transactions are recorded on mainnet blockhain. These transactions are basically #avax transfers. When each block is validated and added to chain, a new level of DAG (Directed Acyclic Graph) is generated. (DAG is a kind of database structure the mainnet blockchain is stored on — in a very broad generalization)
When logout, all the #avax assests are forgotten. All the keys are also forgotten. This is necessary due to security reasons.
When we login, with the help of the 24 mnemonic words, all the keys are re-generated/derived, then the wallet app searches the leaves of the mainnet DAG and matches all the UTXO transactions which are related to our keys, adds up the assets and displays in the main page. In short, our assets are stored on mainnet blockchain. Job of the HD wallet is to store our key pairs for encryption. All the assets stored on blockchain are encrypted with owners’ keys.
LAST NOTE :
It was a long and -kind of- technical document. I’ve learnt a lot during my search, which I couldn’t add here. If you have any additional questions, please don’t hesitate to contact me in comments or avalanche telegram group. https://t.me/dilbertt
Thank you for reading
Reference links :
https://en.bitcoin.it/wiki/BIP_0032
https://www.secg.org/sec2-v2.pdf
http://blog.richardkiss.com/?p=313&cpage=1#comment-93828v
https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671
https://cryptochamp.com/what-methods-are-used-by-wallets-to-generate-keys/
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions
https://ledger.readthedocs.io/en/latest/index.html
https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
https://medium.com/@harshagoli/hd-wallets-explained-from-high-level-to-nuts-and-bolts-9a41545f5b0
https://github.com/satoshilabs/slips/blob/master/slip-0044.md
https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
https://www.ntirawen.com/2019/04/hierarchical-deterministic-wallet-bip32.html
