The possession of bitcoin currency is established through the interaction of digital keys, bitcoin addresses and digital signature. They are independent of the network itself, they can be generated even if you are not connected to the network and are stored on the host of the user who generated them in a file
or a database called wallet (wallet). The digital keys in a user’s wallet allow the implementation of some of the most important aspects of bitcoin and in particular the control and decentralized trust and the security model based on cryptography.
Each bitcoin transaction requires a valid signature to be included in the blockchain, which can
be generated only with valid digital keys, therefore, anyone with a copy of those keys has control of the bitcoins associated with that “account”.
A bitcoin wallet contains a collection of key pairs, each consisting of a key
private and a public key.
The private key is a 256-bit integer contained in the interval [1, n-1] (n = 1,158 * 10 ^ 77)
generable using the bitcoin client which uses the random number generator of the user’s operating system to produce 256 bits of entropy (to maintain a certain degree of randomness, the random number generation software generally requires human input such as random movement of the mouse pointer inside the screen).
Alternatively, the key can be generated without the aid of any software (any sequence of 256 bits contained in the range of integer values [1, n-1] is considered valid by the bitcoin system).
To give an idea of the level of randomness introduced using a 256 bit key, it is sufficient to think that its decimal correspondence is about 10 ^ 77 and it has been estimated that the number of atoms of the whole known universe is in the order of 10 ^ 80 .
The public key is determined starting from the private key through the ECDSA elliptic curve encryption protocol (elliptic curve digital signature algorithm) following a process described in detail in the cryptography paragraph in the bitcoin system.
Starting from the public key, the bitcoin address is generated, a parameter that can be shared and used to transfer currency among the various users of the system.
The address determination process involves a double hash function (invertible mathematical function) of the public key.
Specifically, the hash of the public key is computed using the SHA-256 algorithm which produces a 256-bit output whose hash is calculated using the RIPEMD-160 algorithm which produces a 160-bit output that matches the bitcoin address associated with the private-public key pair.
Generally the bitcoin address is represented in a compact form using the encoding
Base58Check. Base58Check is a 58-character encoding system derived from the Base58 system with the addition of a checksum parameter.
Base58 is a subset of Base64, which uses decimal and uppercase-lowercase characters, omitting some characters that can be confusing if represented in certain fonts (specifically the omitted characters are the decimal digit 0, the uppercase letter O, the lowercase letter l , the capital letter I and the symbols ” +” and “/”).
The checksum consists of 4 additional bytes added to the end of the compressed data and is used for the implementation of a transmission error control mechanism. It represents the first 4 bytes of the hash of the encoded data to be transmitted.
In reception, the hash of the received data is calculated (excluding the checksum), the first 4 bytes are extracted and compared with the 4 bytes of the cheksum.
If the comparison fails then a transmission error occurred and the received data are considered invalid. In the conversion of data in a Base58Check format to the data to be compressed, a prefix is added that allows to identify the type of compressed data.
The figure below lists the set of version prefixes used for Base58Check in bitcoins represented in hexadecimal format and in Base58 format.
Implementation of the Wallet
In the first implementation of the bitcoin client, wallets were simply a collection of randomly generated private keys. This type of wallet is called Type-0 wallet or “Just a Bunch Of Keys” (JBOK) and in subsequent implementations it has been replaced, due to management and backup difficulties, by a deterministic wallet.
The main disadvantage of a non-deterministic implementation of the wallet is the need to keep a copy of all the keys on the wallet and to make frequent backups to avoid accidental loss.
The current implementation of BitcoinCore allows the use of Type-0 wallets, but developers strongly advise against this choice.
The alternative implementation, known as a deterministic wallet or “seeded” wallet, requires that the set of private keys of the wallet be determined from a common key through a cryptographic hash function. The common seed is a randomly generated number which is combined with other parameters, such as index number and “chain code”, to generate the associated private keys. This implementation allows to keep a copy of the entire set of keys keeping only the “common seed” facilitating the backup and migration of the wallet.
The key backup process uses encoding words known as Mnemonic Code Words. They are a sequence of words that represented in encoded format the entire set of private keys contained in the deterministic bitcoin wallets. A wallet application that uses the mnemonic code shows the user who has just created their wallet a list of words (12 or 24 words) that is the encoded representation of the set of keys
private contained in the wallet itself. All you need to do is keep this sequence to recreate your wallet in any compatible application. Mnemonic code words make backup and restore operations easier because they are easier to read and transcribe than a number sequence.
The mnemonic queues are defined in Bitcoin Improvement Proposal 39 (BIP0039), which defines the creation of a mnemonic code as seed with the following process:
* Creates a random sequence (entropy) from 128 to 256 bits.
* Create a random sequence checksum by taking some of the first bits of its SHA256 hash.
* Add checksum at the end of the random sequence.
* Divide the sequence into two 11-bit sections, using these to index a dictionary of 2048 predefined words.
* Produces 12 to 24 words representing the mnemonic code.
Recall that BIP0039 is not a standard and is incompatible with some implementations of the
bitcoin wallets such as Electrum.
The following figure shows the relationship between the magnitude of the entropy data and the length of the mnemonic codes in words.
The mnemonic code represents 128 to 256 bits, which are used to derive a longer seed (512 bits) through the use of the PBKDF2 key-stretching function.
The resulting seed is used to create a deterministic wallet and all its derived keys.
The most advanced form of deterministic wallet is the hierarchical deterministic wallet or HD wallet defined by the BIP0032 standard. The deterministic hierarchical wallets contain keys derived in a tree structure, such that from a parent key can be derived a sequence of child keys, and from each of these you can derive a sequence of keys nephews, and so on, to a infinite depth.
HD wallets offer two important advantages over random keys (non-deterministic). Firstly, the tree structure can be used to represent an additional organizational structure, for example a specific branch of subkeys could be used to receive incoming payments and another branch to receive the remainder from outgoing payments. Some key branches could be used in different branches of the company, assigning different branches to departments, affiliated companies, specific functions, or accounting categories.
The second advantage of HD wallets is that users can create a public key sequence without having access to the corresponding private keys. This allows HD wallets to be used on an unsafe server or with only reception capacity, with the issuance of a different public key for each transaction. Public keys do not need to be preloaded or derived early, and the server does not have to have the private keys needed to spend the funds.
HD wallets are created from a single root seed, which is a random number at 128, 256 or 512 bits. Everything else in the HD wallet is deterministically derived from this root seed, which makes it possible to recreate the entire HD wallet from that seed in every HD compatible wallet. This makes it easy to make backup copies, restore, export, and import HD wallets containing thousands or even millions of keys simply by transferring only the root seed. The root seed is often represented by a mnemonic sequence of words, as described above.
The root seed is the input into the HMAC-SHA512 algorithm and the resulting hash is used to create a master private key (m) and a master chain code. The master private key (m) then generates a corresponding master public key (M) using the ECDSA elliptic curve encryption protocol.
The daughter key derivation functions are based on a mono-directional hash function that combines:
* A private or public key (ECDSA key not compressed)
* A seed called chain code (256 bit)
* An index number (32 bit)
The chain code is used to introduce apparently random data into the process, so that the index is not sufficient to derive other daughter keys. In this way, having a child key does not make it possible to find the sister keys, unless you also have the chain code. The initial seed of the chain code (root of the tree) is composed of random data, while the subsequent chain codes are derived from each parent chain code.
The main key, the chain code, and the index number are combined and encoded with the HMAC-SHA512 hash algorithm to produce a 512-bit hash. The resulting hash is divided into two halves. The 256 bits of the right half of the resulting hash becomes the chain code for the daughter. The 256 bits of the left half of the hash and the index number are added to the mother private key to produce the daughter private key. Changing the index number allows us to extend the parent key to generate the sequence of child keys. For each mother key, up to 2 billion daughter keys can be produced. By repeating the process one level downward in the tree, each daughter can in turn become a mother and create her own daughters, in an infinite number of generations. The private child keys are indistinguishable from non-deterministic (random) keys. Because the derivation function is a one-way function, the daughter key can not be used to find the parent key. The daughter key can also not be used to find any sisters. Only the mother key and the chain code can produce all the daughters. Without the daughter’s chain code, the daughter key can not be used to derive any grandchildren either.
The combination of chain and key is denoted by the term “extended key” and is simply represented as the concatenation of the 256-bit key and the 256-bit chain code in a sequence of 512 bits. There are two types of extended keys: extended private keys and extended public keys both represented in the Base58Check encoding, in order to be easily exported and imported between the different BIP0032 compatible portfolios. Base58Check encoding for extended keys uses a special version number that produces the prefix “xprv” and “xpub” when encoded in Base58 characters, to make them easily recognizable.
A very useful feature of deterministic hierarchical wallets is the ability to derive public keys from public parent keys, without having private keys.
This provides us with two ways of deriving a public key: either from the private key daughter, or directly from the parent public key (with a process similar to that used for the derivation of the private child keys). The second derivation method introduces potential risks.
Generally the knowledge of a public key does not allow to determine the corresponding private key. However, since the extended public key contains the chain code, if a private key is known, it is possible to determine all the sister private keys and derive the private mother key from them (if you know the parent chain code).
To respond to these risks in HD wallets, a derivation method known as a hardened derivation has been introduced which breaks the link between the parent public key and the child chain code. The hardened derivation uses the mother private key for the generation of the child chain code and not the parent public key.
When the derivative function of private hardened keys is used, the private key daughter and the chain code are completely different from what would result from a normal derivation function. The resulting “branch” of keys can be used to produce extensive public keys that are not vulnerable, because the chain code contained in them can not be compromised to reveal any private key.
The index number used to generate child public keys is a 32-bit integer.
For a simple distinction between the keys obtained from the classical derivation and those obtained from the hardened derivation, the set of possible values for the index number is divided into two ranges.
The numbers from 0 to 2 ^ 31-1 are used for the classical derivation, while the numbers from 2 ^ 31 to 2 ^ 32-1 are used for the hardened derivation.
The keys contained within an HD wallet are addressed through a “path name” which uses the slash character (“/”) to separate the various levels of the tree. The private keys derived from the private master key are identified by the lowercase letter m, while the public keys derived from the public master key are identified by the capital letter M. The “descent” of a key can be read from right to left, until you reach the master key from which it was derived. For example, the m / x / y / z identifier describes the key that is the z-th child of the key m / x / y, which is the y-th child of the key m / x, which is the x- esima daughter of m.
For the security of the bitcoin accounts of the individual users it is necessary that the latter maintain their secret private keys. This security criterion presents operational difficulties, above all in the event that a key backup should be retained to prevent loss. A key stored in an encrypted wallet is in itself safe but has operational limits when the user wants to move some keys from one wallet to another or has to upgrade the software wallet. In this regard, a coding standard has been introduced that can be used in many bitcoin wallets (wallets developed according to the Bitcoin Improvement Proposal 38 standard or BIP0038).
The coding process uses a passphrase (very long password), the coding system Base58Check and allows a secure storage of the keys and the safe transport of the same between different wallets. The standard uses the Advanced Encryption Standard (AES), a standard developed by the National Institute of Standards and Technology (NIST) and used frequently in data encoding applications. The coding system introduced by BIP0038 takes in input a private bitcoin key, generally expressed in the Wallet Import Format (WIF) format, as a Base58Check string with the prefix “5”. As a second input, the coding system requires a passphrase (generally consisting of a complex string of alphanumeric characters). The encoding output is a private key encoded in the Base58Check format with the prefix “6P”. All wallet applications developed according to the BIP0038 standard recognize the encoded private keys and require the user to enter the corresponding passphrase to import the key to the wallet.
Pay-to-Hash Scripts (P2SH) and Multi-Sig Addresses
A traditional bitcoin address has as its first character the number “1” and is derived from the public key, which in turn is derived from the private key through the derivation processes seen previously.
The bitcoin addresses that have the number “3” as their first character are pay-to-script hash addresses (P2SH), often mistakenly called multi-signature or multi-sig addresses. They designate the bitcoin transaction beneficiary as the hash of a script and not the owner of a private key.
This type of address was introduced in 2012 with the Bitcoin Improvement Proposal 16 (BIP0016), and was widely adopted by the community because it introduces additional features to the addresses themselves.
Unlike transactions that transfer funds to traditional bitcoin addresses (known as pay-to-public-key-hash or P2PKH), direct transactions to P2SH addresses require additional parameters than the hash of the public key and the private key as evidence of ownership .
The required parameters are set during the creation of the address and all transactions directed to this bitcoin address must contain the same parameters. P2SH addresses are created from a transaction script using the same encoding process as seen for traditional addresses applied to the script rather than the public key.
script hash = RIPEMD-160 [SHA-256 (script)]
The resulting “hash script” is encoded in Base58Check with a version prefix of 5, which corresponds to an encoded address starting with the number 3.
The most common implementation of the P2SH function is the script for multi signature addresses. This script requires more than one signature for proof of ownership and the consequent possibility of spending the funds of a transaction. The implementation of the multi-signature functionality in bitcoins is such as to require M signatures (also known as thresholds or thresholds) from a total of N keys where M is less than or equal to N (M-of-N multi sig). The concept behind the multi signature function is similar to the concept of shared account in traditional banking systems.
The paper wallet is an effective bitcoin offline storage method known as “cold storage”. In essence, the paper wallets are the printing on paper of the private key associated with the bitcoin account (often they can include the corresponding bitcoin address but it is not necessary because as we have seen it can be derived from the private key). Like any backup system, it allows to keep the data related to your bitcoin account to avoid the loss caused by hardware problems of the user computer or the accidental deletion of the file (database) that contains the wallet. Compared to traditional backup methods (if it is generated offline and is never stored on any computer) it is safer against possible cyber attacks.
A paper wallet can be easily generated using a client-side generation tool like the one on bitaddress.org. The page contains the source code necessary for the generation of the paper wallet, just download the HTML page on the hard disk or on an external storage unit like a USB flash drive, disconnect from the internet and open it on a browser. To improve the level of security it is recommended to use a pristine operating system (such as a bootable Linux OS CD-ROM or a USB OS bootable USB flash drive).
Each key generated with this tool executed in offline mode can be printed on paper using a local printer (we recommend connecting the printout via USB cable and not using wireless printers), allowing the user to generate keys that have never been stored on a system that can be connected to the network.
One of the main security limits of paper wallets is that they have no protection against theft. In this regard it is advisable to use more sophisticated types of paper wallet which encode the key using BIP0038. The coding standard requires the user to passphrase the encoding-decryption of the key without which there can be no access to the key and therefore to the associated bitcoin account.
Credits: Andrea Mineo