Cryptographic keys
On the Bitcoin network, possession of Bitcoins and the transfer of value via transactions are reliant upon private keys, public keys, and addresses. Elliptic Curve Cryptography (ECC) is used to generate public and private key pairs in the Bitcoin network. We have already covered these concepts in Chapter 4, Public Key Cryptography, and here we will see how private and public keys are used in the Bitcoin network.
Private keys in Bitcoin
Private keys are required to be kept safe and normally reside only on the owner's side. Private keys are used to digitally sign the transactions, proving ownership of the bitcoins.
Private keys are fundamentally 256-bit numbers randomly chosen in the range specified by the SECP256K1 ECDSA curve recommendation. Any randomly chosen 256-bit number from 0x1
to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140
is a valid private key.
Private keys are usually encoded using Wallet Import Format (WIF) in order to make them easier to copy and use. It is a way to represent the full-size private key in a different format. WIF can be converted into a private key and vice versa. The steps are described here.
For example, the consider the following private key:
A3ED7EC8A03667180D01FB4251A546C2B9F2FE33507C68B7D9D4E1FA5714195201
When converted into WIF format, it looks as shown here:
L2iN7umV7kbr6LuCmgM27rBnptGbDVc8g4ZBm6EbgTPQXnj1RCZP
Interested readers can do some experimentation using the tool available at http://gobittest.appspot.com/PrivateKey.
Also, mini private key format is sometimes used to create the private key with a maximum of 30 characters in order to allow storage where physical space is limited; for example, etching on physical coins or encoding in damage-resistant QR codes. The QR code is more damage resistant because more dots can be used for error correction and less for encoding the private key.
QR codes use Reed-Solomon error correction. Discussion on the error correction mechanism and its underlying details is out of the scope of this book, but interested readers can refer to https://en.wikipedia.org/wiki/QR_code#Error_correction for further information.
A private key encoded using mini private key format is also sometimes called a minikey. The first character of the mini private key is always the uppercase letter S
. A mini private key can be converted into a normal-sized private key, but an existing normal-sized private key cannot be converted into a mini private key. This format was used in Casascius physical bitcoins.
Interested readers can find more information at https://en.Bitcoin.t/wiki/Casascius_physical_bitcoins.
Figure 6.9: A Casascius physical Bitcoin's security hologram paper with mini key and QR code
The Bitcoin core client also allows the encryption of the wallet that contains the private keys.
As we learned in Chapter 4, Public Key Cryptography, private keys have their own corresponding public keys. Public keys on their own are useless and private keys on their own are equally of no use. Pairs of public and private keys are required for the normal functioning of any public key cryptography-based systems such as the Bitcoin blockchain. In the next section, we introduce the usage of public keys in Bitcoin.
Public keys in Bitcoin
Public keys exist on the blockchain and all network participants can see them. Public keys are derived from private keys due to their special mathematical relationship with those private keys. Once a transaction signed with the private key is broadcast on the Bitcoin network, public keys are used by the nodes to verify that the transaction has indeed been signed with the corresponding private key. This process of verification proves the ownership of the bitcoin.
Bitcoin uses ECC based on the SECP256K1 standard. More specifically, it makes use of an Elliptic Curve Digital Signature Algorithm (ECDSA) to ensure that funds remain secure and can only be spent by the legitimate owner. If you need to refresh the relevant cryptography concepts, you can refer to Chapter 4, Public Key Cryptography, where ECC was explained. Public keys can be represented in uncompressed or compressed format, and are fundamentally x and y coordinates on an elliptic curve. In uncompressed format, public keys are presented with a prefix of 0x4
in hexadecimal format. x and y coordinates are both 32 bytes in length. In total, a compressed public key is 33 bytes long, compared to the 65-byte uncompressed format. The compressed version of public keys include only the x part, since the y part can be derived from it.
The reason why the compressed version of public keys works is that if the ECC graph is visualized, it reveals that the y coordinate can be either below the x axis or above the x axis, and as the curve is symmetric, only the location in the prime field is required to be stored. If y is even then its value lies above the x axis, and if it is odd then it is below the x axis. This means that instead of storing both x and y as the public key, only x needs to be stored with the information about whether y is even or odd.
Initially, the Bitcoin client used uncompressed keys, but starting from Bitcoin Core client 0.6, compressed keys are used as standard. This resulted in an almost 50% reduction of space used to store public keys in the blockchain.
Keys are identified by various prefixes, described as follows:
- Uncompressed public keys use
0x04
as the prefix. Uncompressed public keys are 65 bytes long. They are encoded as 256-bit unsigned big-endian integers (32 bytes), which are concatenated together and finally prefixed with a byte0x04
. This means 1 byte for the0x04
prefix, 32 bytes for the x integer, and 32 bytes for y integer, which makes it 65 bytes in total. - Compressed public keys start with
0x03
if the y 32-byte (256-bit) part of the public key is odd. It is 33 bytes in length as 1 byte is used by the0x03
prefix (depicting an odd y) and 32 bytes for storing the x coordinate. - Compressed public keys start with
0x02
if the y 32-byte (256-bit) part of the public key is even. It is 33 bytes in length as 1 byte is used by the0x02
prefix (depicting an even y) and 32 bytes for storing the x coordinate.
Having talked about private and public keys, let's now move on to another important aspect of Bitcoin: addresses derived from public keys.
Addresses in Bitcoin
A Bitcoin address is created by taking the corresponding public key of a private key and hashing it twice, first with the SHA256 algorithm and then with RIPEMD160. The resultant 160-bit hash is then prefixed with a version number and finally encoded with a Base58Check encoding scheme. The Bitcoin addresses are 26-35 characters long and begin with digits 1 or 3.
A typical Bitcoin address looks like the string shown here:
1ANAguGG8bikEv2fYsTBnRUmx7QUcK58wt
Addresses are also commonly encoded in a QR code for easy distribution. The QR code of the preceding Bitcoin address is shown in the following image:
Figure 6.10: QR code of the Bitcoin address 1ANAguGG8bikEv2fYsTBnRUmx7QUcK58wt
Currently, there are two types of addresses, the commonly used P2PKH and another P2SH type, starting with numbers 1 and 3, respectively. In the early days, Bitcoin used direct Pay-to-Pubkey, which is now superseded by P2PKH. These types will be explained later in the chapter. However, direct Pay-to-Pubkey is still used in Bitcoin for coinbase addresses. Addresses should not be used more than once; otherwise, privacy and security issues can arise. Avoiding address reuse circumvents anonymity issues to an extent, but Bitcoin has some other security issues as well, such as transaction malleability, Sybil attacks, race attacks, and selfish mining, all of which require different approaches to resolve.
Transaction malleability has been resolved with the so-called SegWit soft-fork upgrade of the Bitcoin protocol. This concept will be explained later in the chapter.
Figure 6.11: From bitaddress.org, a private key and Bitcoin address in a paper wallet
Base58Check encoding
Bitcoin addresses are encoded using the Base58Check encoding. This encoding is used to limit the confusion between various characters, such as 0OIl, as they can look the same in different fonts. The encoding basically takes the binary byte arrays and converts them into human-readable strings. This string is composed by utilizing a set of 58 alphanumeric symbols. More explanation and logic can be found in the base58.h
source file in the Bitcoin source code:
/**
* Why base-58 instead of standard base-64 encoding?
* - Don't want 0OIl characters that look the same in some fonts and
* could be used to create visually identical looking data.
* - A string with non-alphanumeric characters is not as easily accepted as input.
* - E-mail usually won't line-break if there's no punctuation to break at.
* - Double-clicking selects the whole string as one word if it's all alphanumeric.
*/
This file is present in the Bitcoin source code and can be viewed at https://github.com/bitcoin/bitcoin/blob/c8971547d9c9460fcbec6f54888df83f002c3dfd/src/base58.h.
Now that we have covered private keys, public keys, Base58 encoding, and addresses, with that knowledge we can now examine how a Bitcoin address is generated by using all these elements. We briefly touched on it when we introduced addresses in Bitcoin earlier, but now we will see this in more detail with a diagram.
The following diagram shows how an address is generated, from generating the private key to the final output of the Bitcoin address:
Figure 6.12: Address generation in Bitcoin
In the preceding diagram, there are several steps that we will now explain:
- In the first step, we have a randomly generated ECDSA private key.
- The public key is derived from the ECDSA private key.
- The public key is hashed using the SHA-256 cryptographic hash function.
- The hash generated in step 3 is hashed using the RIPEMD-160 hash function.
- The version number is prefixed to the RIPEMD-160 hash generated in step 4.
- The result produced in step 5 is hashed using the SHA-256 cryptographic hash function.
- SHA-256 is applied again.
- The first 4 bytes of the result produced from step 7 is the address
checksum
. - This
checksum
is appended to the RIPEMD-160 hash generated in step 4. - The resultant byte string is encoded into a Base58-encoded string by applying the Base58 encoding function.
- Finally, the result is a typical Bitcoin address.
In addition to common types of addresses in Bitcoin, there are some advanced types of addresses available in Bitcoin too. We discuss these next.
Vanity addresses
As Bitcoin addresses are based on Base58 encoding, it is possible to generate addresses that contain human-readable messages. An example is shown as follows—note that in the first line, the name BasHir
appears:
Figure 6.13: Vanity public address encoded in QR
Vanity addresses are generated using a purely brute-force method. An example of a paper wallet with a vanity address is shown in the following screenshot:
Figure 6.14: Vanity address generated from https://bitcoinvanitygen.com/
In the preceding screenshot, on the right-hand bottom corner, the public vanity address is displayed with a QR code. The paper wallets can be stored physically as an alternative to the electronic storage of private keys.
Multi-signature addresses
As the name implies, these addresses require multiple private keys. In practical terms, this means that in order to release the coins, a certain set number of signatures is required. This is also known as M of N multisig. Here, M represents the threshold or minimum number of signatures required from N number of keys to release the Bitcoins.
Remember that we discussed this concept in Chapter 4, Public Key Cryptography.
With this section, we've finished our introduction to addresses in Bitcoin. In the next section, we will introduce Bitcoin transactions, which are the most fundamental and important aspect of Bitcoin.